cached rr not provided to recursive clients
Ladislav Vobr
lvobr at ies.etisalat.ae
Wed Mar 3 05:10:30 UTC 2004
Thanks a lot Kevin for your time and information in your reply
I was trying the get some reasoning behind this behavior, this is my
nature - always ask why :-)? I agree with you recursive and
non-recursive query can vary, and varies and it has it's good reasons as
you said.
There are around 4-5 different credit tags (authority, answer, glue,
authanswer, additional) in named_dump.db. The behavior you explained is
related to authanswer flag I assume, and other 4 are not considered as a
valid answer to the recursive client, and bind prefers to time out,
rather than to provide this type of cached data to recursive
clients/servers, am I right?
Does it mean bind will never provide any other cached rrs' then only the
ones with the Cr tag=authanswer?
This was my question, somehow to find out, when the bind really just
answer purely from the cache.
Ladislav
Kevin Darcy wrote:
> 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
>
>
>
More information about the bind-users
mailing list