Private Zones and Deligation bind9.7.2

[Jay Ford]

On Mon, 6 Dec 2010, Barry Margolin wrote:
> In article <mailman.955.1291658327.555.bind-users at lists.isc.org>,
> Jay Ford <jay-ford at uiowa.edu> wrote:
>
>> On Mon, 6 Dec 2010, Martin McCormick wrote:
>>> the config for this private zone is:
>>>
>>> zone "r.ds" {
>>> 	type master;
>>> 	file "/etc/namedb/master/r.ds.zone";
>>>            allow-update {
>>> key updsrv;
>>> };
>>>        allow-query { any; };
>>> #a list of slaves
>>> include "/etc/zoneconfigs/stwnotify";
>>> 	notify yes;
>>> };
>>
>> You configured this server to be master for the r.ds zone, which tells this
>> server that it is authoritative for names in that zone.  If it gets a query
>> for a resource record in that zone which it doesn't know, it will answer
>> authoritatively with a negative answer (either NXDOMAIN if the name doesn't
>> exist at all, or NOERROR with no "answer" data if the name exists but not
>> with the queried type).  NS records in a zone don't cause an authoritative
>> server to send queries elsewhere, because the server knows the answer by
>> virtue of being authoritative for the zone.
>
> That's not true.  NS records delimit the extent of the authority, and
> tell it that some other server is authoritative for the subdomain.  So
> as long as recursion is enabled, and the query is recursive, the server
> should follow the delegation.

If this were a normal delegation, from "ds" to "r.ds", you'd be right. 
However, in this case he was defining the "r.ds" zone as master & trying to 
delegate it.  You can't have both.  The master definition overrode the 
delegation, so the server in question acted authoritatively, ignoring the NS 
records.  It didn't need them because it was configured to be master.

I just verified that behavior with a fake master "mit.edu" zone with nothing 
in it but a fake SOA & real NS records.  The server gives an authoritative 
NXDOMAIN for alum.mit.edu & friends because they don't exist in the fake 
"mit.edu" zone for which it is configured to be master.

Anyway, it's a broken configuration which the original poster fixed.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951