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