On Sun, Oct 16, 2022 at 8:03 AM Suzanne Woolf <swo...@pir.org> wrote:
> Dear Colleagues, > > > The chairs have gotten a couple of requests, off-list and on, for a WGLC > on draft-ietf-dnsop-alt-tld. > > We’ve reviewed the current draft closely and have some concerns that we > feel need to be resolved before any effort to move the draft forward. > (Suzanne wrote this but it’s been discussed among all of the co-chairs.) > > 1. As far as I can tell, this draft does not comply with RFC 6761. This is > a problem for two reasons. > Having re-read this draft, and having re-read 6761, I think that "alt" should NOT be added to the SUDN. The logic is that the SUDN is for DNS domain names only, and "alt" is explicitly for non-DNS names. (Even though it is tempting to include "alt" to give information to those wanting to do non-DNS names, it's still probably best to not do that, IMHO.) > > First, this creates a process problem in that RFC 6761 is the > standards-track document that specifies how the SUDN registry is to be > administered, so a request that doesn’t meet the requirements in 6761 can’t > (or at least shouldn’t) go into the registry. > > RFC 6761 section 4 asserts: > > The specification also MUST state, in each of the seven "Domain Name > Reservation Considerations" categories > below, what special treatment, if any, is to be applied. > > > The alt-tld draft ignores this MUST, without explanation (unless I missed > it). > > The substantive issue is that the questions in Section 5 are there to make > sure there’s a full description of the expected handling of a proposed name > by the assorted components that take part in DNS operations and protocol. > The draft answers at least some of the Section 5 questions, but the answers > are largely implied. > > 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 there should be some instructions to parties wanting to implement non-DNS name systems on additional requirements or anti-requirements, to further reduce the likelihood of queries reaching DNS servers. Specifically, I think having words to the effect of, "Alternative namespaces SHOULD NOT (or MUST NOT) use the port numbers reserved for DNS (including but not limited to 53 and 853)." If they are not DNS they need to not be DNS. Private DNS is still DNS, which is semantically different from alternative namespaces. DNS resolvers are expected to be able to handle public and private DNS names. Alternative namespaces have the potential to collide with DNS names. As such, resolvers should be DNS or not-DNS, but never both. > > So, the current draft isn’t meeting the requirements for the registry, and > also doesn’t clearly answer substantive questions about what DNS operators > are expected to do. This makes me uncomfortable doing a WGLC without a new > rev. It would be Rob Wilton’s call of course (as AD for this draft, > substituting for Warren) but I’m really uneasy with a WGLC without those > changes— they seem rather too large to punt for a post-WGLC version. > > 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the > basis that having the IETF “recognize” (if only by recording) such > pseudo-delegations may serve to attract unwanted attention to the IETF’s > supposed recognition of alternate (non-DNS) namespaces as reservations of > the namespace from the shared, common DNS root. We’re still being denounced > in certain corners for .onion. It might be good to have a paragraph calling > out specifically why .alt is not a delegation of a TLD from the DNS root by > the IETF, even though it looks like one. (We didn’t invent this problem, > because we didn’t make the decision that top-level domain labels should be > used by other protocols in a way that led to confusion. But let’s not > propagate it.) > If each alternate namespace uses its own port numbers, there would not even be a need for any SLD for any such namespace. Using the "alt" RML (rightmost label) would still be a good thing to recommend so DNS has some ability to recognize and reject lookups for other namespaces. (I.e. use a belt and suspenders philosophy) > > 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. > Maybe right-most-label (RML)? > > Thanks to the editors and the WG for considering these comments. > > Ditto. Brian (speaking only for himself.)
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
