Re: cached rr not provided to recursive clients

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