On 27/06/11 16:39, Paul Wouters wrote: > On Mon, 27 Jun 2011, Florian Weimer wrote: > >>> 1 Is this problem happening because EDNS failure is not remembered for >>> forwarders? >> >> There is no realiable way to detect EDNS support in forwarders, so there >> isn't anything to remember, really. Sadly, the situation with >> authoritative servers is not much better. > > That is not entirely true, because bind does log a message that it is > disabling EDNS, and then gets the query out. So it could remember > that state for a little while? But currently, it appaers to not do > that, so a forwarder with broken EDNS creates havoc on a busy server > in combination with serving TTL=0 records.
BIND does take notice of this and it's something we're looking at to make better in future releases. But at the moment it's not foolproof and its effectiveness is dependent on circumstances. There is short term caching of learned 'we don't support EDNS' servers. But reaching the point of being able to process and cache them is dependent on how many servers we're dealing with for a zone that we're querying and also how far down the 'trail' of handling a client query we happen to be. If the client query times out before BIND has finished trying and timing out, then it doesn't get to cache what it was in the process of learning. There's also currently no caching of intermediate status - such as supporting EDNS0 but only at size 512. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
