Subject: Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 15 Dec 2021 21:17:42 +0000

Despite what the subject line says, I’d like to follow up on the discussion about glue from today’s interim meeting.

First, I think the definition of glue given in RFC 2181 is problematic in a number of ways.  It is overly broad (e.g., "any record ... that is not properly part of that zone” and "any other stray data that might appear”).  It essentially says that all non-authoritative data is glue, including NS, which is wrong IMO.

If we can ignore what 2181 says, then the question is whether or not glue is limited only to addresses.  Historically it has only meant addresses, since those address RRs were required for zones with in-domain name servers.  There are some new proposals in DPRIVE to publish more record types in parent zones and have them considered as glue.  This has obvious implications server behavior given the glue-is-not-optional draft.

On one hand I think it would be a lot simpler to just say that only address records can be glue.  But I’m not sure that is defendable given the directions things are going.  Here’s a definition of glue that I came up with:

Glue is non-authoritative data in a zone that is transmitted in the additional section of a referral response on the basis that the data might be necessary for resolution to proceed at the referred name servers.

I also feel like we might be heading in a direction where there would need to be a registry or some standardization of which RR types can be treated as glue.

DW

---

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Dec 2021 14:01:16 -0800

Wessels, Duane wrote on 2021-12-15 13:17:
> ...
> ...

if glue is non-authoritative data in a zone then it has to be below a 
zone cut; you might make that clear.

if glue is in a zone it will be carried by zone transfers not just 
referrals; you might make that clear.

otherwise, +1.

vixie

---

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Dec 2021 15:10:50 -0800

On Wed, Dec 15, 2021 at 2:01 PM Paul Vixie <paul=
[email-masked]> wrote:

> > On one hand I think it would be a lot simpler to just say that only
> address records can be glue.  But I’m not sure that is defendable given the
> directions things are going.  Here’s a definition of glue that I came up
> with:
> >
> > Glue is non-authoritative data in a zone that is transmitted in the
> additional section of a referral response on the basis that the data might
> be necessary for resolution to proceed at the referred name servers.
> >
> > ...
>

