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

From: [email-masked]
Date: Wed, 03 Jun 2020 19:36:49 -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
        Author          : M. Andrews
	Filename        : draft-ietf-dnsop-glue-is-not-optional-00.txt
	Pages           : 5
	Date            : 2020-06-03

Abstract:
   The DNS uses glue records to allow iterative clients to find the
   addresses of nameservers that live within the delegated zone.  Glue
   records are expected to be returned as part of a referral and if they
   cannot be fitted into the UDP response, TC=1 MUST be set to inform
   the client that the response is incomplete and that TCP SHOULD be
   used 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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-glue-is-not-optional-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-glue-is-not-optional-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 05 Jun 2020 09:52:57 +0200

>         Title           : Glue In DNS Referral Responses Is Not Optional

Mark,

thank you for writing this down in a document.

If you're doing an implementation status section, you can note that
PowerDNS Auth is compliant since 4.2.0, or about a year ago.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 5 Jun 2020 17:37:56 +0000

The essence of this draft is the addition of once sentence to RFC 1034:

  "If glue RRs do not fit set TC=1 in the header."

I worry that this is too ambiguous.  Does it mean all glue?  One glue?  As much as will fit?

AFAIK most software today is designed to fill up the additional section with as much glue as possible.  Is the name server allowed to add only some glue RRs, even if more would fit (without truncating, or in a TCP response)?

Is the name server allowed to fill the additional with all records of one type, AAAA or A, when the resolver might only have connectivity of the other type?

There is also the question of in-domain vs sibling-domain glue.  RFC 8499 (Terminology) notes that "Glue records for sibling domains are allowed, but not necessary."  Should in-domain glue take priority over sibling-domain glue?  Can sibling-domain glue be omitted even if it would fit?

DW

> On Jun 3, 2020, at 7:36 PM, [email-masked] wrote:
> 
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 05 Jun 2020 17:40:56 +0000

On Friday, 5 June 2020 17:37:56 UTC Wessels, Duane wrote:
> ...
> 
> There is also the question of in-domain vs sibling-domain glue.  RFC 8499
> (Terminology) notes that "Glue records for sibling domains are allowed, but
> not necessary."  Should in-domain glue take priority over sibling-domain
> glue?  Can sibling-domain glue be omitted even if it would fit?

yes, and yes. and if truncation occurs after all in-domain glue has been 
added, then the TC bit need not be set. we should not force a retry over TCP 
to get nonessential data (which is available by means other than a referral.)

-- 
Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jun 2020 18:56:43 +0000

> There is also the question of in-domain vs sibling-domain glue.  RFC 8499 (Terminology) notes that "Glue records for sibling domains are allowed, but not necessary."  Should in-domain glue take pri…

The current document is indeed ambiguous. I propose that it be changed to:
   If all glue RRs do not fit, set TC=1 in the header.

Given Duane's questions above, we can do better with another change to RFC 1034 in this document. In this same paragraph from RFC 1034, it says:
   Put whatever addresses are available into the additional
   section, using glue RRs if the addresses are not available from
   authoritative data or the cache.
That could instead be:
   Put at least one available address into the additional
   section, using glue RRs if the addresses are not available from
   authoritative data or the cache.

I don't think it is worthwhile to go into more detail about how to choose how many to put in (because RFC 1034 didn't explicitly talk about message size), or the mix of A and AAAA (because RFC 1034 didn't anticipate more than one address type).

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 5 Jun 2020 19:56:15 +0000

> On Jun 5, 2020, at 11:56 AM, Paul Hoffman <[email-masked]> wrote:
> 

I believe this is contrary to how most authoritative DNS software works today, isn't it?

>   authoritative data or the cache.

And that sounds like the opposite of what you suggested above?

DW

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2020 16:40:57 -0400

>I believe this is contrary to how most authoritative DNS software works today, isn't it?

I hope not. If it sends only part of the glue without a hint that
there's more if they requery, that's a recipe for failure. People sent
some examples last week.

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 5 Jun 2020 21:22:55 +0000

> On Jun 5, 2020, at 1:40 PM, John Levine <[email-masked]> wrote:
> 

Here's one example, 0124.org which has five in-domain name servers with glue:

$ for sz in `seq 604 16 700`; do echo -n "BUFSIZE $sz " ; dig +norec +ignore +dnssec +bufsize=$sz @199.19.57.1 0124.org | grep ';; flags:' ; done
BUFSIZE 604 ;; flags: qr tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
BUFSIZE 620 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
BUFSIZE 636 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 2
BUFSIZE 652 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 3
BUFSIZE 668 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 4
BUFSIZE 684 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 5
BUFSIZE 700 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 6

Note that one of the Additional RRs is always the OPT RR.

And from everyone's favorite, the root servers:

$ for s in a b c d e f g h i j k l m ; do echo -n "$s  " ; dig @$s.root-servers.net +dnssec +norec +ignore +bufsize=700 example.com | grep ';; flags:' ; done
a  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5
b  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5
c  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5
d  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7
e  ;; flags: qr tc; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5
f  ;; flags: qr tc; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5
g  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5
h  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7
i  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5
j  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 5
k  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7
l  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7
m  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 7

DW

---

From: "John R Levine" <[email-masked]>
Date: 5 Jun 2020 17:43:45 -0400

> Here's one example, 0124.org which has five in-domain name servers with glue:

You're right, that's what it does but it also seems seriously wrong.

> BUFSIZE 620 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1

This domain has five NS, but the client only has the IP address of the 
first one.  If that first one doesn't respond, what happens?  It can't 
query any of the others because it doesn't have any of the addresses and 
it doesn't have any way to ask for them.

What's the point of having more than one NS if clients can only find one 
of them?

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