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

[Geoff Huston <[e-mail]>]

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


> On 28 Jul 2021, at 9:25 am, Shumon Huque <[e-mail]> wrote:
> 
> 
> 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.


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.



> 
> >* 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.
> 
> 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.
> 
> Yeah, after thinking about this since yesterday, I'm now a little skeptical that we
> should cover this potentially thorny topic.


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