IMHO, the original text in 4033 is correct as it is for the first proposed errata. The notion that zone cuts are between nodes was blown away by the DS record, and when I've ever white-boarded a DNS hierarchy, the cut goes through the node.
The parent is authoritative for the existence of the node, the child is authoritative for the data at the node. In DNSSEC we denoted this by having the bitmap of the delegation point include the NS despite not signing it. The parent signed proof that the NS set existed (RRSIG(NSEC) or RRSIG(NSEC3)) but was not authorized to endorse it's integrity (no RRSIG(NS)). We wished then (development of DNSSEC) that the NS set had been split the same way DS and DNSKEY have been designed to make this clearer but we weren't about to take on that change. While I respect the classics, one thing taught to me was that early RFCs were not meant to be specifications nor even pseudo-code. This was in particular to my study of "Algorithm" in RFC 1034, sect. 4.3.2. The documents described the concepts (see the title of that RFC) and were not meant to be strict rules to follow. So, with that, when there are differences is later documents, sometimes it is intentional and not an over sight/error. Yes, "do what I mean, not what I say!" The second errata is arguably right, but it depends on how you read the original text. The text switches context from zone apex to domain name mid-stride, which is, at least confusing. On 4/3/15, 14:23, "Casey Deccio" <ca...@deccio.net> wrote: > I've re-read the definitions of zone apex and delegation point in RFC 4033 (in > conjunction with review of draft-hoffman-dns-terminology-02) and it seems to > me that they are not consistent with RFC 1034 notions. Additionally, there > appears to be some misusage of the terms in the document itself. An errata > (or two) might be appropriate, but because the changes are not simple typo > fixes, I wanted to bring it to the list first. > > Original text: > ---- > Delegation Point: Term used to describe the name at the parental side of a > zone cut. That is, the delegation point for "foo.example" would be the > foo.example node in the "example" zone (as opposed to the zone apex of the > "foo.example" zone). See also zone apex. > > Zone Apex: Term used to describe the name at the child's side of a zone cut. > See also delegation point. > ---- > > RFC 1034 indicates that the zone cut is between nodes, which refer to names in > the namespace tree. In the context of delegation, there is no node with the > delegated name in the parent zone: the node is only on the child side, even > though there are records by that name on the parent side. Thus, the notion of > name/node at child/parent is confusing. From RFC 1034: > The RRs that describe cuts around the bottom of the zone are NS RRs that > name the servers for the subzones. Since the cuts are between nodes, > these RRs are NOT part of the authoritative data of the zone.... Since > name servers are always associated with zone boundaries, > NS RRs are only found at nodes which are the top node of some zone. In > the data that makes up a zone, NS RRs are found at the top node of the > zone (and are authoritative) and at cuts around the bottom of the zone > (where they are not authoritative), but never in between. > > In light of that, the following is a suggested update to the text in RFC 4033: > ---- > Delegation Point: Term used to describe a delegated name when used in > conjunction with RRsets at the zone cut. For example, the delegation NS RRs > for "foo.example" are found at the delegation point, which is in the "example" > zone (as opposed to the authoritative NS records at the zone apex of the > "foo.example" zone). See also zone apex. > > Zone Apex: Term used to describe the a delegated name when used in conjunction > with RRsets below the zone cut (i.e., at the top node). See also delegation > point. > ---- > > Also, the definition of Authoritative Data uses the terms incorrectly. > > Original text: > --- > All RRsets at the zone apex are authoritative, except for certain RRsets at > this domain name that, if present, belong to this zone's parent. These > RRset... > ---- > > But because "Zone Apex" is defined as being associated with the child zone, > the fact that the parent is brought up as an exception is a violation of that > definition. > > Suggested fix: > ---- > All RRsets at the zone apex are authoritative. Note, however, that certain > RRsets at this zone's delegation point, if present, belong to the zone's > parent. These RRsets... > ---- > > I'm happy to file two erratas for the above, but feedback is requested. > > Cheers, > Casey
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
