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

[Jared Mauch <[e-mail]>]

> On Jul 28, 2021, at 12:16 AM, John Levine <[e-mail]> wrote:
> 
> OK, so I ask for foo.example and I get 
> 
> ; answer
> foo.example NS ns.bar.example
> ; additional
> ns.bar.example AAAA 2001:0DB8:0000:000b::2
> 
> Does it check that's the right value for ns.bar.example?  How about with DNSSEC?  I suppose
> 
> I still don't see the benefit of trying to make some loops work when we know that we
> can't make cross-zone loops work.

I think this is honestly a bit about, should we make the computers more strict (and possibly more secure) vs more likely to workaround something that is mostly-broken.

Much of the flag day activities were about reducing cruft around workarounds for older code out there.  I don’t like breaking existing stuff but am leaning towards John in that if people are putting semi-broken glue out there, the operator should fix their NS config. 

We have been explicitly driving up DNS queries (eg: QNAME minimization for longer zones, like ip6.arpa) for the sake of privacy and reduced performance as a result.  I think breaking a few people who have poorly configured systems isn’t the end of the world, they will eventually fix their NS records.

Also, trying to define relationships without knowing where the zone cuts may exist in a domain is interesting for terminology but not something I believe goes in this work.

I think calling out that it’s possible people will create situations where a name won’t resolve, is similar to what happens with routing that isn’t deterministic as well.  We should be defining how to determinsticly resolve a name and highlight that it’s flexible enough you can configure it so it won’t work.

- Jared