Subject: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

From: [email-masked]
Date: Mon, 26 Jul 2021 14:06:15 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Glue In DNS Referral Responses Is Not Optional
        Authors         : M. Andrews
                          Shumon Huque
                          Paul Wouters
                          Duane Wessels
	Filename        : draft-ietf-dnsop-glue-is-not-optional-02.txt
	Pages           : 7
	Date            : 2021-07-26

Abstract:
   The DNS uses glue records to allow iterative clients to find the
   addresses of nameservers that are contained within a delegated zone.
   Authoritative Servers are expected to return all available glue
   records in referrals.  If message size constraints prevent the
   inclusion of all glue records in a UDP response, the server MUST set
   the TC flag to inform the client that the response is incomplete, and
   that the client SHOULD use TCP to retrieve the full response.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-glue-is-not-optional-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Puneet Sood <[email-masked]>
Date: Tue, 27 Jul 2021 11:42:19 -0400

Couple of comments and a readability suggestion

* +1 to Geoff Huston's request to provide justification for why
sibling glue is desirable in a response. Also would prefer to not make
it mandatory in a referral response. If the sibling glue is referring
to a dns operator, it is possible that the resolver already has seen
the nameserver names before and has the needed A/AAAA records in
cache. Truncation in this case would require a redundant query.

* Section 5: Promoted or orphan glue
The considerations for handling orphan glue will be different for a
TLD vs a lower level zone within a domain. I would think that orphan
glue in a TLD context should go away when a zone is deleted/expired.
Maybe even have sanity checking to prevent such an operation.

A readability suggestion
* Move the description of all types of glue upfront before getting
into recommendations.
- real glue
- sibling glue
- loops with sibling
- orphaned glue
* Describe the recommendations for including glue.
This should also call out the scenario where different kinds of
glue/referrals are present in a response (glue, sibling glue). This is
implicit in the wording now.

-Puneet

On Mon, Jul 26, 2021 at 5:06 PM <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2021 16:15:03 -0400

It appears that Puneet Sood  <[email-masked]> said:
>it mandatory in a referral response. ...

I would prefer we completely remove the sibling glue, or at most move
it to an appendix of possbily useful minor improvements.

We say that authoritative servers MUST return all the glue, which is true
for real glue, but not true for sibling glue (unless the sibling is in
a loop which is not something to encourage.)  Let's not confuse people,
please.

>Maybe even have sanity checking to prevent such an operation.

This is a political question, not a technical one. If the DNS operator
has external knowledge that the orphan's domain has not been delegated
to someone else, you can make a case to leave the glue. The usual
example is a name in a TLD which has expired but is still in the grace period,
but it can happen anywhere someone delegates names; I run registries
at the third level like watkins-glen.ny.us.

I don't see how we can offer any more than general and vague advice here.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 Jul 2021 16:28:32 -0400

> I don't see how we can offer any more than general and vague advice here.

I agree, and I think the best plan is to remove any mention of it. Orphan glue is by definition not glue. It once was glue, but that has no bearing on how to craft a referral response. It's out of scope for this document.

At best, I think the term "orphan glue" belongs in a taxonomy concerned with registry terminology, not DNS terminology. And although one of the ways in which domain registries publish information is in the DNS, it's rarely a good idea to conflate the two.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Tue, 27 Jul 2021 13:44:28 -0700

On Tue, Jul 27, 2021 at 1:29 PM Joe Abley <[email-masked]> wrote:

> I agree, and I think the best plan is to remove any mention of it. Orphan
> glue is by definition not glue. It once was glue, but that has no bearing
> on how to craft a referral response. It's out of scope for this document.
>
> At best, I think the term "orphan glue" belongs in a taxonomy concerned
> with registry terminology, not DNS terminology. And although one of the
> ways in which domain registries publish information is in the DNS, it's
> rarely a good idea to conflate the two.
>
>
I'd like to point out a (now moot) nit to the original comment(s): Instead
of TLD, it is probably more correct to refer to "Registry". E.g. in John
L's response about operating a third-level Registry, it isn't a TLD but is
still a Registry.

