Subject: [DNSOP] DNS Terminology: Glue

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 12 Mar 2015 12:07:00 +0000

Hi.

  In http://www.ietf.org/id/draft-hoffman-dns-terminology-02.txt,
  "glue" is defined as follows.

   Glue records -- Resource records which are not part of the
   authoritative data, and are address resource records for the servers
   listed in the message.  They contain data that allows access to name
   servers for subzones.  (Definition from RFC 1034, section 4.2.1)

  Reference to "the message" seems to be a distraction here.  The
  cited source defines (and motivates) glue records, in a section
  which specifies "[t]he data that describes a zone", as follows

   [...] a zone contains "glue" RRs which are not
   part of the authoritative data, and are address RRs for the servers.
   These RRs are only necessary if the name server's name is "below" the
   cut, and are only used as part of a referral response.

  I think that placing the definition of glue in the scope of "the
  message" rather than in that of the zone data is likely to lead to
  confusion.

  Best regards,
  Niall O'Reilly

---

From: "Zheng"<[email-masked]>
Date: Thu, 12 Mar 2015 09:46:23 -0500

I guess glue in the scope of the zone data may be a proper subset of glue in the scope of "the message". What if zone A has the name server's name "below" the cut fall in the bailiwick of zone B, and both zones are hosted in one authoritative name server?  If that authoritative name server is allowed to place the address (in zone B) of the name server (zone cut in zone A) in a referral response, is that a case of glue in "the message" but not glue in the zone data?

Best regards,
Zheng Wang

发件人："Niall O'Reilly" <[email-masked]>
发送时间：2015-03-12 08:07
主题：[DNSOP] DNS Terminology: Glue
收件人："Paul Hoffman"<[email-masked]>
抄送："IETF DNSOP WG"<[email-masked]>

  Hi. 

  Best regards, 
  Niall O'Reilly 

_______________________________________________ 
DNSOP mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Mar 2015 09:53:48 -0400

Its a bug in the spec.

Glue records should never have existed and they have caused nothing but
implementation confusion.

I understand the reasons why people imagine they are justified. But a
mistake is still a mistake.

At this point we cannot get rid of them.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Mar 2015 07:42:06 -0700

> Its a bug in the spec.

The terminology document is the wrong place to deal with bugs in the spec. We are happy to list differences of opinion about what a term means if they appear in different RFCs, but not to try to fix bugs.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Mar 2015 10:47:47 -0400

On Thu, Mar 12, 2015 at 10:42 AM, Paul Hoffman <[email-masked]>
wrote:

> The terminology document is the wrong place to deal with bugs in the spec.
> We are happy to list differences of opinion about what a term means if they
> appear in different RFCs, but not to try to fix bugs.
>
> --Paul Hoffman

Maybe.

But what might help clear up some of the confusion would be to redefine
them as pseudo-records rather than DNS RRs.

The problem with glue records is that they are not properly in the DNS name
space. They do not originate from the server that is authoritative for the
zone in question. They cannot and should not be used for any purpose other
than interpreting the zone delegation passed in the same message.

The terminology document might be the wrong place to admit that they are a
bad idea but we can flag them as not being part of the Internet DNS name
space.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Mar 2015 08:21:59 -0700

On Mar 12, 2015, at 7:47 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 
> 
> On Thu, Mar 12, 2015 at 10:42 AM, Paul Hoffman <[email-masked]> wrote:

No, definitely. If the WG wants to fix bugs, it should do so in a standards-track document.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Mar 2015 08:27:44 -0700

>  message" rather than in that of the zone data is likely to lead to

Quite right. We'll fix this in the next draft.

--Paul Hoffman

---

From: Patrik Wallström <[email-masked]>
Date: Thu, 12 Mar 2015 18:53:08 +0100

> Quite right. We'll fix this in the next draft.

While working on the Zonemaster test specifications we decided to go even further in order to differentiate between names and addresses, calling those “glue address records” and “glue name records”:

Glue Name Records are defined as all NS records pertaining to the child domain that are delivered by the nameservers for the parent domain.

