On Sun, Oct 23, 2022 at 12:33 PM Paul Vixie <paul= 40redbarn....@dmarc.ietf.org> wrote:
> > > David Conrad wrote on 2022-10-23 12:00: > > Rob, > > not rod, but i have three comments. > > > On this mailing list, I think there is a pretty good understanding of > > the intent of .alt and I don’t think there is much in the way of > > disagreement on that intent. As far as I can tell, the points of > > contention are: > > > > 1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory. > > 2) whether there will be a registry of .alt uses (i.e., non-DNS name > > resolution systems) and if so, who will operate that registry. > > 3) whether the inevitable leakage of .alt queries to the DNS represent > > potential issues, and if so, should there be an effort to address those > > issues. > > first, +1 to the above and to the elided text formerly below. > > second, it's worth a bit of puttering to figure out how to prevent more > pollution (queries of non-DNS namespaces or non-global-DNS namespaces) > from hitting the root. delegating .ALT the same way 10.in-addr.arpa is > delegated (prisoner.iana.org and so on) may be a fine idea. > > Just to expand on this idea (which I quite like), the original AS112 was enhanced to handle new/arbitrary names, so that AS112 operators don't need to do anything to support being a sink for new domains. This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa" target for use via DNAME. (The DNAME bit is so there isn't a delegation for which the AS112 operator would need to have a zone configured.) Using this via the root zone would be a new kind of entry for the root zone, but is otherwise non-controversial (IMHO). It would basically look like: alt. DNAME empty.as112.arpa Any query for foo.alt would be rewritten by the resolver doing resolution to foo.empty.as112.arpa, which would result in an NXDOMAIN from the topologically closest AS112 instance. (Separate conversation that might be time to raise: is it time to sign empty.as112.arpa, so these NXDOMAIN results have full DNSSEC proofs, and to enable aggressive NSEC support on resolvers?) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
