EDNS request problem on TTL=0 data

[Cathy Almond]

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.