Glue Address Records are all A or AAAA records pertaining to the child domain that are delivered by the nameservers for the parent domain

These terms are then later used to describe what kind of DNS data we are actually testing.

https://github.com/dotse/zonemaster/blob/master/docs/specifications/tests/MasterTestPlan.md#definitions-of-terms

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Mar 2015 17:59:49 +0000

Patrik Wallström <[email-masked]> wrote:
>
> Glue Name Records are defined as all NS records pertaining to the child
> domain that are delivered by the nameservers for the parent domain.
>
> Glue Address Records are all A or AAAA records pertaining to the child
> domain that are delivered by the nameservers for the parent domain

That's nice and clear.

I use the term "delegation NS records" and reserve "glue records" for the
address records.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: South or southwest 6 to gale 8, veering northwest 4 or 5 for a time.
Very rough or high. Rain then showers. Good, occasionally poor.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Mar 2015 11:10:17 -0700

> I use the term "delegation NS records" and reserve "glue records" for the

My reading of 1034 is the same as Tony's. I don't seen in 1034 where the delegating NS records would qualify as "glue" at all.

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 13 Mar 2015 11:57:30 +0000

> No, definitely. If the WG wants to fix bugs, it should do so in a standards-track document.

Paul is correct.  While the discussion of Glue (or the lack thereof) is 
a flaw in the documents, it should not be fixed in this document.

tim

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 13 Mar 2015 14:53:59 +0000

On Thu, 12 Mar 2015 17:53:08 +0000,
Patrik Wallström wrote:
> 
> While working on the Zonemaster test specifications we decided to go
> even further in order to differentiate between names and addresses,
> calling those “glue address records” and “glue name records”:
> 
> Glue Name Records are defined as all NS records pertaining to the
> child domain that are delivered by the nameservers for the parent
> domain.

  This seems to be a new, product-specific extension of the definition
  of the term "glue".  I think it can only lead to confusion.

  Rather than do so here, I'll follow up in my response to the
  questionnaire mentioned by Sandoche
  (Message-ID: <[email-masked]>) at
  https://fr.surveymonkey.com/r/zonemaster.

  Best regards,
  Niall O'Reilly

---

From: Shumon Huque <[email-masked]>
Date: Fri, 13 Mar 2015 11:39:56 -0400

> Quite right. We'll fix this in the next draft.

It might be worth also clarifying another thing. The definition states
"These
RRs are only necessary if", but doesn't clearly include or exclude the
possibility
that other address records for NS names that don't sit below the zone cut,
and
were gratuitously provided in the referral response, qualify to be  called
'glue'. I
think  they should not be called glue (they don't meet my intuitive
understanding
of the meaning of 'glue', as gluing up a hole in the resolution path). But
clarity on
this point would be welcome.

Shumon Huque

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2015 09:00:34 -0700

On Mar 13, 2015, at 8:39 AM, Shumon Huque <[email-masked]> wrote:
> It might be worth also clarifying another thing. The definition states "These
> RRs are only necessary if", but doesn't clearly include or exclude the possibility
> that other address records for NS names that don't sit below the zone cut, and 
> were gratuitously provided in the referral response, qualify to be  called 'glue'. I 
> think  they should not be called glue (they don't meet my intuitive understanding 
> of the meaning of 'glue', as gluing up a hole in the resolution path). But clarity on 

If there is a well-accepted name for "address records that come with glue records but are not actually glue records", we can add it, but I am hesitant for this document becoming a list of things observed in the wild that don't already have names.

FWIW, what we tentatively have for the next draft is:

   Glue records -- Resource records which are not part of the
   authoritative data [for a zone], and are address resource records for
   the servers [in a subzone].  These RRs are only necessary if the name
   server's name is "below" the cut, and are only used as part of a
   referral response.  (Definition from RFC 1034, section 4.2.1)

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Mar 2015 16:05:24 +0000

