----- Original Message ----- > From: "Jim Reid" <j...@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
