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

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 6 Jan 2022 23:46:28 +0000

In order to make progress on the glue-is-not-optional draft, we need the working group to reach consensus on the requirement level for sibling glue (MUST, SHOULD, or MAY).

The only situation in which a failure to include sibling glue leads to a resolution failure is when there is a sibling glue cyclic dependency.  e.g.:

      bar.test.                  86400   IN NS      ns1.foo.test.
      bar.test.                  86400   IN NS      ns2.foo.test.

      foo.test.                  86400   IN NS      ns1.bar.test.
      foo.test.                  86400   IN NS      ns2.bar.test.

A few months back I analyzed the zone files available to me via CZDS for sibling glue.  Out of some 209,000,000 total delegations, 222 of them had only sibling NS records in a cyclic dependency as above.  The domains ADOBE.NET and OMTRDC.NET is one real-world example.

The arguments for making sibling glue a MUST are:

1. accommodates (the 0.0001% of) domains with cyclic sibling glue.

2. simpler to specify, don’t need differing requirements for in-domain and sibling glue.

The arguments against are:

1. domains with cyclic sibling delegations should be considered “broken” and not expected to work, perhaps similar to TsuNAME-style external delegation cycles.

2. increases response sizes, truncation probability, and amount of TCP.

DW

> On Oct 11, 2021, at 4:51 PM, Wessels, Duane <[email-masked]> wrote:
> 
> Dear DNSOP,
> 
> Changes to this draft from the previous version are as follows:
> 
>   *  Clarified scope to focus only on name server responses, and not
>      zone/registry data.
>   *  Reorganized with section 2 as Types of Glue and section 3 as
>      Requirements.
>   *  Removed any discussion of promoted / orphan glue.
>   *  Use appropriate documentation addresses and domain names.
>   *  Added Sibling Cyclic Glue example.
> 
> I'd say we still do not have consensus on treatment of sibling glue.  Section 3.2 currently has the strict requirements with optional more lenient requirements in [square brackets]:
> 
> 3.2.  Sibling Glue
> 
>   This document clarifies that when a name server generates a referral
>   response, it MUST [SHOULD] include available sibling glue records in
>   the additional section.  If all sibling glue records do not fit in a
>   UDP response, the name server MUST [is NOT REQUIRED to] set TC=1.
> 
> 
> DW
> 
> 
>> On Oct 11, 2021, at 4:30 PM, [email-masked] wrote:
>> 
>> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
>> 
>> 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-03.txt
>> 	Pages           : 9
>> 	Date            : 2021-10-11
>> 
>> 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.  This
>>  document updates RFC 1034 to clarify correct server behavior.
>> 
>> 
>> 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-03.html
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-03
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2022 19:35:55 -0500

It appears that Wessels, Duane <[email-masked]> said:
>A few months back I analyzed the zone files available to me via CZDS for sibling glue.  Out of some 209,000,000 total delegations,
>222 of them had only sibling NS records in a cyclic dependency as above.  The domains ADOBE.NET and OMTRDC.NET is one real-world
>example.

Looks to me like they're just broken:

$ dig @a.gtld-servers.net. adobe.net ns
;; QUESTION SECTION:
;adobe.net.			IN	NS

;; AUTHORITY SECTION:
adobe.net.		172800	IN	NS	ns1.omtrdc.net.
adobe.net.		172800	IN	NS	ns2.omtrdc.net.

;; ADDITIONAL SECTION:
ns1.omtrdc.net.		172800	IN	A	66.235.157.6
ns2.omtrdc.net.		172800	IN	A	66.235.157.7

$ dig @ns1.omtrdc.net. adobe.net. ns
;; QUESTION SECTION:
;adobe.net.			IN	NS

;; ANSWER SECTION:
adobe.net.		900	IN	NS	ns-1.adobe.net.
adobe.net.		900	IN	NS	ns-2.adobe.net.

;; ADDITIONAL SECTION:
ns-1.adobe.net.		900	IN	A	66.235.157.6
ns-2.adobe.net.		900	IN	A	66.235.157.7

