Paul, > On Oct 21, 2022, at 10:34 AM, Paul Hoffman <paul.hoff...@icann.org> wrote: > Warren and I believe that the changes in draft-ietf-dnsop-alt-tld-18 meet all > of the concerns in the message that started this thread, and thus it is ready > for WG Last Call.
I disagree that the document is ready for WG Last Call. I will try again: Throughout the document: The document says domain names in .alt “should not” be looked up in a DNS context. The whole point of .alt is that it isn’t to be used in the DNS context. Why is this not RFC 2119 “MUST NOT”? Section 1, paragraph 4: Two of the quoted terms “Experimental Squatting Problem” and “Land Rush Problem” are NOT defined in RFC 8244 — those terms do not exist in RFC 8244. It would be helpful if those terms were defined. Section 2, paragraph 3: Namespaces aren’t actors. They can't "differentiate themselves". Applications differentiate namespaces by the uniqueness of the label for each namespace (something the draft suggests but makes no provision for). Section 2, paragraph 6: “ If the non-DNS protocol has a wire format like the DNS wire format, it might append the null label at the end of the name, but it also might not. This document does not make any suggestion for how non- DNS protocols deal with the wire format of their names.” The sentence preceding the last is pointless. Just use the last sentence. Section 2, paragraph 7: “ Caching DNS servers and authoritative DNS servers will treat all names in the .alt pseudo-TLD just as they would any other name whose TLD does not appear in the global DNS root.” This guarantees the root will receive queries for .alt. Shouldn’t it say “Resolvers and caching DNS servers MUST NOT forward or query the global DNS root name servers for names in .alt”? Same paragraph: “ DNS server operators and DNS registries/registrars for the global DNS will never register names in the .alt pseudo-TLD because .alt will not exist in the global DNS root.” DNS server operators don’t register names. Section 2, last paragraph: “ Currently deployed projects and protocols that are using pseudo-TLDs may choose to move under the .alt pseudo-TLD, but this is not a requirement. Rather, the .alt pseudo-TLD is being reserved so that current and future projects of a similar nature have a designated place to create alternative resolution namespaces that will not conflict with the regular DNS context." Why not encourage movement and explain why, e.g.: "Currently deployed projects and protocols using pseudo-TLDs are encouraged to move under the .alt pseudo-TLD. Doing so will reduce the chance of name collision with TLDs allocated via ICANN processes or other future modifications to the global DNS root zone.” Section 4: There is no explanation as to why leakage will “undoubtedly occur" or why it represents a privacy consideration. Section 5: It is unclear what “re-use the chosen label” means or what “special host name” is being referenced. AFAICT, the primary security consideration is that .alt name lookups can receive unanticipated or malicious responses due to incorrect mapping of the non-DNS name resolution system to the .alt pseudo-TLD. > We note that there are still some people who want a registry of some sort for > names that would appear under .alt, but it feels like the number of people > who want no registry is larger, and it also is clear that the people who want > a registry don't agree on the rules or location for that potential registry. > During WG Last Call, if there is a consensus (decided by the chairs, not the > authors) for one proposal for a registry, we can add it to the draft. Without a registry, how is a non-DNS name resolution developer supposed to "choose a label that they expect to be unique”? Regards, -drc
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
