On Oct 21, 2022, at 2:39 PM, David Conrad <d...@virtualized.org> wrote: > > 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?
Yes. > 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. Also yes. > If the intent here is that .alt names should never be looked up via the DNS, > then MUST NOT is the expected behavior, no? There is no such intent of the draft. If you find words that lean toward that intent, please let us know so we can remove them. The intent is that .alt will always not be in the global DNS. Looking up those name in the global DNS is as acceptable as is looking up any name that's going to lead to an NXDOMAIN for the first label. >> 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 Both are true for all names with TLDs that are not in the root zone. For (a), that's a problem with using the DNS. For (b), the RSOs have repeatedly said that they have plenty of capacity for the kruft they get. > >> 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. We disagree here. Adding per-name rules to resolvers causes more fragility and possibly wrong outcomes than letting the DNS continue to be the DNS. > >>> 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. Ah, got it. I still think the explanatory sentence for why we don't make any suggestions helps the reader. >>> 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? The point is to say "here's a name that will not be in the root zone that you can use for non-DNS contexts". Setting up a bunch of rules for DNS resolvers to support that, when they already support that now, adds fragility to the DNS. > >>> 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). Ah. I can see your logic, although I can also see mine. Given your logic, what should I say about "DNS server operators" with respect to .alt? >>> "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? Giving them a safer way to do what they're gonna do. >>> 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. There's plenty of documentation on why leakage occurs; it does not need to be repeated here. > >>> 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. I like that; will add. > >>> 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. Quite true. That's the price they pay for not using an enforced registry which is the global DNS. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
