[dnsext] zone cut semantics

From: "Jim Reid" <jim@rfc1035.com>

> So: people-who-do: is my supposition/assertion above correct? If it is,
> is it reasonable to draw from it the inference that I do (IE, that Jim is
> correct and Brandon's not)?

It's more than reasonable Jay: it's true! Then again, I would say
that. :slight_smile:

But don't take my word for it. See for yourself. Query the parent
zone's name servers and the child's for the zone's NS RRset. Look who
sets and does not set the AA bit.

You've misunderstood the granularity of my question, though, Jim. :slight_smile:

I asked not what the default behavior was, but *whether it was even
manually possible to override* that default behavior. I believe it is
not, which would serve as much stronger evidence for your case.

You will of course need to use a decent lookup tool like dig to do
this. Or you could just read Section 6 of RFC2181. Brandon clearly
hasn't. :slight_smile:

Yes; I know how to drive dig. +trace is *really* cool, in fact.

I've been wanting to wrap +trace for nagios, so I can monitor my
registries/registrars. :slight_smile:

BTW, BIND8 got zone cut semantics wrong. It used one monolithic data
structure (a hash table) for everything. [BIND9 uses discrete red-
black trees for each zone.] So the parent would set the AA bit in a
referral response even though it shouldn't have done that. This
incorrect behaviour broke things and also permitted zone and server
misconfigurations to appear to work: for instance no NS records in the
child. Another weird error this caused was phantom A records that
didn't exist in either the parent or child zone files! Secure DNS put
an end to this brokenness -- and as a side effect killed BIND8 --
because it demands much stricter (and correct) zone cut sematics.

Good you made a point of this discrepancy.

When you say, though, that this permitted child zones to have no NS
records in them, I presume you mean "when the same server is serving
both the parent and the child in question"?

-- jra