EDNS request problem on TTL=0 data

Scott Mann smann at isc.org
Fri Jun 24 21:11:09 UTC 2011

Hi Paul,

Which version of named are you running? You've likely run into an issue 
that we've seen before - basically, as you have surmised, your server 
has to retry each query and never gets a response regarding edns (so it 
can't "remember"). Let me know which version you are running and I'll 
get back to you regarding the availability of a "fix."

You can mitigate this issue by using "edns-udp-size 512" in the 
appropriate server clause or use "edns no" to turn off edns altogether.


On 06/24/2011 01:22 PM, Paul Wouters wrote:
> Hi,
> I'm investigating an outage that happened on a bind server. It was
> configured as a caching resolving name server. It was forwarding for
> one specific zone. This zone had two nameservers/forwarders of which one
> at some point was unreachable due to a cable cut. The other nameserver
> turned out to be dropping any requests with the DO bit set.
> What seems to have happened is:
> 1 the bind nameserver would send 3 queries 1s apart with ENDS0+DO bit, 
> which were
>   dropped.
> 2 bind sends out a query without the DO bit, it gets a response with 
> TTL=0
> 3 a burst of queued up queries for that exact query gets rushed 
> through for 1s
>   (prob not more then max-clients-per-query though, which was set at 100)
> 4 goto 1
> This not only caused resolving failures for the forwarding data, but 
> within the hour
> caused the entire server to collapse under load. The number of clients 
> asking
> for this data was higher then the max-clients-per-query setting.
> My questions:
> 1 Is this problem happening because EDNS failure is not remembered for 
> forwarders?
> 2 Is this problem happening because EDNS failure is forgotten once 
> there is no more
>   data cached that used the specified nameserver?
> 3 Does max-clients-per-query apply to forward zone queries too, or is 
> this ignored?
> 4 Can this behaviour be changed via a configuration option so we can 
> remember this EDNS
>   failure so that we're not unable to anser queries for 3 out of 4 
> seconds?
> Paul
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

More information about the bind-users mailing list