Overly-pedantic clarification on wording/semantics:

   - Glue is non-authoritative data in a zone, where the owner name of that
   glue data is below some zone cut (or otherwise out-of-zone, like
   different-TLD, if that is even permitted by the zone owner's policies.)

> referrals; you might make that clear.
Also +1.

Brian

---

From: Joe Abley <[email-masked]>
Date: Wed, 15 Dec 2021 18:16:55 -0500

On Dec 15, 2021, at 18:11, Brian Dickson <[email-masked]> wrote:

> Glue is non-authoritative data in a zone, where the owner name of that glue data is below some zone cut (or otherwise out-of-zone, like different-TLD, if that is even permitted by the zone owner's policies.)
I think with that text you just introduced three more terms that need a definition ("glue data", "out-of-zone" and "different-TLD").

Joe

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Dec 2021 15:18:31 -0800

I like this definition.  However, I think it would be clearer to say
"useful" instead of "necessary".

On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane <dwessels=
[email-masked]> wrote:

> Despite what the subject line says, I’d like to follow up on the
> discussion about glue from today’s interim meeting.
>
> First, I think the definition of glue given in RFC 2181 is problematic in
> a number of ways.  It is overly broad (e.g., "any record ... that is not
> properly part of that zone” and "any other stray data that might appear”).
> It essentially says that all non-authoritative data is glue, including NS,
> which is wrong IMO.
>
> If we can ignore what 2181 says, then the question is whether or not glue
> is limited only to addresses.  Historically it has only meant addresses,
> since those address RRs were required for zones with in-domain name
> servers.  There are some new proposals in DPRIVE to publish more record
> types in parent zones and have them considered as glue.  This has obvious
> implications server behavior given the glue-is-not-optional draft.
>
> I also feel like we might be heading in a direction where there would need
> to be a registry or some standardization of which RR types can be treated
> as glue.
>
> DW
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 15 Dec 2021 23:56:15 +0000

For me “necessary” is an important distinction and “might be useful” is too broad or ambiguous.  I have a hard time reconciling the idea that glue is not optional with the idea that it might be useful.

DW

> On Dec 15, 2021, at 3:18 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> 
> I like this definition.  However, I think it would be clearer to say "useful" instead of "necessary".
> 
> On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane <dwessels=[email-masked]> wrote:

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 15 Dec 2021 19:08:41 -0500

(no hats)

I feel that "might be useful" leaves the definition still ambiguous.

I like Paul V's additions on where the glue must reside, and noting that it
will be passed along with transfers.

tim

On Wed, Dec 15, 2021 at 6:56 PM Wessels, Duane <dwessels=
[email-masked]> wrote:

> For me “necessary” is an important distinction and “might be useful” is
> too broad or ambiguous.  I have a hard time reconciling the idea that glue
> is not optional with the idea that it might be useful.
>
> DW
>
>
> > First, I think the definition of glue given in RFC 2181 is problematic
> in a number of ways.  It is overly broad (e.g., "any record ... that is not
> > If we can ignore what 2181 says, then the question is whether or not
> glue is limited only to addresses.  Historically it has only meant
> addresses, since those address RRs were required for zones with in-domain
> name servers.  There are some new proposals in DPRIVE to publish more
> record types in parent zones and have them considered as glue.  This has
> obvious implications server behavior given the glue-is-not-optional draft.
> >
> > I also feel like we might be heading in a direction where there would
> need to be a registry or some standardization of which RR types can be
> treated as glue.
> >
> > DW
> >
> >

---

From: George Michaelson <[email-masked]>
Date: Thu, 16 Dec 2021 10:31:06 +1000

This is one of those times where classic email quoting isn't helping
my brain. Maybe I'm alone, but I think there may be others in a
similar situation.

We're close to a discussion of very specific language. I think the
best thing is for people to state once, in their level of indentation
(ie "top") *EXACTLY* what specific language they think we need here.

Say the text. All of it (that you want to discuss) as you want it to
be in the document. Even if it becomes repetitious, I am struggling to
maintain context over the words and what they mean, under the latest
edit.

cheers

-G

On Thu, Dec 16, 2021 at 10:09 AM Tim Wicinski <[email-masked]> wrote:
> I like Paul V's additions on where the glue must reside, and noting that it will be passed along with transfers.
>
> tim
>
>
>
>
> On Wed, Dec 15, 2021 at 6:56 PM Wessels, Duane <dwessels=[email-masked]> wrote:
>>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Dec 2021 20:31:26 -0500

On Dec 15, 2021, at 18:56, Wessels, Duane <dwessels=[email-masked]> wrote:
> 
> For me “necessary” is an important distinction and “might be useful” is too broad or ambiguous.  I have a hard time reconciling the idea that glue is not optional with the idea that it might be useful

Necessary for resolving, securely resolving and/or resolving with privacy ?

In other words, would a TLSA or SVCB be “necessary” or not ?

Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 16 Dec 2021 08:49:29 +0530

On Wed, Dec 15, 2021 at 09:17:42PM +0000, Wessels, Duane wrote:
> in a number of ways.  It is overly broad (e.g., "any record ... that
> is not properly part of that zone” and "any other stray data that
> might appear”).  It essentially says that all non-authoritative data
> is glue, including NS, which is wrong IMO.
> 
> addresses, since those address RRs were required for zones with
> in-domain name servers.  There are some new proposals in DPRIVE to
> publish more record types in parent zones and have them considered as
> glue.  This has obvious implications server behavior given the
> glue-is-not-optional draft.
> 
> address records can be glue.  But I’m not sure that is defendable
> given the directions things are going.  Here’s a definition of glue
> that I came up with:
> 
> additional section of a referral response on the basis that the data
> might be necessary for resolution to proceed at the referred name
> servers.
> 

RFC 5936 (the AXFR RFC) section 3.5 calls names under a zonecut, but
part of the (parent) zone as "occluded names". It can happen with both
NS cuts and existence of DNAME:

> 3.5.  Occluded Names

>    Dynamic Update [RFC2136] operations, and in particular their
>    interaction with DNAME [RFC2672], can have a side effect of occluding
>    names in a zone.  The addition of a delegation point via dynamic
>    update will render all subordinate domain names to be in a limbo,
>    still part of the zone but not available to the lookup process.  The
>    addition of a DNAME resource record has the same impact.  The
>    subordinate names are said to be "occluded".

>    Occluded names MUST be included in AXFR responses.  An AXFR client
>    MUST be able to identify and handle occluded names.  The rationale
>    for this action is based on a speedy recovery if the dynamic update
>    operation was in error and is to be undone.

Though records with occluded names are considered "glue", there is a
semantic difference in the context in which the term "glue" is used
vs. occluded names - in that "glue is used in connecting the zone cuts".

Clarification with extra description is good. I don't know if the
currently accepted liberal meaning should be restricted further.

		Mukund

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 16 Dec 2021 10:45:17 -0800

> is not optional with the idea that it might be useful.

My view is less like "might be useful for reaching the nameserver", and
more like "intended for use in connecting to the nameserver".  A record is
"glue" if it is provided for the purpose of helping the resolver connect to
the nameserver indicated in the NS record.

"Necessary" doesn't work, in my view.  Whenever there are multiple A or
AAAA glue RRs, each RR is not individually "necessary".   Any glue AAAA
RRSet is basically never "necessary".

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 16 Dec 2021 18:46:35 +0000

> On Dec 15, 2021, at 5:31 PM, Paul Wouters <[email-masked]> wrote:
> 

Well, that is why I feel that we’re heading in a direction where the IETF will have to say which RR types must be considered as glue (aka necessary).  Today it's just A and AAAA, but if some of the proposals in DPRIVE achieve consensus then maybe those other types become designated as glue.

DW

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Dec 2021 10:55:26 -0800

Ben Schwartz wrote on 2021-12-16 10:45:
> On Wed, Dec 15, 2021 at 3:56 PM Wessels, Duane 
> <dwessels=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     For me “necessary” is an important distinction and “might be useful”
>     is too broad or ambiguous.  I have a hard time reconciling the idea
>     that glue is not optional with the idea that it might be useful.
> 
> 
> more like "intended for use in connecting to the nameserver".  A record 
> is "glue" if it is provided for the purpose of helping the 
> resolver connect to the nameserver indicated in the NS record.

the AAAA or A RRsets which are beneath delegation points will never be 
answered authoritatively by the zone's servers. they will either come as 
referral glue when asking for other names at/below that delegation 
point, or they will come as referral glue when asking for them by name.

so they do seem "necessary" since there is no other way to get them from 
the zone's servers except by asking a question which inspires the server 
to add them to the additional data section of a referral response.

of course, they may be held as glue higher up the hierarchy. for example 
we might get ns-ext.vix.com's AAAA/A RR from the root or COM servers 
when forwarding a question for www.vix.com to one of those servers. but 
if it doesn't come from there, it had better come from vix.com's 
servers, but since it's below a delegation point, it can only be sent by 
the vix.com zone servers as additional data in a referral response.

perhaps the nomenclature should be "referral glue" to drive home the 
point about where it will appear, and disambiguate from whatever DPRIVE 
is thinking about, and avoid the use of the words "necessary" or "useful".

> RRSet is basically never "necessary".

i think that's a corner case, unworthy of the complexity of describing 
it. if there is only one name server for a zone, and it has only one 
kind of IP connectivity, then that one AAAA (or A) RRset will be 
"neccessary". this highlights the benefit of not using words like 
"necessary" or "glue" since they drag in unnecessary outer concepts.

vixie