cached rr not provided to recursive clients

[Ladislav Vobr]

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
> 
> 
>