On Mon, 6 Dec 2010, Barry Margolin wrote:
In article <mailman.955.1291658327.555.bind-us...@lists.isc.org>,
Jay Ford <jay-f...@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-f...@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
