[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dnsext] zone cut semantics
- Subject: [dnsext] zone cut semantics
- From: jra at baylink.com (Jay Ashworth)
- Date: Sun, 20 Feb 2011 21:31:13 -0500 (EST)
- In-reply-to: <[email protected]>
----- Original Message -----
> From: "Jim Reid" <jim at 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
> 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"?