Shumon Huque <[email-masked]> wrote:
> "These RRs are only necessary if", but doesn't clearly include or
> exclude the possibility that other address records for NS names that
> don't sit below the zone cut, and were gratuitously provided in the
> referral response, qualify to be called 'glue'. I think they should not
> be called glue (they don't meet my intuitive understanding of the
> meaning of 'glue', as gluing up a hole in the resolution path). But
> clarity on this point would be welcome.

In the additional section of a referral, address records for name servers
that are not in the delegated zone are not glue records. This is implied
by RFC 1034 section 4.3.2:

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step 4.

Section 4.2.1 classifies zone data into authoritative data, apex
authoritative data, delegations, and glue, and says glue is
non-authoritative. It also says glue records are only used as part of a
referral response, which is not the case for authoritative name server
address records.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, Faeroes, Southeast Iceland: Southerly 5 to 7, occasionally gale 8
in Faeroes, and occasionally severe gale 9 in Southeast Iceland. Very rough or
high, occasionally very high later in Southeast Iceland. Occasional rain, fair
for a time. Moderate or poor, occasionally good.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 13 Mar 2015 12:21:19 -0400

>             data or the cache.  Go to step 4.

Ah, right. I see the implication. That's good. What I'd like to see is
something
clearer than the implication in the terminology draft definition. After
all, one
of the goals is to clear up confusion about the terms.

> referral response, which is not the case for authoritative name server

But a nameserver could also return a referral with address records that
aren't glue, but that they also aren't authoritative for (that sit in some
other
zone) - I believe these exist in the wild. I'm okay with not having a name
for such things (Paul's desire), but it would be nice to definitively
exclude
them from the definition of glue records.

Shumon Huque.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 13 Mar 2015 16:33:35 +0000

On Fri, Mar 13, 2015 at 09:00:34AM -0700, Paul Hoffman wrote:
> If there is a well-accepted name for "address records that come with glue
> records but are not actually glue records", we can add it, but I am
> hesitant for this document becoming a list of things observed in the wild
> that don't already have names.
> 

Given the amount of discussion this topic has generated, and the number of
ways I've seen the word used in the past (and, in fact, have used it myself
when speaking imprecisely), a discursive paragraph about common misuses
might be helpful.  Like:

        The term "glue" is sometimes incorrectly used to refer to 
        other resource records in a parent zone that are related to a
        delegation, such as address records included with a referral
        which are not strictly necessary due to the server's domain
        name falling below the zone cut, the authoritative delegation
        (NS), or the delegation signer (DS).

This could help newcomers to the DNS to understand what they're reading
when they encounter terms like "NS glue", but it still stakes out a clear
definition of the word.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2015 09:55:45 -0700

> when they encounter terms like "NS glue", but it still stakes out a clear

This seems like a good addition. We would like the terminology draft to be both definitions of terms and common mis-definitions. Do others have thoughts on Evan's proposed addition?

--Paul Hoffman

---

From: Shumon Huque <[email-masked]>
Date: Fri, 13 Mar 2015 13:00:18 -0400

On Fri, Mar 13, 2015 at 12:55 PM, Paul Hoffman <[email-masked]>
wrote:

> This seems like a good addition. We would like the terminology draft to be
> both definitions of terms and common mis-definitions. Do others have
> thoughts on Evan's proposed addition?
>
>
Works for me. I like it.

Shumon Huque

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 13 Mar 2015 17:20:26 +0000

> This seems like a good addition. We would like the terminology draft to be both definitions of terms and common mis-definitions. Do others have thoughts on Evan's proposed addition?

Removing my hat as chair, I personally like Evan's additions.

tim

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Mar 2015 18:12:30 +0000

>   referral response.  (Definition from RFC 1034, section 4.2.1)

One of my rules about definitions is to start with a positive and not a
negative statement.

Glue records -- Resource records in a zone falling adhering to some
specific conditions.  Glue records are address records for name servers
mentioned in zone cuts in the zone and for names below some (the same one
another) zone cut in the zone, hence are not authoritative in the zone.
These records are considered hints of the address of a name server
included in a referral.  The definition of glue records is arguable
confusing and unclear, some historical usage applies the term to the name
server records at a zone cut (in part because these records too are not
considered authoritative data).

