cached rr not provided to recursive clients

[Kevin Darcy]

Take a look at Section 5.4.1 ("Ranking Data") in RFC 2181.

- Kevin

Ladislav Vobr wrote:

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