(I only point this out so that in future, any commentary that starts out
with someone writing "TLD", that they might correct themselves and write
"Registry".)

Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Jul 2021 07:19:09 +1000

> On 28 Jul 2021, at 06:15, John Levine <[email-masked]> wrote:
> 

The MUST is an instruction to developers.  It is not a comment on whether
the record is actually required or not because there is a circular dependancy.

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

---

From: Ralf Weber <[email-masked]>
Date: Wed, 28 Jul 2021 01:18:45 +0200

Moin!

> the record is actually required or not because there is a circular dependancy.
So if I see a MUST in an RFC it does not mean that this bit is required for
the protocol to work? That is not how I understand it. I agree with what
others have said that for DNS to work all real glue have to be presented.
Everything else, including sibling glue is optional and will make the
additional section bigger an hence more likely to get truncated.

I have no problem with authorities sticking sibling or even out of
zone glue in the additional section if they see fit. Resolver will
use or ignore that as they see fit and all of that if fine. However
requiring authorities to put unnecessary data in the additional section
(the sibbling glue) is not something I support.

So ong
-Ralf
——-
Ralf Weber

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Jul 2021 19:25:16 -0400

> a loop which is not something to encourage.)  Let's not confuse people,

Just to make sure we're talking about the same thing, the definition of
sibling glue is glue from another zone delegated from the same parent.
I'm mentioning this because there appeared to be confusion during
yesterday's meeting with the other case of cross zone glue from different
parents with circular dependence, a configuration which we explicitly say
cannot reliably work (and ultimately removed from the draft).

For sibling glue, part of our rationale was indeed to cover the cases where
it is required for resolution (and not just an optimization). Those configs
usually do involve a cycle. But our goal was not to encourage or
discourage such configurations, but to make it easier for implementers
of authoritative servers. Since many implementations already provide
sibling glue, it's easier to just provide them all, rather than figure out
which
are required or not.

> I don't see how we can offer any more than general and vague advice here.

Yeah, after thinking about this since yesterday, I'm now a little skeptical
that we
should cover this potentially thorny topic.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Jul 2021 19:26:52 -0400

> implicit in the wording now.

These are good suggestions Puneet. Thanks!

Shumon.

---

From: "John R Levine" <[email-masked]>
Date: 27 Jul 2021 20:32:09 -0400

>> a loop which is not something to encourage.)  Let's not confuse people, please.
>

That's not what the example in 4.1 of the draft shows.  It has foo.test 
depending on ns1.bar.test, so the server adds the A record for 
ns1.bar.test.

If we can't even agree what sibling glue is, perhaps we should snip it out.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Jul 2021 20:40:41 -0400

> depending on ns1.bar.test, so the server adds the A record for

It does actually.

foo.test and bar.test share the same parent zone (test).

Glue is returned in referrals from the parent zone. So this exactly matches
the definition I mentioned above.

"ns1.bar.test/A" is glue for "bar.test" (and sibling glue for "foo.test" in
that
example). It is returned by the servers for "test" in a referral for
"foo.test".

Open to suggestions for more clarifying language.

Shumon.

---

From: "John R Levine" <[email-masked]>
Date: 27 Jul 2021 20:47:23 -0400

>> depending on ns1.bar.test, so the server adds the A record for

Oh, sorry, I misread your message.

> "ns1.bar.test/A" is glue for "bar.test" (and sibling glue for "foo.test" in that
> example). It is returned by the servers for "test" in a referral for "foo.test".
>

Unless I'm misunderstanding something, in the absence of sibling glue, the 
resolver would make a second request for ns1.bar.test, same as if it were 
ns1.bar.otherdomain, and it would get back a referral with the glue.  It 
is just a performance tweak and I don't see why we should describe it as 
more than that.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Jul 2021 10:58:32 +1000

