[Unbound-users] problems resolving www.iana.org / ianawww.vip.icann.org

Tue Jun 21 06:56:09 UTC 2011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Leen,

On 06/21/2011 01:09 AM, Leen Besselink wrote:
> On 06/20/2011 03:52 PM, W.C.A. Wijngaards wrote:
>> Hi Leen, Daisuke,
>>
>> On 06/18/2011 04:56 PM, Daisuke HIGASHI wrote:
>>> Leen Besselink wrote:
>>
>>>> Is it just me or is Unbound 1.4.7 not able to resolve www.iana.org /
>>> ianawww.vip.icann.org right now ?
>>
>> The reponses for this query, the DNSKEY and the A responses are over 3
>> Kb.  You likely have path MTU trouble.  Something is wrong with your
>> fragments.  Perhaps you own firewall is set to stop UDP fragments?
>>
>> There is the OARC reply size tester to help with that.
>>
>> The error you see in your logs (I saw your attachments earlier, Leen),
>> are that the system returns very short (0 byte?) UDP datagrams to
>> unbound.  Likely because of the UDP fragmentation issues, or less likely
>> because of a server-error at icann.org nameservers.
>>
>>> Unbound with DNSSEC validation not able to resolve www.iana.org.
>>> BIND9 manages to do it but takes long time because of many timeouts.
>>
>> All the time is because of the PMTU trouble.  For the server it seems as
>> if the packet has disappeared, and after a while, BIND and unbound
>> attempt to use smaller packets.  Where BIND does EDNS at 512 (and thus TCP
>> and it works), Unbound does not implement EDNS at 512 (it is against
>> standard and people oppose it) and thus turns off EDNS altogether, gets
>> the response but without DNSSEC information, and thus returns SERVFAIL
>> because it fails validation.
>>
>>> It seems that all NS in vip.icann.org returns broken response for
>>> DNSKEY query with UDP. BIND9 retries query with TCP and gets complete
>>> DNSKEY but Unbound does not.
>>
>> Yes, because of the different probe.
>>
>>> Despite vip.icann.org NS are broken, is Unbound behavior correct?
>>
>>> ------------------
>>>> dig @gtm1.lax.icann.org vip.icann.org DNSKEY +dnssec
>>>   <snip>
>>> ;; connection timed out; no servers could be reached
>>
>>>> dig @gtm1.lax.icann.org vip.icann.org DNSKEY +tcp +dnssec
>>> <very large DNSKEY RRSet and RRSIG>
>>> ------------------
>>
>> It is not really possible for unbound to probe the PMTU trouble
>> everywhere; it is not DNS-OARC.  If you really have to you can configure
>> a workaround, the edns-size in unbound.conf to 1280 or so and then you
>> have less PMTU trouble.  It is better for the internet if you fix the
>> PMTU trouble (on your firewall, or from your provider).
>>
> 
> Hi Wouter,
> 
> It is actually my normal home ISP-connection and a HE-tunnel and Unbound
> is on the firewall itself,
> it still took a lot of tries/time.
> 
> Have to say I was trying to 'debug' the problem from with unbound-host
> behind the firewall, probably
> not that smart. I've learned my lesson. :-)
> 
> The ISP-connection can usually get 'normal' 1500 MTU, the HE-tunnel
> might obvisously not be able
> to get that.
> 
> So over IPv4 the Unbound on the firewall should normally not have any
> PMTU-issues on the first
> (few) hops.
> 
> I'll atleast know what to look for when it happends again, maybe
> disable/look at account of some
> firewall rules to see if that is the cause.

Commonly, people block ICMP, and over IPv6 this blocks fragments because
ICMP PMTU Discovery ICMP messages need to traverse the firewall.  Some
firewalls do not support UDP-connection-tracking with fragmentation on
IPv6 (such as pf).  These are random IPv6 hints ... :-)

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOAECEAAoJEJ9vHC1+BF+NlxYP/RvkYEss3H3Ns89SvuHmxdTh
742DYBecfT2ZstrPHw479EC9sdLabiqijFcKA5s/f6j/w45dpnGYgU2N/sv+b962
KAaQl5WfFYgO0LYRcM2rg9DgFdDKXeWVNU6xTuejtFDE6mBrjVOc4nyDl6PwNsuE
TpVfvHfYC2OLePcGGjd9/TT0F2uzH6auSAbYCf64ZjxBcW2mJwBz3rK1S+VmH/BB
hbSXq5qIJoGEOmCbEYtlp0v8KDx38bgkHuQgIKinltNyUZyUYXehvBZUM+fWfQws
cSClJLTq7FxB9cmCAAG5lyvxz0SoDzsB5OZzl22OzdDMO7RN8+DM0H4ZB/Xf2V6e
c/hQkPNomZMcM/Kno4cyYqXUgtMoJ/eARvpHkeip9zaOf5K1K9IzP6H4JZr2tOOO
GNWdiFoC6T2o/xPX2F/v8xKbqkVBm9RlX/DZ/OwQ++9waAYlzSitdb5a4ll+XnrN
sOJ/0XsDPvTpiB1FocNpjm3Qc1poR48dsrKYEYGV5YFHz0ouQgAHMwckiYhTsAU5
FjZ8m5Un1AHqvTJ21t5DTGcxQlE/HFsDgpty83LUsmCR4qBSGtU25pD3dz8jWt8t
y0YjIBJ94N1sEqDzaejqH1mVn1M8RayF+BaaKN33jIH/pg6Db9masi7YIE1YzWOA
pl5sUwAD6K/rlSkK/M5w
=YmKQ
-----END PGP SIGNATURE-----