BIND 9.4.1-P1: "allow-query" and "allow-query-cache"

[Kevin Darcy]

Merton Campbell Crockett wrote:
> On 21 Oct 2007, at 15:45:20, Mark Andrews wrote:
>
>   
>>> I've recently gotten around to upgrading from BIND 8.3.7-REL to BIND
>>> 9.4.1-P1.  I would like to have a better understanding of the "allow-
>>> query" and "allow-query-cache" options.
>>>
>>> Assuming that I have "allow-query { any; };" and "allow-query-cache
>>> { none; };" set in the global options for a name server, what
>>> information can an external system access on the name server?
>>>
>>> I presume that the external system can access information regarding
>>> any zone defined as "type master;".  Does this hold true when there
>>> are no NS resource records identifying the name server as
>>> authoritative for the zone?
>>>
>>> Can external systems access information regarding any zone defined as
>>> "type slave;"?  Again, does this hold true when there are no NS
>>> resource records identifying the name server as authoritative for the
>>> zone?
>>>       
>> 	master/slave zones inherit allow-query from the options /
>> 	view level.
>>
>> 	I presume you mean no delegation to these servers rather
>> 	than no NS records as the zones won't load without NS record.
>> 	Lack of delegation has no impact on whether named will answer
>> 	for the zone or not.  Only the contents of named.conf control
>> 	that.
>>     
>
>
>
> The last question involves the treatment of a slave zone data that  
> was downloaded from one of the authoritative name servers.  Is this  
> treated as "cached" data because the name server is not identified in  
> one of the zone's NS records and, therefore, not accessible when  
> "allow-query-cache { none; }; is set?
>   
If you have an unexpired slave copy of the zone, you'll answer 
authoritatively for the zone regardless of what NS records may or may 
not contain. Remember that there are such things as undelegated slaves 
and/or "stealth" slaves.

>>> What information is accessible for zones defined as "type stub;" and
>>> "type forward;"?
>>>       
>> 	Stub zones prime the cache, forward zones only override where
>> 	recursive queries are sent.  They aren't real zones.
>>     
>
>
> Given that the name server loads "sub.domain.com" as a stub zone and  
> this is used prime the cache, the presence of an "allow-query-cache  
> { none; };" option would result in a DNS query for  
> "host.sub.domain.com" failing.  Is that correct?
>
>   
It doesn't really matter _how_ the data got into the cache, whether it 
was from a "stub" definition, forwarding, etc. If it's cached data 
rather than authoritative data, then "allow-query-cache" will control 
access to it.

- Kevin