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.
third, in recognition of this concern:
...
As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS
name resolution protocol is specified to not be plain text (presumably
any new protocol would be encrypted), then users of that protocol have
an expectation that their queries are protected. ...
implementation guidance contained in the .ALT "specification" should
include the need to detect ".ALT" from the right hand side before
deciding whether or not to do special non-DNS processing on the
remaining left hand side. this is because the non-DNS syntax on the left
hand side might include .ALT for other reasons, or may use "."
differently than DNS would do. this is messy but inevitable given that
DNS camped on to the entire domain namespace in its earliest days.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop