On Oct 21, 2022, at 12:49 PM, David Conrad <d...@virtualized.org> wrote: > 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”?
Because we cannot force applications or APIs to do anything. If they look up a .alt name in a DNS context, that's just fine, as long as they want to get an NXDOMAIN. The draft says "should not" in two places: "should not be resolved using the DNS protocol" and "should not attempt to be resolved using the global DNS". Would it be clearer to say "will never be resolved in the global DNS" in both places? > 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. Good catch; will fix. > 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). Good catch; will fix. > 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. This was discussed earlier in the WG. The preceding paragraph is useful because some readers of the draft forgot that there is a difference between the DNS presentation format and wire format. > 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. Yes, just like the root service receives queries for all sorts of stuff. (See <https://magnitude.research.icann.org/> for a list of the TLDs that one root server operator sees.) > Shouldn’t it say “Resolvers and caching DNS servers MUST NOT forward or query > the global DNS root name servers for names in .alt”? No, it shouldn't, unless you can say why resolvers and caching DNS servers should treat .alt any differently than any of the other zillion popular non-delegated TLD? > > 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. According to RFC 6761, they do, or at least they act like what a registry does after it registers a name. > 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.” Because encouraging those parties seems pointless. They're gonna do what they want to do regardless of what some RFC says. > Section 4: > > There is no explanation as to why leakage will “undoubtedly occur" or why it > represents a privacy consideration. See the URL above for why leakage undoubtably occurs. Some such leakage will include labels below the TLD that some might consider a privacy concern. Further, leakage can be worse than just full names: if you paw through the queries received by root server operators, you will see some queries that contain full URLs as the QNAME. > Section 5: > > It is unclear what “re-use the chosen label” means or what “special host > name” is being referenced. Noted. This sentence is quite hard to parse, now that I (a co-editor) read it. > 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. Isn't that true for any TLD, pseudo or not? > >> 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”? With a voluntary registry for .alt, they will have the same problem. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
