Paul, On Oct 21, 2022, at 1:46 PM, Paul Hoffman <paul.hoff...@icann.org> wrote: >> 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.
This is true for all IETF protocols/specifications. Are you arguing RFC 2119 “MUST” is pointless? As far as I understand, the point of 2119 language is to be explicit in expected behaviors, not to imply that the Internet Police will hunt you down if you violate them. If the intent here is that .alt names should never be looked up via the DNS, then MUST NOT is the expected behavior, no? > If they look up a .alt name in a DNS context, that's just fine, as long as > they want to get an NXDOMAIN. No, it is not "just fine": a) it leaks potentially sensitive information b) it adds load to the root servers > 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? It is marginally clearer, but misses the point. .alt is defining a technique by which a non-DNS name resolution system can make use of domain name syntax that applications expect. Given that it is explicitly non-DNS, I feel the wording should be explicit in stating that the DNS protocol MUST NOT be used. >> 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. Sorry if I was unclear: I said “sentence preceding last", not paragraph. Simply saying “This document does not make any suggestion for how non-DNS protocols deal with the wire format of their names” is sufficient — you don’t need the “it can be X or not X” tautology. >> 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? Because .alt is being set up to be for use in non-DNS contexts. If not, then what is the point of this draft? >> 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. No. RFC 6761, section 5.6 talks about configuring, not registering. I believe what 6761 was getting at is whether or not the server should reject a name as a configuration error. This is different than administratively rejecting a name for registration. E.g., I can easily imagine a registrar creating a registration for the equivalent of ‘*.alt’ to block anyone from even bothering to register a .alt name by indicating it is already registered (as is hinted at in RFC 6761 section 5.7). >> "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. Then what is the point of this draft? >> 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. This may surprise you, but I’m aware of why leakage occurs :). My point was that the reader, i.e., someone implementing a non-DNS name resolution system, may need a bit more explanation as to why leakage happens and the privacy implications of that leakage. >> 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? If it is not a pseudo-TLD, presumably DNSSEC validation may be able to provide some protection. If it is a pseudo-TLD, then a security consideration is ensuring (somehow) that the mapping of that pseudo-TLD into the appropriate non-DNS name resolution system is expected. In particular, given no registry of pseudo-TLDs to name resolution mapping systems, I imagine there is an increased risk that a name collision under .alt could result in queries that expect one non-DNS name resolution system to be submitted to a different non-DNS name resolution system, resulting in unanticipated responses. More generally, I believe the security consideration here is that because .alt names are explicitly outside of the DNS context, it is obviously not possible to rely on any DNS-related security considerations and care must be taken to ensure that the mapping of the pseudo-TLD into its corresponding non-DNS name resolution system is as the end user/application/operating system/etc. expects. >> 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. I would think there would be less chance of surprise if there were to be a voluntary (light-weight) registry. Without a voluntary registry in some well-known place, each non-DNS name resolution system developer will need to know of all other non-DNS name resolution systems. Regards, -drc
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
