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

Reply via email to