John,
	take the following delegations in the parent zone example.

	foo.example NS ns.bar.example
	ns.foo.example AAAA 2001:0DB8:0000:000b::1

	bar.example NS ns.foo.example
	ns.bar.example AAAA 2001:0DB8:0000:000b::2

If you don’t return sibling glue a query for b.foo.example returns
a referral of

	foo.example NS ns.bar.example

and a query for ns.bar.example returns a referral of 

	bar.example NS ns.foo.example

and the subsequent query for ns.foo.example  returns a referral of

	foo.example NS ns.bar.example

Returning sibling glue is not an optimisation.

> On 28 Jul 2021, at 10:47, John R Levine <[email-masked]> wrote:
> 
> Unless I'm misunderstanding something, in the absence of sibling glue, the resolver would make a second request for ns1.bar.test, same as if it were ns1.bar.otherdomain, and it would get back a referral with the glue.  It is just a performance tweak and I don't see why we should describe it as more than that.
> 
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 27 Jul 2021 22:47:21 -0400

> 	ns.bar.example AAAA 2001:0DB8:0000:000b::2

Well, OK.  How about this?

 	bar.example NS ns.abc.example
 	ns.bar.example AAAA 2001:0DB8:0000:000b::2

 	abc.example NS ns.def.example
 	ns.abc.example AAAA 2001:0DB8:0000:000b::3

 	def.example NS ns.foo.example
 	ns.def.example AAAA 2001:0DB8:0000:000b::4

