Re: [dnsext] zone cut semantics

[Jay Ashworth <jra () baylink com>]

----- Original Message -----
> From: "Jim Reid" <jim () rfc1035 com>

> On 21 Feb 2011, at 01:44, Jay Ashworth wrote:
>
> > 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. :-)
>
> 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.  :-)

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. :-)

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.  :-)

> 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"?

Cheers,
-- jra