BIND 9.4.1-P1: "allow-query" and "allow-query-cache"
Merton Campbell Crockett
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?
What information is accessible for zones defined as "type stub;" and
"type forward;"?
Merton Campbell Crockett
m.c.cr...@roadrunner.com
Mark Andrews
> 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.
> 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.
> Merton Campbell Crockett
> m.c.cr...@roadrunner.com
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Chris Buxton
your server for any authoritative data that it has. This includes
zones of type master and slave. It does not affect zones of type hint
or forward, which control how your server performs recursion in
response to recursive queries. (Since allow-query-cache is set to
{ none; }, your server will not perform recursion unless you re-
enable it for specific domains.)
Stub zones are interesting, because they not only control how your
server reacts to recursive queries, they can also be used to create
delegations from your zone to a child zone. I think data from these
zones could be returned by your server as a referral.
Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone: +354 412 1500
Email: cbu...@menandmice.com
www.menandmice.com
Men & Mice
We bring control and flexibility to network management
This e-mail and its attachments may contain confidential and
privileged information only intended for the person or entity to
which it is addressed. If the reader of this message is not the
intended recipient, you are hereby notified that any retention,
dissemination, distribution or copy of this e-mail is strictly
prohibited. If you have received this e-mail in error, please notify
us immediately by reply e-mail and immediately delete this message
and all its attachment.
On Oct 20, 2007, at 12:38 PM, Merton Campbell Crockett 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?
>
> What information is accessible for zones defined as "type stub;" and
> "type forward;"?
>
> Merton Campbell Crockett
> m.c.cr...@roadrunner.com
>
>
>
>
Merton Campbell Crockett
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?
>> 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?
>> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
>
>
Merton Campbell Crockett
m.c.cr...@roadrunner.com
Kevin Darcy
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