I'm not sure my wording is much better, perhaps just different.  Mostly, I
urge avoiding "which are not" as part of the opening line of the
definition.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Mar 2015 18:20:22 +0000

On 3/13/15, 12:55, "Paul Hoffman" <[email-masked]> wrote:
>
>This seems like a good addition. We would like the terminology draft to
>be both definitions of terms and common mis-definitions. Do others have

Much more useful that (Evan's) way.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2015 12:34:10 -0700

> One of my rules about definitions is to start with a positive and not a

Noted, but the higher-order rule we are using for this document is "quote the RFCs where possible". In fact, this particular thread was caused by us being close to, but not exactly on, the definition from 1034.

> considered authoritative data).

This definition is more inclusive than what is in 1034, and thus (I think) inappropriate. That is, it says "what 1034 said, plus these other things". As this thread has show, there is a desire for the most narrow definition. Given that other RFCs require a consistent view of what is a glue record, widening it at this late date seems ill-advised.

--Paul Hoffman

---

From: Casey Deccio <[email-masked]>
Date: Fri, 13 Mar 2015 16:13:56 -0400

On Thu, Mar 12, 2015 at 2:10 PM, Paul Hoffman <[email-masked]> wrote:

> My reading of 1034 is the same as Tony's. I don't seen in 1034 where the
> delegating NS records would qualify as "glue" at all.
>
>
I use the same terminology also (i.e., "delegation NS records" vs. "glue
records").

But it should be noted that within existing RFCs the terminology differs:

RFC 1034 4.2.1:

    ..."glue" RRs which are not
    part of the authoritative data, and are address RRs for the servers.

RFC 1034 4.2.2:

   ...delegation NS RRs and glue RRs

but:

RFC 2181 5.4.1:

   "Glue" above includes any record in a zone file that is not properly
   part of that zone, including nameserver records of delegated sub-
   zones (NS records), address records that accompany those NS records
   (A, AAAA, etc), and any other stray data that might appear.

It's unclear whether "'glue' above" means "glue, for the purposes of this
document" or "glue, which we are restating the definition of", but it
sounds to me like the latter.  In any case, the definition differs from
that previously stated (and my own understanding).

Casey

---

From: Casey Deccio <[email-masked]>
Date: Fri, 13 Mar 2015 16:21:06 -0400

> thoughts on Evan's proposed addition?

It is a helpful addition.

It seems like a reference to delegation NS records is also in order, based
on previous discussion:

From:
"... the authoritative delegation (NS)..."

To:
"... delegation or authoritative name server (NS) records (i.e., above or
below the zone cut)..."

Regards,
Casey

---

From: Shumon Huque <[email-masked]>
Date: Fri, 13 Mar 2015 17:31:51 -0400

> that previously stated (and my own understanding).
Interesting. RFC 2181, being 'Clarifications to the DNS spec' probably
carries
some weight, and lends support to Patrik Wallstrom's view that these could
be
called glue name(server) records. This also doesn't violate an intuitive
understanding
of the term glue, so I would not be opposed.

(Yes, I also usually call them delegation NS records.)

Shumon Huque

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Mar 2015 21:32:39 +0000

> "... delegation or authoritative name server (NS) records (i.e., above or

I prefer "apex NS records" for the ones below the zone cut. RFC 1034 uses
"top node" - it seems the term "apex" was introduced with DNSSEC.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall: South 6 to gale 8, occasionally severe gale 9 for a time. Very rough
or high. Rain later. Moderate.

---

From: Casey Deccio <[email-masked]>
Date: Fri, 13 Mar 2015 18:05:19 -0400

> "top node" - it seems the term "apex" was introduced with DNSSEC.
I could (alternatively) go for the use of "top node", e.g.,

"... delegation name server (NS) records or those at the top node (i.e.,
above or below the zone cut)..."

because RFC 1034 4.2.1 includes it as part of authoritative data (referring
to NS and SOA records):