(I would have gone all the way to ns.xyz.example but it's tine for bed here)

We don't try to make NS loops work across zones, so I don't see the point 
of sorta kinda trying to make them work sometimes.

It's kinder to make stuff just fail so people fix it than to make it 
sometiemes work, depending on what version of what software people's 
multicasted queries happen to land on.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Tue, 27 Jul 2021 23:06:27 -0400 (EDT)

On Tue, 27 Jul 2021, John R Levine wrote:

> We don't try to make NS loops work across zones, so I don't see the point of 
> sorta kinda trying to make them work sometimes.

You still mis thepoint. In the case of def.example needing
ns.foo.example, the server can just check if it has glue for
ns.foo.example. It does, so it returns it. It is not going to
check whether or not this is a silly loop to .xyz.example or
beyond. There is no point in knowing that. It has an NS record
pointing to X. It has a glue record for X. So it includes the glue
record X.

> multicasted queries happen to land on.

This is outside the scope of the document. Most DNS server will just
check if they have glue, and if so include it. The draft now makes a
statement on that glue - if it does not fit, set TC=1.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 27 Jul 2021 23:10:29 -0400 (EDT)

On Wed, 28 Jul 2021, Ralf Weber wrote:

> However requiring authorities to put unnecessary data in the additional section

First, as Mark said, sibling glue is sometimes needed.

Second, the server will most likely not know whether or not the glue
is needed, it will just include it so it does not have to follow the
complicated looping zones to determine if it is needed or not. Since it
does not know if it is needed or not, it cannot make a smart decision
on whether setting TC=1 is overkill or not. Thus the document saying
"also for sibling glue, just set TC=1 if it does not fit".

Paul

---

From: "John Levine" <[email-masked]>
Date: 28 Jul 2021 00:16:31 -0400

>pointing to X. It has a glue record for X. So it includes the glue

OK, so I ask for foo.example and I get 

; answer
; additional

Does it check that's the right value for ns.bar.example?  How about with DNSSEC?  I suppose

I still don't see the benefit of trying to make some loops work when we know that we
can't make cross-zone loops work.

R's,
John

---

From: George Michaelson <[email-masked]>
Date: Wed, 28 Jul 2021 14:24:35 +1000

I had it said to me, that "lies" about the ns.bar.example are not a
problem because if they can tell you a DNSSEC verified truth about the
primary request, you don't care who told you.

That can only  be truly not a concern, if the primary is DNSSEC
verified. So, for the non-DNSSEC, it feels like a substantial problem.
But then.. the only way out is to BE DNSSEC aware. There's not much
choice.

I'm not convinced this "glue doesn't have to be validated" thing is
true, but the problem latent in this is the recursive time/compute
cost of chasing all out-of-baliwick data, to verify its status in
DNSSEC.

Love to hear other people's POV on this. Maybe it is a false meme on
my part? Maybe glue HAS to be checked and validated, no matter what?

-G

---

From: Geoff Huston <[email-masked]>
Date: Wed, 28 Jul 2021 16:26:53 +1000

tldr - suggest cutting sections 4 and 5 completely and advancing with what’s left!

> On 28 Jul 2021, at 9:25 am, Shumon Huque <[email-masked]> wrote:
> 
> 
> sibling glue, it's easier to just provide them all, rather than figure out which
> are required or not.

The language of sections 2 and 3 are clear and purposeful. For DNS resolution to work
the glue records for “in-balliwick” name servers of a zone MUST be provided as glue records
in a DNS response. clear.

Section 4 in Sibling Glue ther heads into a different direction It notes that “In many
cases, these are not strictly required for resolution” but then simply adds them as a MUST 
be returned in referral responses without any apparent justification.

If this is an optimisation technique, then SHOULD or MAY, with some explanation, makes
more sense to me in this document. But frankly even this seems to be a different 
recommendation (and a different document) to me. 

Up to section 4, this document appears to be stating clearly an omission in the current
DNS spec, namely that all in-bailiwick name server names MUST be present as a Glue record in
a referral response for resolution to work.

And while I think about it, why not just refer to in-baliwick, as defined in RFC8499?

i.e. amend section 3 to read:...

3. Recommendations

This document clarifies RFC1034 in that in-bailiwick [RFC8499] glue (being part of all
available glue records) MUST be returned in referral responses, and there is a requirement
to set TC=1 if all in-bailiwick glue cannot fit in the response.

> Yeah, after thinking about this since yesterday, I'm now a little skeptical that we

Section 5 deviates away from protocol requirements into registry practice and
the deviation appears to be at best a somewhat random thought!

It makes no sense to me to even include sections 4 or  5 in this document.

regards,

   Geoff

---

From: Shumon Huque <[email-masked]>
Date: Wed, 28 Jul 2021 07:04:52 -0400

> a referral response for resolution to work.

Sibling glue was already covered in RFC 1034 (even though there was no term
for it). To quote
(Section 4.3.2, 3b):

            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.

Text was not as precise back then, but my reading of this is that the
nameserver should
put "whatever" addresses it has in the additional section. It says to
include glue RRs (defined
earlier as data that allows access to subzones), but doesn't differentiate
between glue below
the zone cut of the referral or glue it has for other subzones.

(An earlier section does say that glue is only necessary if it's below the
cut, but the
intent of the paragraph seems clear. Put "whatever" addresses I have in the
referral. And
"only necessary" doesn't address the corner cases we've described where
sibling glue is
required for resolution).

This paragraph also says to include addresses it may have from
authoritative data, which is
okay, but that's not glue, so we didn't cover it in the draft.

It also says 'addresses from cache' (mixed mode recursive/authoritative
servers were more
common then). This phrase should be deprecated in my opinion. Cached
addresses may
include things that are certainly out of bailiwick of the delegating zone,
and I assume would
likely be disregarded by most paranoid resolvers.

Shumon.

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 28 Jul 2021 13:51:35 +0200

Moin!

> First, as Mark said, sibling glue is sometimes needed.
It is only needed for broken circular dependancies, which we don’t 
care about.

> "also for sibling glue, just set TC=1 if it does not fit".
Ok that is not what the draft says. It says you must include sibbling
glue, no matter what. Setting TC=1 if you include sibling glue and it 
can not
fit it is something different. That probably makes sense for all 
referall
where glues don’t fit.

So long
-Ralf
—--
Ralf Weber

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Jul 2021 08:21:07 -0400

> It is only needed for broken circular dependancies, which we don’t care about.

I tend to agree with this. 

There are a lot of ways a delegation can be non-functional (for example the circle of dependencies can be as big as you like, can incorporate third cousin twice removed glue, etc) and it makes more sense to me to let all of these cases fail rather than incurring the cost of papering over just some of them in the authority server.

As many people have pointed out, recursive servers will often ignore Kaminsky-looking glue anyway, so the result of including it is going to be very much like intermittent failures that are painful to diagnose and have the effect of making the DNS less stable.

From this perspective it's a greater kindness to all concerned to fail consistently when such configurations are first deployed.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Jul 2021 10:13:46 -0400

> There are a lot of ways a delegation can be non-functional (for example the circle of dependencies can be as big as you like, can incorporate third cousin twice removed glue, etc) and it makes more…

Do you want dns servers to spend extra CPU power to lookup whether this is a “non-functional” glue case instead of spending less CPU just looking if it has a glue record and adding it?

If the latter, should it do this extra work of things don’t fit to determine the usefulness of TC=1 for this to set it depending those circumstances or just set TC=1 based on size ?

> From this perspective it's a greater kindness to all concerned to fail consistently when such configurations are first deployed.

Is that kindness worth spending more CPU cycles on the auth server?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Jul 2021 12:03:19 -0400 (EDT)

> It is only needed for broken circular dependancies, which we don’t care 

They are not broken until you decide "we don't care about" :)

