On 21:14 06/01, Paul Wouters wrote: > On Jan 6, 2022, at 20:48, Paul Vixie <[email protected]> > 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
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
