cached rr not provided to recursive clients

[Kevin Darcy]

Ladislav Vobr wrote:

>I have noticed that bind 9.2.3, albeit having the rr's in the cache as a 
>glue from parent, doesn't provide it to recursive clients, but only to 
>nonrecursive (dig +norec), in case authoritative servers are down.
>
>Most probably bind is trying to verify with the authoritative servers, 
>and without their reply it refuses to provided the data to but only to 
>recursive clients.
>
>Can someone elaborate what are the conditions/verifications/checks 
>required to provide recursive clients cached rrs'? What is the reasoning 
>behind this behavior?
>
>This seems to be a topic of a minor interest, since I have raised 
>several times without much success, but I think I am not the first guy 
>who dumped the cache and see the rr data there, wondering why bind 
>doesn't provide it. Are those non-responding authoritative nameservers 
>considered lame? No, not for bind9 they are not lame since it doesn't 
>log them in the lame.log...
>
Ladislav,
This behavior is the combined result of a) the distinction between 
recursive and iterative resolution and b) the design principle of DNS 
that answers to the same question should be as consistent as possible, 
even in the face of failures in the system.

When a DNS query is made recursively, it is essentially saying "do 
everything you can to get me the answer to this question, because I'm 
relying on you totally for the answer". Therefore the recursive resolver 
tries to get the answer by asking the authoritative servers. If they are 
down or unreachable, the query may time out, the client times out, life 
goes on.

When, on the other hand, a DNS query is made non-recursively, it 
essentially says "give me the best information you have about this name 
without recursing; if the response you give is incomplete or 
untrustworthy, that's OK because I'll just use your information to get 
the real data by myself". Therefore the recursive resolver gives out 
referral/glue information if that's all it happens to have.

Follow me so far? A recursive and a non-recursive query for the same 
RRset may generate different results, depending on what the responding 
resolver happens to have cached. This is normal and natural as the DNS 
protocol is designed.

Now, you seem to be implying that for a recursive query, the resolver 
should first try to get the answer from the authoritative servers, but, 
after a short timeout (shorter than the client's timeout!) it should 
give up and return glue information instead, if it has any. But that 
violates the consistency principle. It means that, in 
intermittent-connectivity situations, the same recursive query could get 
*different* answers -- sometimes glue, sometimes answers from the 
authoritative servers -- even though the base DNS data has not changed 
in any way. Such behavior would play havoc with any attempt to 
troubleshoot such a problem, and as a whole makes the DNS infrastructure 
seem unreliable.

- Kevin