On Fri, Oct 21, 2022 at 1:36 PM Paul Vixie <p...@redbarn.org> wrote: > > > Brian Dickson wrote on 2022-10-21 12:42: > > > > > > On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie > > <paul=40redbarn....@dmarc.ietf.org > > <mailto:40redbarn....@dmarc.ietf.org>> wrote: > > > > ... > > > > it's not a fight, and the internet standards community should > > facilitate such carve-outs whenever possible. > > > > ... > > > > I think your suggested carve-out would need a different anchor point in > > the DNS namespace, ... > can you say more about why you think this? (what incompatibilities lurk?)
The different anchor points are (would be?) tied to different purposes, intended behavior for namespaces and resolvers (including leaked queries), and relatively low level-of-effort for DNS-friendly experimentation. So, my read on the general sentiment is: - "alt" => not DNS, or at least not DNS-friendly, including has DNSSEC preventing resolution via validating resolvers. - "alt.arpa" => extending DNS without conflicting with existing ICANN-regulated namespaces, is DNS-friendly, has DNSSEC unsigned delegation point included (so won't be made unuseable when slightly modified validating caching resolvers are involved) What I mean by the term "DNS-friendly" is: includes specification-defined guardrails against collisions, squatting, land rush, abuse, etc., is opt-in (delegation or namespace won't work unless hosts or software have explicitly enabled functionality), and can't be used as a global free end-user registry of domains that work from unmodified clients/resolvers. Mostly the different anchor points are required due to different DNSSEC policies (which are needed to prevent bad end-user experiences for leaked queries with respect to "alt", or are need to enable experimentation without getting blocked by validating resolvers). Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
