On Sun, 16 Oct 2022, Suzanne Woolf wrote:
1. As far as I can tell, this draft does not comply with RFC 6761. This is a problem for two reasons.
One could advance the 6761bis proposal document first, which would remove these non-compliance items as those would be no longer needed (as the bis document proposal removes it as these were not consistently required in the past). Alternatively, ignoring it wouldn't be the first time these are ignored, so I guess there is a precedence of ignoring it.
For example, the draft says that DNS resolvers seeing .alt names "do not need to look them up in the DNS context”, but a big part of the point of codifying these names is the assumption that queries will leak and DNS servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s implied that .alt is simply not in the public DNS root zone and the root servers (or better yet, any intermediate resolver) should answer “name error”/NXDOMAIN for such queries. But this should probably be said explicitly, because people who configure DNS servers and services shouldn’t have to guess what’s being implied here. (The WG discussed the possibility that such queries should be blackholed and not answered at all, which is in some ways an obvious answer. Clarification of why this was discarded might also be helpful.)
I think it draft would be better if it said something along the lines of: No code changes are required to properly handle leaked queries for .alt into the DNS, but: 1) Implementations MAY handle .alt specially by (pre)fetching the proofs of non-existence of .alt and serve these for all .alt queries. 2) implementations MAY rely on their query minimalization to accomplish 1) 3) or MAY do nothing special, which should work fine but might leak SLD queries to the root if the implementation and its querier didn't do query minimalization) 4) MAY return FORMERR on .alt queries that in some ways violate the DNS specification (so that no code changes are mandatory to support the madness .alt queries could bring in, eg >63 SLD names)
2. Having the IETF maintain a registry of pseudo-SLDs concerns me
Me too, I really do believe that the IETF should not do this. It is an anchor for non-IETF hooks. There is no guarantee of uniqueness in names. Some alternative sysytems might even use .alt without SLD. Basically, .alt is what IETF recommends you should not do, and we should not keep a registry of entries within it. But also, IETF maintaining a list might open it up for legal liabilities with alternative naming systems. The whole idea of the ICANN/IETF split is that ICANN does money and legal stuff, and IETF does codepoints and running code (with no money) :P So I disagree with Eliot who prefered some kind of FCFS registry that requires RFCs to get an entry. We do not want alternative naming systems to require (and burden) the IETF with RFCs.
3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term “registered” differently than common usage. Judging from searches on RFC 6761 and RFC 8499, it’s ambiguous for DNS naming and resolution, and “registered” can definitely mean something different to a registry or registrar than it does to a DNS operator. To people who operate TLD registries, a name can be “registered” and still may or may not be delegated. (“Label” is defined in 8499, “register” and “delegate” are not.) And, in the reference to “TLD,” it feels strange to expand the acronym to “Top-level label” even if “label” is the right word for what you’re talking about.
"pseudo-TLD" is not a good word here to refer to .alt, as other common SLD's that are open to generic registration are often called pseudo-TLDs, such as .uk.com. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
