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

W.C.A. Wijngaards wouter at NLnetLabs.nl
Tue Jun 21 06:56:09 UTC 2011

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,
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


More information about the Unbound-users mailing list