Paul Wouters has entered the following ballot position for draft-ietf-dnsop-alt-tld-23: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some of my comments might be DISCUSS-worthy (my apologies), but I really don't want to block this document for any further time. But please do take my comments into considerations if you can do a quick ref update. The term pseudo-TLD as defined here is not how I've seen the term used. A pseudo TLD as I've seen it used is a TLD that's one step below a real TLD and runs as a general GTLD (open registration), eg "uk.com". I guess I would qualify the use in this document more as "fake TLD", but I can see how that might come over as even more perogative. So I am fine with the current definition and use case. Perhaps a "to be confused with" note could be added, but is not strictly required. 4. Caching DNS servers SHOULD NOT recognize names in the .alt pseudo-TLD as special and SHOULD NOT perform any special handling with them. There is value for a recursor to "pre-load" the proof of non-existence of ".alt" (the entire branch in the hierarchy) to avoid any potential leakage of subdomains within alt. It could potentially also reduce error message logs if someone starts using .alt not as a real hierarchy or using non-DNS valid characters in their name, eg Ulabel stuff or even binary stuff like 0x00010001000000003616c7400. They could also just return NXDOMAIN instead of forwarding the query to the root servers to avoid a privacy leak. Or it could modify the question foo "foo.alt" and only send "alt" to the root. I see no reason such additional protection mechanisms need to violate this "SHOULD NOT" clause. Why not flip the statement around? 4. Caching DNS servers MAY recognize names in the .alt pseudo-TLD as special and MAY perform special privacy preserving methods to return (DNSSEC signed) NXDOMAIN answers to prevent leaking entries under the .alt pseudo-TLD into the global DNS. 5. Authoritative DNS servers SHOULD NOT recognize names in the .alt pseudo-TLD as special and should not perform any special handling with them. Any reason the second "should not" is lowercase ? Note that I do agree here, and would even say MUST NOT so that people can use DNS technology even if not rooted in the global DNS for their .alt names without having to modify existing DNS software (eg run a shadow .alt using DNS on port 666 or something) 6. DNS server operators will treat names in ... I find the use of "will" here a little odd. Perhaps: 6. DNS servers and operators, which whave no special handling for the .alt pseudo-TLD will end up treating names in ... 7. 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 "will never" seems wishful thinking. I've seen some very fraudulent stuff happen with DNS registries/registrars. eg what if one of them will support pseudo-TLDs along with real DNS domains, and includes bogus .alt registrations? Perhaps: 7. DNS registries/registrars for the global DNS can never legitimately register names in the .alt pseudo-TLD because .alt will never exist in the global DNS root Again, my apologies to Warren for not balloting a blanc YES :) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
