I have a question for the NSD developers. I have a zone defined as follows:
$ORIGIN zone.tld.
@ IN SOA ns1 rname 20090309 1d 1h 4w 1h
IN NS ns1
IN NS ns2
;
child IN NS foo.example.
IN NS bar.example.
;
sub.child IN NS some.more
IN NS yet.more
If I query an NSD 3.x server for NS records for sub.child.zone.tld, I
get back an authoritative answer with "some.more." and "yet.more.".
Just for comparison, tinydns does the same thing.
However, BIND 9 responds with "foo.example." and "bar.example.".
My understanding is that an authoritative name server should not know
about records below a delegation point, so BIND's behaviour seems okay.
Why does NSD respond with answers for records below the delegation point?
Is there a standard which defines what an authoritative server should do
with a zone like this?
At the moment, BIND and NSD exhibit opposite behaviour, which could lead
to interesting situations where a particular zone has such a delegation,
and a mix of BIND and NSD among its name server set.
My understanding is that an authoritative name server should not
know about records below a delegation point, so BIND's behaviour
seems okay.
Indeed. IMHO, it is a bug in NSD. It should not have loaded the zone
or at least ignored the below-the-cut records.
Is there a standard which defines what an authoritative server
should do with a zone like this?
RFC 1034 has a lot of sentences like (section 4.2.1):
The authoritative data for a zone is simply all of the RRs attached to
all of the nodes from the top node of the zone down to leaf nodes or
nodes above cuts around the bottom edge of the zone.
The way I read it is that zone.tld. is delegating the subdomains child
and sub.child. According to RFC 1034, only NS RRsets may appear at the
parental side of a zone cut. RFC 2181 clarifies that no data below the
zone cut may appear at the parental side.
The behavior of what to do with such a zone is undefined. NSD considers
this an operator error. Because of the explicit no end-user friendliness
requirement, NSD has not built in a detailed zone garbage detection.
As the result of the operator error, NSD behaves incorrectly.
FYI, this issue came up when I was working at ISC. I think BIND will
actually warn you when it loads such a zone (I'm not 100% sure, but turn
up logging and check if you want to test).
The specific question we discussed was whether or not something should
be logged when a part of a zone becomes obscured at runtime, either by
the system administrator changing zone file contents and reloading, or
by something like dynamic DNS or [AI]XFR. I am pretty sure my suggestion
that administrators be warned when this happens was ignored, because
BIND has an *implicit* no end-user friendliness requirement.
My understanding is that an authoritative name server should not
know about records below a delegation point, so BIND's behaviour
seems okay.
Indeed. IMHO, it is a bug in NSD. It should not have loaded the zone
or at least ignored the below-the-cut records.
I'm unsure if this should be considered a bug.
It could be perfectly ok for foo.example and bar.example to delegate sub.child back to your original "ns1" and "ns2", or directly to some.more and yet.more. ns1 and ns2 are in that case supply a by-pass directly to some.more and yet.more.
It saves most resolvers an extra hop they needn't to bother about. Perhaps an interesting feature? It depends a bit on how one looks at the ownership of the tree as a whole.
For reference:
$ORIGIN zone.tld.
@ IN SOA ns1 rname 20090309 1d 1h 4w 1h
IN NS ns1
IN NS ns2
;
child IN NS foo.example.
IN NS bar.example.
;
sub.child IN NS some.more
IN NS yet.more
it probably should. "Verbosely ignoring" the extraneous information
would be desirable IMHO.
It could be perfectly ok for foo.example and bar.example to delegate
sub.child back to your original "ns1" and "ns2", or directly to
Not really. It's not upon name servers to make these delegations, it's
something that comes from within the (parent) zone. So, it would be
perfect if there were a delegation of sub.child.zone.tld within the
child.zone.tld zone. However, this information does not belong into
the zone.tld zone, simply because it has no authority beyond its zone
cuts.
It saves most resolvers an extra hop they needn't to bother about.
If these were of concern, one could set up stealth slaves for the
child zones at the name servers authoritative for the parent. However,
with DNSSEC, you'd need the extra hops once again to verify the whole
key chain. And that's a feature, too.
