Solving: too many timeouts resolving ... disabling EDNS

[Aliet Santiesteban Sifontes]

Mark, here I attach the capture file on the gateway, I filtered and
only left there udp dns packages and icmp responses, you will see that
there are icmp responses por queries that get responses ok,
timeout???, you can see this file with wireshark or ethereal, maybe
this can help to trace the problem, we have satellite links, maybe the
latency can be a problem, ny way I'm sure the answer is digging in
this capture file.
Best regards
2008/8/22 Aliet Santiesteban Sifontes <alietsantiesteban at gmail.com>:
> I know this, I have made some package capture on the gateway, and it
> seems bind is having problems with high udp ports, I'm doing this
> tests without firewalls, I'm attached directly to the net to find this
> very problem for me, I will attach the capture on next posts so
> somebody can help me with this.
> I mean, no firewall, in os, and no firewall in my gateway, is just
> acting a a routing platform, I did all the tests to query with dig
> dnssec related stuff and works ok, and the EDNS problems is happening
> with all domains, even with example.com.
> Best regards
> 2008/8/22, Mark Andrews <Mark_Andrews at isc.org>:
>>
>> > Hi, list, I have upgraded our dns servers to version 9.5.0 P2, we have
>> > a hight load, and a merged setup of authority and recursive servers, I
>> > know this is bad, but one can't have everything it wants, specially
>> > when having low resources.
>> > I have running in almost all the problems listed on this list since
>> > the upgrade for the vulnerability of kaminsky:
>> > Out of file descriptors, ... etc, it has been a realy hard job, we
>> > also have to change our firewall beacuse of the problems with udp
>> > packages, and until now almost everything is solved, but one thing
>> > that realy has me crazy.
>> > We are tunning in rhel 5.2, customs rpms packages of 9.5.0 P2 built
>> > for highs loads, we have 2000 zones, and almost 7000 recursive
>> > clients, I'm trying to fix the problem of:
>> > too many timeouts resolving ...: disabling EDNS
>> >
>> > a average ping from our network has this responses
>> >
>> > PING google.com (64.233.187.99) 56(84) bytes of data.
>> > 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=236
>> > time=582 ms
>> > 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=2 ttl=236
>> > time=583 ms
>> >
>> > PING isc.org (204.152.184.88) 56(84) bytes of data.
>> > 64 bytes from external.isc.org (204.152.184.88): icmp_seq=1 ttl=50 time=610 m
>> > s
>> > 64 bytes from external.isc.org (204.152.184.88): icmp_seq=2 ttl=50 time=610 m
>> > s
>> >
>> > I did all the test to confirm our firewall allow big udp packages,
>> > even I have used dig to query for dnssec, and it works ok, so I don't
>> > understand why bind timeouts the edns query, so, I'm wondering, what
>> > is the timeout for a edns query, could I change this value to a custom
>> > one, why dig can do edns queries, and why bind can't do it, and says
>> > timeouts and disable this, I know edns is important for the next step
>> > to use dnssec, but if dig can do it, why binds timeouts???
>> > Any ideas..
>> > Best regards, Aliet
>>
>>        "disabling EDNS" is issued when named experiences too many
>>        timeouts to EDNS queries and named decides to give up on
>>        EDNS and revert to plain old DNS.   Now timeouts can be the
>>        result of many things.  Broken nameservers that don't respond
>>        to EDNS queries.  Firewalls that block EDNS queries.
>>        Firewalls that block fragmented responses.  Firewalls/NATs
>>        that don't handle out of order fragments.
>>
>>        Timeouts can also be due to other network problems including
>>        unreachable servers.
>>
>>        If you are getting lots of these then you do have network /
>>        firewall problems.  They may however *not* be caused by EDNS.
>>
>>        The message has the symptom "too many timeouts", what it
>>        was trying to do "resolving 'ns.cmmail.com/AAAA' (in
>>        'cmmail.com'?)" and what named doing "disabling EDNS" to
>>        try to rectify the problem.
>>
>>        It does not say "EDNS is broken".
>>
>>        Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>>
>