On 4/6/15, 12:46, "Casey Deccio" <ca...@deccio.net> wrote: >> Isn't "owns an NS set" inferred by "zone"? > > "The NS RR states that the named host should be expected to have a zone > starting at owner name of the specified class" (RFC 1034).
IMHO, it is more precise to talk about domain names that own or do not own an NS set than whatever is meant by "to have a zone starting at owner name". > Also, "delegation point" implies and is used to refer to a "location", i.e., > the administrative zone in which the RRsets are governed, rather than the > RRsets themselves. Often RFC 4034/4035 use the phrase "at a delegation > point". So, while your definitions might be fine, it doesn't seem to me like > definitions that refer to a set of records (as opposed to the location of the > records) is accurate--at least for the purposes of RFC 4033, which serves as a > reference for the RFC 4033/4034/4035 series. Part of what is happening is that DNS terminology has never been the hallmark of precision. Is a delegation point a thing or a place between two things? It's not clear. (Like, when traveling internationally, when you "go through customs", you are "at the border" but not really, you've already crossed over the border. The analogy of DNS delegations and international boundries isn't very strong, I'm merely referring to the physical act of approaching the booths/tables.) Regardless of all else, a name owning an NS set is special. It may not own an SOA record - which would be, colloquially speaking, "broken." The parent zone of such a name (owns an NS but no SOA) treats the name as any other cut point - the problem is on the other side. From this, IMHO, it's more precise to talk about names that own certain types of records than to apply other nomenclature (label, but not in the DNS sense of label). Part of the answer to this, in my mind, is embedded in the NSEC records (or the corresponding hash's NSEC3 records) found in the parent and in the child. The set of bits set in the parent reflect the types the parent has some "say" over. The set of bits set in the child reflect the types the child has say over. The other part of the answer is embedded in the set RRSIGs at each location (parent and child) determine what records each side has "authority" over. Note "say" and "authority" differ in the annoying case of the NS set. I realize that terminology is very important. It's what future generations rely upon in trying to figure what has been wrought. But combing through the past documents here is not going to lead to a clear set of terms - in my opinion - because, well, no one ever reviewed the documents that way. (The RFCs are rife with issues, such as whether or not to downcase the RRSIG's signer name - a topic that "leapfrogging RFCs" kept up a contradiction. BTW, you shouldn't but most implementations did until recently.) Perhaps unfortunately, a lot of what is needed to understand the documents was left at the mic, in hallways, or perhaps mail messages that never made it to archives. So, it's important to come to a common set of terminology which reflects how we understand the DNS to be built today, less important to rectify this with the past documents. Don't take this as me saying "I'm right you rascal, now get off the porch" but to find consensus today rather than worry too much about immutable documents.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