(Note that they're the same servers with different names.)

I'm not sure how you'd do this, but do you have any idea how many domains have NS cycles
across parallel zones that don't work, e.g.:

  foo.tld1. IN NS ns1.bar.tld2

  bar.tld2. IN NS ns2.foo.tld1.

R's,
John

PS: My preference is still "don't do that."
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: George Michaelson <[email-masked]>
Date: Fri, 7 Jan 2022 10:50:33 +1000

for a 200 in 200,000,000 problem? Ban it.

-G

---

From: Paul Vixie <[email-masked]>
Date: Thu, 6 Jan 2022 17:47:58 -0800

> for a 200 in 200,000,000 problem? Ban it.

i agree that we should ban it, but not on the basis of its infrequency 
of use. rather, on the basis of data provenance. let me explain.

an iterator has no reason to believe adobe.net's servers as to addresses 
under omtrdc.net, or vice versa. it can be used only for the current 
iteration and never as answer or additional data, and never put into a 
shared cache or used by other iterations even concurrently. 
chicken-or-egg problems mean that no iteration will ever have all of the 
data it needs to complete. when this loop is detected, the result should 
be servfail.

what's important in the context of this draft is to require this 
servfail, rather than letting it be implementation dependent. it ought 
to be possible for implementors to create regression tests around this, 
and for customers to create acceptance tests around this. servers which 
somehow work around chicken-or-egg glue paths must be declared "wrong". 
for something this critical to dns coherency, we must be conservative in 
what we accept.

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Jan 2022 21:14:41 -0500

On Jan 6, 2022, at 20:48, Paul Vixie <paul=[email-masked]> wrote:
> i agree that we should ban it, but not on the basis of its infrequency of use. rather, on the basis of data provenance.

Who wants to be the first to fail resolving adobe.net 😀

Seriously though, this draft is not about banning certain deployments or not. Its only concern is MAY vs SHOULD vs MUST require the found glue to be added to the response and potentially cause TC. 

I am tempted to SHOULD (or just not mentioning sibling glue at all) for two reasons.

1) the WG keeps punting this so MUST or MUST NOT seems too strong

2) in general the whole point of this draft is to get the glue in as it’s important and some implementations don’t always do that. Making it MAY or SHOULD NOT might leak into the non-sibling use case and for this 0.0000002% I don’t really care what happens. (Adobe can fix it if they need to)

Paul

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2022 21:57:25 -0500

>Who wants to be the first to fail resolving adobe.net 😀

Since it's only a redirect to adobe.com, I doubt many people would care.

>Seriously though, this draft is not about banning certain deployments or not. Its only concern is MAY vs SHOULD vs MUST require the
>found glue to be added to the response and potentially cause TC. 

We finally appear to be coalescing around the correct answer, MUST NOT.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Thu, 6 Jan 2022 21:59:16 -0800

> Who wants to be the first to fail resolving adobe.net 😀

adobe.net is unrelated to adobe.com.

> Seriously though, this draft is not about banning certain deployments or not. Its only concern is MAY vs SHOULD vs MUST require the found glue to be added to the response and potentially cause TC.

i don't think any draft can or should specify behaviour in the face of a 
data loop other than (a) servfail and (b) required. if this draft is not 
going to touch on data loops, that's fine, leave it out. if it does, 
though: "servfail required".

-- 
P Vixie

---

From: Hugo Salgado <[email-masked]>
Date: Fri, 14 Jan 2022 14:08:13 -0300

> 1) the WG keeps punting this so MUST or MUST NOT seems too strong

There's also the case of registries with sibling glue names but without
the addresses. I suppose that in registries that use NS-as-objects this
can't happen, because there're pre-requisities in defining a host object
for every case. But in .CL, we use NS-as-attributes, and the addresses
are only required (and registered) where the NS is directly under
the delegation (the In-Domain Glue case).

So in this case:

  bar.test.                  86400   IN NS      ns1.bar.test.
  bar.test.                  86400   IN NS      ns2.bar.test.
  ns1.bar.test.              86400   IN A       192.0.2.1
  ns2.bar.test.              86400   IN AAAA    2001:db8::2:2

  foo.test.                  86400   IN NS      ns1.foo.test.
  foo.test.                  86400   IN NS      ns1.bar.test.
  foo.test.                  86400   IN NS      other.bar.test.
  ns1.foo.test.              86400   IN A       192.0.3.1

a question that delegates to foo.test will return sibling glue addresses
for ns1.foo.test. and ns1.bar.test., but no address for other.bar.test.

In .CL we have several hundreds of cases with this type of sibling
names, including some names in which there're no address at all
(all the NS are under another CL name but aren't in-domain glue).

So, a SHOULD-level requirement would seem to be a better fit for us.

Hugo