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

[Hugo Salgado <[e-mail]>]

On 21:14 06/01, Paul Wouters wrote:
> On Jan 6, 2022, at 20:48, Paul Vixie <paul=[e-mail]> wrote:
> > 
> > 
> > 
> > George Michaelson wrote on 2022-01-06 16:50:
> >> 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.
> 
> 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
> 

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