> glue, no matter what. Setting TC=1 if you include sibling glue and it can not
> fit it is something different. That probably makes sense for all referall
> where glues don’t fit.

We will look at improving the wording in the draft. The draft is not
about changing the rules of glue - we just thought to include some of
it to help implementers and to help explain why it is important to set
TC=1 even if you think it is harmless to not include some or all glue.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Jul 2021 12:10:23 -0400 (EDT)

> to set TC=1 if all in-bailiwick glue cannot fit in the response.

I think the reasons for returning non-in-bailiwick are the same as for
in-bailiwick glue. You want to give the client as many DNS servers as
possible to increase resilience of the zone. What is your argument for
making this less resilient?

> It makes no sense to me to even include sections 4 or  5 in this document.

I guess what the document is trying to say is "this glue that is not
optional also applies to records that are technically not glue because
it is authoritative data". We really only want to mention that these
should still be added and TC=1 should still be set if it does not fit.

Paul

---

From: "John R Levine" <[email-masked]>
Date: 28 Jul 2021 12:20:15 -0400

On Wed, 28 Jul 2021, Shumon Huque wrote:
> for it). ...

Sure, but we've been cleaning up the ambiguities and errors in 1034 for 30 
years.  A straightforward reading of that paragraph also gives you the 
Kaminsky attack.

The simplest way to defend agaist cache poisoning is to accept only 
in-bailiwick glue which you can do with a string comparison.  If you're 
going to accept sibling glue, now you have to look up the tree and see if 
both names have the same parent.  That's not all that hard, but it's a big 
step up in implementation complexity from the string comparison.

How about this?

  foo.test NS abc.def.bar.test
  abc.def.bar.test A 10.11.12.13

but there's a zone cut at def.bar.test.  Is a nephew* still a sibling? 
What if that zone cut is in the PSL?  I have no idea and I don't think I 
want to find out.

"MUST" in RFC-ese means you have to do something in order to interoperate. 
I think we all agree that the DNS will operate fine without sibling glue, 
other than NS loops which I personally don't care about. That makes it at 
most a MAY, and I agree with Geoff's reasons to take it out completely.

Regards,

* - I don't know of an English word that means niece-or-nephew

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Jul 2021 13:35:31 -0400

Hi Paul,

> Do you want dns servers to spend extra CPU power to lookup whether this is a “non-functional” glue case instead of spending less CPU just looking if it has a glue record and adding it?

I'm not sure I understand your argument about what is more work for the authority server.

Checking whether a referral targets nameservers whose owner name is below the zone cut seems straightforward. This is work that authority-only servers already do. It also seems entirely possible to do this work at load time at which point it ought to be clear that the zone cut exists; it's not something that must happen at response time.

