Subject: [DNSOP] terminology: glue

From: Casey Deccio <[email-masked]>
Date: Mon, 4 May 2015 10:32:36 -0400

I am still a bit uncomfortable with the -01 definition of glue,
specifically the reference to RFC 2181.  I think the reference to RFC 2181
is useful and necessary, but I hesitate to think that RFC 2181's use of
glue is a redefinition that is intended to apply outside of the RFC
itself.  That is, I believe the term was overloaded (similar to the
apparent overloading of "label" discussed in another recent dnsop thread).

Here is some proposed re-wording (modified from a previous proposal), which
both adds more context (quoted from earlier RFC 1034 text) for the use of
glue to the first paragraph and gives less weight to the RFC 2181 reference
in the second.

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)

   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" ([RFC2181], section 5.4.1).  Although glue is sometimes used
   today with this wider definition in mind, the context surrounding the
   RFC 2181 definition suggests it is intended to apply to the use of glue
   within document itself and not necessarily beyond.

---

From: Steve Crocker <[email-masked]>
Date: Mon, 4 May 2015 12:27:01 -0400

Glue records are necessary to prevent circular references, i.e. to cut the loop.  The most obvious and common situation is where the name server is below the cut.  If the address of the name server were not included, the querying system would keep being referred to the parent, i.e. stuck in a loop of length 1.  It is also possible to have loops of length 2 or more, though these will be quite rare.  If the name servers for A are below B, and the name servers for B are below A, if glue records are not included for either, the querier will bounce back and forth between A and B without ever succeeding.

It would be nice if the definition of glue records included the complete picture, though that might make it harder for people to understand the basic case.  So, a brief bit of explanatory and example text in addition to the formal definition would also be advisable.

Steve

On May 4, 2015, at 10:32 AM, Casey Deccio <[email-masked]> wrote:

> I am still a bit uncomfortable with the -01 definition of glue, specifically the reference to RFC 2181.  I think the reference to RFC 2181 is useful and necessary, but I hesitate to think that RFC 2181's use of glue is a redefinition that is intended to apply outside of the RFC itself.  That is, I believe the term was overloaded (similar to the apparent overloading of "label" discussed in another recent dnsop thread).
> 
> Here is some proposed re-wording (modified from a previous proposal), which both adds more context (quoted from earlier RFC 1034 text) for the use of glue to the first paragraph and gives less weight to the RFC 2181 reference in the second.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Mon, 04 May 2015 12:01:21 -0700

Steve Crocker wrote:
> Glue records are necessary to prevent circular references, i.e. to cut the loop.  ...

after kashpureff, circular references are no longer allowed. XYZ.NET
cannot have only nameservers named within within XYZ.ORG, if XYZ.ORG has
only name servers named within XYZ.NET. that's because, due to cache
poisoning risks, out-of-zone glue must be in-bailiwick for the delegator.

i see no reason not to explain it this way in the terminology document,
even though this was an undocumented protocol change. (one of hundreds
of little things that you "just have to know", and this terminology
document would be a fine place to list some of those.)

-- 
Paul Vixie

---

From: Steve Crocker <[email-masked]>
Date: Mon, 4 May 2015 15:03:58 -0400

Paul,

Thanks.  I agree it’s good to explain this.  I’d rather it were explained in a document that purported to explain how things work instead of slipping it into a terminology document, but getting it written down somewhere is better than nowhere.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 May 2015 12:08:15 -0700

> Thanks.  I agree it’s good to explain this.  I’d rather it were explained in a document that purported to explain how things work instead of slipping it into a terminology document, but getting it…

Agree about "somewhere else". The terminology document is meant to describe terms briefly, not describe fully how the technology behind the term works. I'm sure that the community would benefit from a "How To Glue" document, and I doubt it would be only a few paragraphs, and I hope it would have lots of examples.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Tue, 05 May 2015 09:52:27 +1000

In message <[email-masked]>, Paul Hoffman writes
:
> > Thanks.  I agree it=92s good to explain this.  I=92d rather it were expla=
> ined in a document that purported to explain how things work instead of sli=
> pping it into a terminology document, but getting it written down somewhere=
>  is better than nowhere.
> 
> Agree about "somewhere else". The terminology document is meant to describe=
>  terms briefly, not describe fully how the technology behind the term works=
> . I'm sure that the community would benefit from a "How To Glue" document, =
> and I doubt it would be only a few paragraphs, and I hope it would have lot=
> s of examples.
> 
> --Paul Hoffman

B.T.W. named uses "manditory glue" and "sibling glue"

manditory glue: glue records beneath the zone being delegated which are
	referenced in the delegation.
sibling glue: is glue records that are in / below a sibling zone.

The source of bad instances of both of these are easy to track down as you
just check the parent zones.

Named allows both manditory and sibling glue.

Then there is "other glue" (if/when) we sign glue then these become
viable.

Named currently doesn't support other glue and removes it from
incoming zone transfers.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 May 2015 09:04:15 +0100

> poisoning risks, out-of-zone glue must be in-bailiwick for the delegator.

If the circle is big enough, however, it's possible to have circular
references without that actually being detected until the caches start
to expire on a Bad Day.

> i see no reason not to explain it this way in the terminology document,

I'm worried about document bloat, but I'm not unalterably opposed to
this.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 May 2015 15:45:27 +0100

>    within document itself and not necessarily beyond.

I like this wording.

Re "other stray data", can we conclude if it includes or excludes
occluded records (as in RFC 6672 section 5.2 and RFC 2136 paragraph 7.18)?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: Easterly 4 or 5 becoming cyclonic 6 to gale 8, occasionally severe
gale 9 later in west. Moderate becoming rough or very rough, then high later
in far west. Rain, fog patches. Moderate or good, occasionally very poor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 May 2015 08:00:15 -0700

>>   within document itself and not necessarily beyond.

Seems OK to me, and I like the fact that it keeps puts the quotations in context. Are there any objections?

> occluded records (as in RFC 6672 section 5.2 and RFC 2136 paragraph 7.18)?

I propose that we don't try to over-analyze RFC 2181 here, given that we are using the RFC 1034 definition as the more important one.

--Paul Hoffman

---

From: Casey Deccio <[email-masked]>
Date: Tue, 5 May 2015 11:40:43 -0400

>    within document itself and not necessarily beyond.

typo: there should be a "the" after "within".

Casey

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 07 May 2015 08:30:48 +0200

On 04-05-15 16:32, Casey Deccio wrote:
> specifically the reference to RFC 2181.  I think the reference to RFC
> 2181 is useful and necessary, but I hesitate to think that RFC 2181's
> use of glue is a redefinition that is intended to apply outside of the
> RFC itself.  That is, I believe the term was overloaded (similar to the
> Here is some proposed re-wording (modified from a previous proposal),
> which both adds more context (quoted from earlier RFC 1034 text) for the
> use of glue to the first paragraph and gives less weight to the RFC 2181
> reference in the second.
> 

This later definition reminds me a lot of what is later (in RFC 5936)
defined as occluded names.

Personally I like to consider glue as a special type of occluded data
(address records that are 'below' a zone cut).

Best regards,
  Matthijs

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 May 2015 10:40:23 +0100

> (address records that are 'below' a zone cut).

I think they are both different special cases of non-authoritative data in
a zone. The key difference is that a name server will serve glue but it
will not serve occluded records.

Non-authoritative data can be:
  delegation NS RRsets (served in authority sections of referrals)
  glue (served in additional sections of referrals)
  occluded by a zone cut (not served)
  occluded by a DNAME (not served)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: West 6 decreasing 4 or 5. Moderate or rough. Showers. Good.