'dig -t any ...' question : *ANSWER* & *GLUE* credibility discrepancies

[Ladislav Vobr]

 > You seem to be under the impression that BIND's credibility weighting
 > to response data determines how it will resolve some query. It
 > doesn't. The server doesn't say to itself "I've only cached lowest
 > credibility data for this incoming query. Let's go and hunt for
 > definitive data from the zone's authoritatve servers and return that
 > to the client." The server answers from its cache if that has data
 > that will answer the query: credibility weighting doesn't come into
 > it. Otherwise it resolves the name, caches the responses during
 > resolving before returning an answer.

It does, jim, and I have to say it, your reply is incorrect, bind 8.3.4 
and 9.3.0beta4 and 9.2.3 all of these are reluctant to provide the 
answers to recursive client if it cached with credibility *glue*.

I have done some troubleshooting, and seems that there are discrepancies 
amongst different bind servers how they treat non-authoritative records 
let's call it glue, some like 8.3.4 returns these in the ANSWER section, 
and caching servers cache it under the credibility tag *answer* and 
without a hesitation provide it to a recursive client, others like 8.4.1 
and 9.2.3 or 9.3.0beta4 returns this in the authority section and it is 
cached by the recursive server with credibility level *glue*, which is 
in no way provided to the recursive clients.

This credibility levels and their impact is very poorly documented, and 
not even discussed, should it be clear after so many years of bind 
servicing the Internet community, till today there is no paper about how 
it effect the recursive and non-recursive clients, how to troubleshoot, 
and even here in the mailing list one can not get a clear idea, how this 
  was designed, what it is suppose to do, I think bind is great product, 
but shouldn't this be published so everybody knows how to 
troubleshoot:-( it is very simple once you figure it out.

BTW: the reason you got the reply, is imho that we have set up here 
anycast clusters and you got the answer for ANY query from 8.3.4 which 
gives it in the *answer* section, not the same I am getting from inside, 
where is different anycast cluster serves by 9.2.3 and 8.4.1, thus I am 
always getting it in the authority section and cache it as a *GLUE*, 
WHICH IS NOT PROVIDED TO RECURSION DESIRED CLIENTS, BUT INSTEAD OF IT 
BIND TRIGGERS A QUERY(S) (can be hundereds of queries) TO AUTH SERVERS.

P.S.: so to explain the case of ericsson.com correctly, if the gtld .com 
server returs the data for ANY query in the authority section, and not 
in the answer section, the caching server will be forced to cached as a 
*glue* only, thus will be forced to follow up up to the end with the 
authoritative server for to provide the recursive client with the 
*answer* or better *authanswer*

Ladislav