I don't see where the "extra CPU power" you are talking about comes from.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Jul 2021 14:00:32 -0400 (EDT)

On Wed, 28 Jul 2021, Joe Abley wrote:

> Checking whether a referral targets nameservers whose owner name is below the zone cut seems straightforward.

If the zone example contains amongst other content:

foo.example. IN NS ns0.foo.example.
foo.example. IN NS ns0.bar.example.
ns0.foo.example. IN A 1.2.3.4
ns0.bar.example. IN A 1.2.3.5

Then for the DNS server returning an NS query for foo.example, it is
easy to either:

1) return ns0.foo.example's A record

or

2) return ns0.foo.example and ns0.bar.example. A records`

What is harder to do is determining whether it should or should not
include ns0.bar.example's A record based on whether it is "needed" or
not, as there are various kinds of loops possible.

> This is work that authority-only servers already do.

I think I agree, that auth-only servers already do 1) or 2)

> I don't see where the "extra CPU power" you are talking about comes from.

To determine if the glue you know you have is "needed or not".

Paul

---

From: Ralf Weber <[email-masked]>
Date: Wed, 28 Jul 2021 20:02:34 +0200

Moin!

> They are not broken until you decide "we don't care about" :)
I don’t think I was the only one ;-).

> TC=1 even if you think it is harmless to not include some or all glue.
That is something I can agree to. If the glues you as an authoritative
server want to put in a UDP packet don’t fit you SHOULD or MUST set TC=1.

However adding sibling glue is optional, but MUST in the current draft.

So long
-Ralf
——-
Ralf Weber

---

From: Ralf Weber <[email-masked]>
Date: Wed, 28 Jul 2021 20:07:13 +0200

Moin!

> Do you want dns servers to spend extra CPU power to lookup whether this is a “non-functional” glue case instead of spending less CPU just looking if it has a glue record and adding it?
Well that is a tradeoff an implementer has to make and not something we should define in an RFC.

> If the latter, should it do this extra work of things don’t fit to determine the usefulness of TC=1 for this to set it depending those circumstances or just set TC=1 based on size ?
Again if the packet I as the authoritative server want to deliver does not fit I SHOULD/MUST set TC=1. However if I can and am willing to omit optional sibling glue to make it fit that is fine also. There is authoritative software out there that has a minimize-responses setting to allow the operator to define that behaviour.

So long
-Ralf
——-
Ralf Weber

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Jul 2021 14:27:38 -0400

> not, as there are various kinds of loops possible.

So your assumption is that it's easier to return all possible glue for every nameserver in the delegation set than it is to return glue for just that subset that are subordinate to the zone cut.

Perhaps this is a good opportunity to let actual implementers let us know what is what.

> To determine if the glue you know you have is "needed or not".

As I said, it seems to me that this is absolutely knowledge that you can gain at load time and it's not necessary to wait until response time to do the work. So I think the CPU consumption argument is not especially persuasive. However, I am not an implementer.

Regardless, it does seem to me that glue for nameservers that are subordinate to the zone cut is the MUST and other glue is at best a MAY.

Joe

---

From: Shumon Huque <[email-masked]>
Date: Wed, 28 Jul 2021 17:23:12 -0400

> years.  A straightforward reading of that paragraph also gives you the

The Kaminsky attack can redirect in-bailiwick nameserver names just as
easily as out-of-bailiwick. The defenses against it are (1) make it harder
(source port randomization etc), or (2) deploy DNSSEC. Glue is
unauthenticated
anyway, so the only real defense against misdirection is DNSSEC and
a secure referral to the child.

Also, sibling glue is easier to accept for a paranoid resolver. It may not
be in-bailiwick (i.e. a subdomain) of the "delegated zone", but it is in-
bailiwick of the "delegating zone". If a paranoid resolver, ignores and
re-queries for the sibling names, it ends up requerying the same authority
and then getting a response with in-bailiwick glue. So, it just did a bunch
of additional work for not much benefit in my opinion.

But this is an interesting topic. What do resolver implementations do
when presented with sibling glue? Can implementers comment? I think
this can help inform what we recommend in the draft.

> most a MAY, and I agree with Geoff's reasons to take it out completely.

I don't agree we should take it out, since as I pointed out, RFC 1034
explicitly
covers this type of glue (without giving it a name), and the algorithm will
include it if it is there. If there is a compelling security or other
reason to
remove that, someone should make that case (I haven't heard it yet).

But it seems we will not get consensus on truncating if sibling glue doesn't
fit, so I'm okay with relaxing that requirement.

Shumon.

---

From: "John R Levine" <[email-masked]>
Date: 28 Jul 2021 17:29:46 -0400

We are clearly talking past each other here.  Let's see what the rest of 
the WG thinks.

I think we need to think harder about "what is required for the DNS 
protocol to work" vs "what do I think might be a nice idea."

R's,
John

Regards,

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Jul 2021 09:58:26 +1000

Hi Paul,

> On 29 Jul 2021, at 2:10 am, Paul Wouters <[email-masked]> wrote:
> 

The current version of the draft proposes a mandatory (“MUST”) inclusion of all
in-bailiwick glue records, all “sibling” glue records and is silent on all other
(non-in-bailiwick) glue records.

I had suggested text that was intended to maintain the approach already used in
the draft but I suggested dropping the mandatory (MUST) inclusion of the so-called
“sibling” glue records, and leaving the mandatory to include provision only
relating to in-bailiwick glue records.

Now the draft/operational advice could go in many directions at this point:

a) for basic functionality of DNS resolution it should be mandatory (MUST) to include
in-bailiwick glue records (it’s not clear if “all”) is appropriate for the basic
functionality of the DNS resolution protocol.

b) for more robust resolution performance it would be a good idea (SHOULD? MUST?) to include _all_
in-bailiwick glue records.

It's unclear to me that a compelling case can be made to MUST include _all_ glue records in a referral
response, particularly relating to non-in-bailiwick glue records. 

For me it appears to depend on the actions of the resolver as to whether this would be faster
or not. If all resolvers blindly re-query using TCP for all UDP responses where TC=1 is seen in
responses, then the additional query could be seen as wasted time that could contribute to
slower resolution times. If resolvers actually treat TC=1 in a more optional manner, as in “more
information is available, but if you've got what you needed to move on, then don’t bother
with the TCP followup query.” I suppose it depends on how strictly one interprets the guidance in
Section 9 of RFC2181, which appears to state that TC=1 means requery, to paraphrase the text
in that RFC.

And there is of course the ever-present issues with the resolver’s treatment of non-in-bailiwick
glue records.

Geoff

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Jul 2021 10:12:13 +1000

> On 29 Jul 2021, at 09:58, Geoff Huston <[email-masked]> wrote:
> 
> Hi Paul,
> 

Take the case where only one of the servers for the delegated zone is available.  If it is not a
MUST you end up with resolution failures despite the server being available.  The MUST ensures that
the requisite bootstrapping record is available.

---

From: "Mark Delany" <[email-masked]>
Date: Thu, 29 Jul 2021 00:33:10 +0000

> or not. If all resolvers blindly re-query using TCP for all UDP responses where TC=1 is seen in

I'm not sure I follow this bit. Are you merely implying that the resolver should first
consider a larger edns0 bufsize before resorting to TCP?

Or are you suggesting that responses with TC=1 should include as much of the answers as
will fit and then the resolver can decide whether enough is enough?

That is, what do they look at to avoid a "blind requery"?

Mark.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Jul 2021 11:23:35 +1000

> On 29 Jul 2021, at 10:12 am, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

It's a tradeoff. If TC=1 mandates a requery using TCP then this additional robustness is gained at the
expense of a slower resolution of a referral response.

I would normally expect such tradeoffs to be described in terms of MAY or even SHOULD to guide
the implementer / operator as to a suggestion resolution of these factors while still leaving room
for some folk to tailor their DNS enviroment to meet a different set of priorities.

A MUST pre-ordains a particular set of priorities (in this case an improved robustness for all at
the cost of resolution time), which seem to be to be somewhat presumptive.

When we have a situation that negatively impacts a small proportion of use cases, then it is reasonable
to impose some time / performance penalty on _all_ use cases by making mandatory (MUST) changes to the protocol
to address such corner cases? (No, I don't have a simple answer to this question, either in this specific
case of the more general situation, but it seems that this question is at the core of what we are talking
about here.)

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Jul 2021 11:45:28 +1000

> On 29 Jul 2021, at 10:33 am, Mark Delany <[email-masked]> wrote:
> 

Seems that the DNS Flag Day 2020 precluded that option, so I don’t think its available.

> will fit and then the resolver can decide whether enough is enough?

Well no. Because RFC2181 says "When a DNS client receives a reply with TC set, it should
ignore that response, and query again, using a mechanism, such as a TCP connection, that
will permit larger replies.”, which, unless there is some later RFC that quietly countermanded
this directive then I don't think the resolver has a choice here.

(digression into the interpretation of the term “should” in a document that pre-dates normative 
language. Is that “should” used then in the way we use MUST today? Or is that a SHOULD? I interpreted
it as a MUST but as I don't write resolver code for a living or as a hobby (and you should all be thankful
for that!) I'm definitely not an authoritative sources as to how resolvers SHOULD or MUST interpret
TC=1 responses.

Geoff

---

From: Jared Mauch <[email-masked]>
Date: Thu, 29 Jul 2021 06:33:34 -0400

> On Jul 28, 2021, at 12:16 AM, John Levine <[email-masked]> wrote:
> 

I think this is honestly a bit about, should we make the computers more strict (and possibly more secure) vs more likely to workaround something that is mostly-broken.

Much of the flag day activities were about reducing cruft around workarounds for older code out there.  I don’t like breaking existing stuff but am leaning towards John in that if people are putting semi-broken glue out there, the operator should fix their NS config. 

We have been explicitly driving up DNS queries (eg: QNAME minimization for longer zones, like ip6.arpa) for the sake of privacy and reduced performance as a result.  I think breaking a few people who have poorly configured systems isn’t the end of the world, they will eventually fix their NS records.

Also, trying to define relationships without knowing where the zone cuts may exist in a domain is interesting for terminology but not something I believe goes in this work.

I think calling out that it’s possible people will create situations where a name won’t resolve, is similar to what happens with routing that isn’t deterministic as well.  We should be defining how to determinsticly resolve a name and highlight that it’s flexible enough you can configure it so it won’t work.

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Thu, 29 Jul 2021 10:52:49 -0400

> Seems that the DNS Flag Day 2020 precluded that option, so I don’t think its available.

	I think we should simplify the number of ways we do something,
be it edns0 or tcp.  We are seeing the difference in everyone wanting
their own way/transport/whatnot and therefore keep growing the methods
to get the same data.

	But yes, as we increase the default answer size with additional
glue, signatures, validation, we should be following and sizing as
appropriate.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: "John R Levine" <[email-masked]>
Date: 29 Jul 2021 11:33:23 -0400

> I think calling out that it’s possible people will create situations where a name won’t resolve, is similar to what happens with routing that isn’t deterministic as well.  We should be defining how…

Sounds reasonable.  I'd also like us to keep in mind what our capitalized 
words mean.  MUST means "do this to interoperate".  The only MUST I've 
seen in this document is that servers MUST return all in-bailiwick glue.

I don't think there's anything harmful about returning sibling glue, but 
it is 100% optional. Ignoring NS loops, anything you can get with sibling 
glue you can get by another query, which makes it a MAY.  Maybe two 
queries are slower, maybe the single response with extra glue needed a 
retry with TCP while the two simpler responses could each use UDP, so 
maybe not.

Conflating it with in-bailiwick glue is 100% confusing, which I why I 
think we should drop it and stick to the important point about all the 
in-bailiwick glue.

Regards,