rfc1034 & bind9 cache - cached glue A RR not available to any clients, even with +norec

[Ladislav Vobr]

Jonathan, when I dump the cache on my caching / proxy dns server it has 
this A record which I have asked for. It doesn't have to recurse to get 
it, and it should not recurse to get it, if it is in the cache already.

IMHO as per the rfc1034, it should provide it. My point was that the 
authoritative servers are unreachable (fake :-) ) and bind tries to 
flood them with requests it received from clients amplified by 100-200 
times (contacting each unreachable server several times :-( for each 
request) and it even refuses to tell you the A record of the flooded 
servers so you are really completely blind to this kind of activities 
going on in the background.

Ladislav

Jonathan de Boyne Pollard wrote:
> LV> Why bind9 doesn't provide A RRs, which were received as a
> LV> referral even to the +norec clients.
> 
> One possible reason why is that it isn't actually useful for proxy DNS 
> servers (and it is your proxy DNS server that you queried here, not the 
> actual content DNS servers themselves) to perform such "additional" 
> section processing; since DNS Client libraries generally only look for 
> the answer to the exact question that they asked and ignore additional 
> data, and thus it is largely pointless and consumptive of both bandwidth 
> and processing to eke out and to supply those data.
> 
> Another possible reason why is that by setting the RD bit to zero, 
> you've told your proxy DNS server to not issue any back-end queries to 
> other DNS servers, and essentially to do the bare minimum amount of 
> processing in order to generate a response.  Notice that BIND has 
> returned no more than the minimum information necessary to let you 
> distinguish the response as being a partial answer ending in a referral, 
> instead of a complete answer denoting an empty resource record set in 
> the form of type 3 response.
> 
> LV> $ dig a fake1.ladislav.name.ae. +norec
> 
> Now query your content DNS server directly with
> 
> 	dig @fake1.ladislav.name.ae. a fake1.ladislav.name.ae. +norec
> 
> and consider that, conversely, it is not only useful but necessary for 
> content DNS servers to perform "additional" section processing.
>