"Data that defines the top node of the zone (can be thought of as part of
the authoritative data)."

Although, still "authoritative" seems to me more intuitive than "top node".

"Zone apex" seems ill-defined.  In namespace terms, a name is a name and
corresponds to a node in the namespace tree.  However, RFC 4033 (section 2)
seems to make "delegation point" and "zone apex" appear as though they were
two different nodes:

   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.

But in the definition of "Authoritative RRset" "zone apex" is being used to
refer to both sides of the cut:

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

I would not use "apex" for this reason.

Casey

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2015 16:00:26 -0700

Casey noticing the updated, wider definition in 2181 kinda throws a wrench into the "what is not glue" discussion. Here is a proposed update to the draft that includes both definitions and discusses the ramifications of the update.

   A later definition is that glue "includes any record in a zone file
   that is not properly part of that zone, including nameserver records
   of delegated sub-zones (NS records), address records that accompany
   those NS records (A, AAAA, etc), and any other stray data that might
   appear".  (Definition from RFC 2181, section 5.4.1) This definition
   in RFC 2181 is wider than the one from RFC 1034, and bases the
   definition on the contents of a zone file.  Some implementers might
   only be thinking about the earlier definition when they see rules
   about glue records.

--Paul Hoffman

---

From: Casey Deccio <[email-masked]>
Date: Fri, 13 Mar 2015 22:22:06 -0400

On Fri, Mar 13, 2015 at 7:00 PM, Paul Hoffman <[email-masked]> wrote:

> Casey noticing the updated, wider definition in 2181 kinda throws a wrench
> into the "what is not glue" discussion. Here is a proposed update to the
> draft that includes both definitions and discusses the ramifications of the
> update.
>

 In the spirit of the statement (from the terminology draft):

"Some of the definitions differ from earlier RFCs, and those differences
are noted."

I think noting the definitions in the two RFCs is good, but additional
clarity is necessary to avoid perpetuating further confusion.

The RFC 2181 definition of glue is under the section clarifying rules for
"Data ranking".  Whether it is attempting to restate the definition of glue
generally or define glue for the the scope of this section/document alone,
that is not the focus of the section.

Anyway, this is clearly at odds with RFC 1034's definition.  For example,
RFC 1034 states that "[glue] RRs are only necessary..."--but delegation NS
records are always necessary (i.e., there is no "if...").  Also, the RFC
1034 (section 4.2.1) text immediately preceding that quoted in the "Glue
records" states:

"In particular, if the name of the name server is itself in the subzone, we
could be faced with the situation where the NS RRs tell us that in order to
learn a name server's address, we should contact the server using the
address we wish to learn. To fix this problem, a zone contains 'glue'
RRs...".

Understanding the motivation for glue helps us understand the definition of
glue, which is clearly for the address records.

Here is some proposed rewording that attempts to capture that:

Glue records -- Records "which are not part of the
   authoritative data [for a zone], and are address resource records for
   the servers [in a subzone].  These RRs are only necessary if the name
   server's name is "below" the cut, and are only used as part of a
   referral response.  Without glue "we could be faced with the situation
   where the NS RRs tell us that in order to learn a name server's
   address, we should contact the server using the address we wish to
   learn." (Definition from RFC 1034, section 4.2.1)

   The term "glue" is sometimes incorrectly used to refer to
   other resource records that are related to a
   delegation, such as address records included with a referral
   which are not strictly necessary due to the server's domain
   name falling below the zone cut, delegation or authoritative
   name server (NS) records (i.e., above or below the zone
   cut), or delegation signer (DS) records.

   RFC 2181 (section 5.4.1) denotes glue as "any record in a zone file
   that is not properly part of that zone, including nameserver records
   of delegated sub-zones (NS records), address records that accompany
   those NS records (A, AAAA, etc), and any other stray data that might
   appear".   This definition is explicitly applied to the use of the term
   within the document itself.  However, its application beyond the
document is
   questionable because of its contrast with both the motivation for an
definition of
   glue in RFC 1034.

Regards,
Casey