Subject: [DNSOP] Zone apex and delegation point

From: Casey Deccio <[email-masked]>
Date: Fri, 3 Apr 2015 14:23:52 -0400

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 3 Apr 2015 18:52:46 +0000

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" <[email-masked]> 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:
> ----
> 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:
> In light of that, the following is a suggested update to the text in RFC 4033:
> ----
> 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
> 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.
> ----
> 
> the fact that the parent is brought up as an exception is a violation of that
> definition.
> 
> Suggested fix:
> ----

---

From: Paul Vixie <[email-masked]>
Date: Fri, 03 Apr 2015 11:53:53 -0700

Edward Lewis wrote:
> 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.

+1.

-- 
Paul Vixie

---

From: Casey Deccio <[email-masked]>
Date: Fri, 3 Apr 2015 15:21:28 -0400

> DS record, and when I've ever white-boarded a DNS hierarchy, the cut goes

This is understandable, and I can see how the introduction of the DS
changes things.  However, independent of the location of the zone cut, the
text is still confusing (to me), as it implies that there are multiple
nodes and names.

Here is an alternative wording, which adds the context of RRsets:
----
Delegation Point: Term used to describe a delegated name when used in
conjunction with RRsets on the parental side of 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 RRs 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 on the child side of a zone cut.  See also
delegation point.
----

Regards,
Casey

---

From: Edward Lewis <[email-masked]>
Date: Fri, 3 Apr 2015 19:32:00 +0000

On 4/3/15, 15:21, "Casey Deccio" <[email-masked]> wrote:
>   However, independent of the location of the zone cut, the text is still
> confusing (to me), as it implies that there are multiple nodes and names.

Well, that case:

> which is in the "example" zone (as opposed to the authoritative NS RRs at the
> zone apex of the "foo.example" zone).  See also zone apex.
> 
> with RRsets on the child side of a zone cut.  See also delegation point.
> ----

I'll start with, I've started to use cut point instead of delegation point,
so to me there's a cut and an apex at a delegation.  I'm not saying this to
start a revolution or new terminology, but in recognition of the confusion.

Delegation Point: the collection of records at a name which owns an NS set
that are visible in the parent zone.
Zone apex: the collection of records at a name which owns an NS set that are
visible in the child zone.

"Visible" is a nod to "occluded" records, those records that are subject to
appear in an AXFR but are below a zone cut.  (Section 3.5 of RFC 5936.)

Casey, now, see what you've started.  And on a Friday, no less!  Having to
dig up that reference to "occluded".

So, back to the proposed definitions:

Delegation Point: Term used to name the set of record sets owned by a name
that also owns an NS set that belong in the parent zone.  (The term "belong"
needs fixing.)

Zone apex: Term used to name the set of record sets owned by a name that
also owns an NS set that belong in the child zone.

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 4 Apr 2015 00:37:43 -0400

> seems to me that they are not consistent with RFC 1034 notions.

When I was working on this in the -00 with Paul, I came to believe
that 1034 was not always totally careful about distinguishing theory
and practice.

To me, the "delegation point" is a logical question: where in the tree
does a new authority take over?

The "zone cut" is in fact a question of implementation: delegation
points are implemented at zone cuts, which correspond to the point
where the parent gives away its authority over the namespace.
Therefore, _I_ think the zone cut is the place where the NS records
are.  But to me the delegation point is a logical construct, and as
such represents a point in the tree.  4033's definition, however,
ought to trump for the purposes of the terminology doc unless it's at
odds with other docs, because the terminology doc is supposed to
reflect known usage.

I believe quite strongly, however, that the zone apex is in fact a
logical point in the tree, and the zone origin is the implementation
of that.  I think that is just entailed by the way STD13 is written.

I think errata would be incorrect: if this is a change, it's a clarification, not an erratum in any previous document.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Casey Deccio <[email-masked]>
Date: Mon, 6 Apr 2015 12:46:08 -0400

> that are visible in the parent zone.
Zone apex: the collection of records at a name which owns an NS set that
> are visible in the child zone.
>
> "Visible" is a nod to "occluded" records, those records that are subject
> to appear in an AXFR but are below a zone cut.  (Section 3.5 of RFC 5936.)
>

Hope I didn't disrupt any weekend plans :)

> that also owns an NS set that belong in the parent zone.  (The term
> "belong" needs fixing.)
>

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

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.

Regards,
Casey

---

From: Casey Deccio <[email-masked]>
Date: Mon, 6 Apr 2015 13:16:19 -0400

On Sat, Apr 4, 2015 at 12:37 AM, Andrew Sullivan <[email-masked]>
wrote:

> I think errata would be incorrect: if this is a change, it's a
> clarification, not an erratum in any previous document.

Just to clarify, my original issue with the definition was not the location
of records, zone cut, or delegation point (per se), but more the
implication from the definition that there was more than one "node" or
(correspondingly) "name" in the namespace tree.  For example:

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

To me, "...the name at the parental side of a zone cut" implies a
parenthetical "as opposed to the name somewhere else".  Same with "...the
foo.example node in the 'example' zone".

The location of the zone cut is an interesting discussion, particularly in
the context of these definitions.  In fact, that's why the text of my
"proposed fix" included that language, but I can see now that it derailed
things.  For the purposes of this document the issue was the multiple
names/nodes discrepancy.

Regards,
Casey

---

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Apr 2015 17:38:55 +0000

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

---

From: Casey Deccio <[email-masked]>
Date: Mon, 6 Apr 2015 14:27:04 -0400

On Mon, Apr 6, 2015 at 1:38 PM, Edward Lewis <[email-masked]> wrote:

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

...except we're referencing those documents heavily to build the common set
of terminology (e.g., the hoffman draft).

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

Whether or not errata(s) or clarification(s) are warranted, based on my
readings/confusion, I find the discussion useful to come to "terms".

Casey

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Apr 2015 11:15:46 +0100

> an NS set than whatever is meant by "to have a zone starting at owner name".

I think the point of that quote is that the child zone's SOA must have the
same owner as the delegation in the parent. (This often gets screwed up in
load balancer configurations which causes problems because the SOA in a
negative reply identifies the wrong zone.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: Variable 3 or 4, becoming south or
southwest 4 or 5. Slight, occasionally moderate in north Forties and northeast
Cromarty. Fog patches in Forties and Dogger. Moderate or good, occasionally
very poor in Forties and Dogger.