On Sun, Oct 16, 2022 at 11: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. > > 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.) > > 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. > Yup. The version 2 back ( https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-15) has all of the text / answers, and it would be trivial to put it back. It may require some minor word-smithing to get the wording to align perfectly, but that should be simple enough. On the "what should resolvers do?" question, the prior text said: "4. Caching DNS servers SHOULD NOT recognize these names as special and should not perform any special handling with them." This changed from -07 ( https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-07), which said: "4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD generate immediate negative responses for all such queries." This reason for this change was that we had proposed adding this to the "Locally Served Zones" registry, and so there wasn't expected to be any "special" handling or knowledge by implementations. Perhaps we could clarify this somehow…. > 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.) > Yup. This is (IMO) the area of the draft where the consensus was the least clear. I still think that it would be useful to have a *purely* informational list saying "Group A says it is using string B and their documentation is at https://foo.example.com"; and "Group X also says that it is using string B and their documentation is at https://bar.example. <https://foo.example.com/>net". Enough people have pushed back on asking IANA to host this that I think that it should be removed (and I was the one most strongly arguing for it). Ibviously it's the DNSOP WGs decision, but I won't argue for keeping it :-) > 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. > Thank you, these are good points. For reference (to save people having search), here is the current text for 'pseudo-TLD': "A label that appears in a fully-qualified domain name in the position of a TLD, but which is not registered in the global DNS. This term is not intended to be pejorative." Do you have any suggestions on what we can / should use instead of "registered"? Perhaps "but does not exist in the IANA root zone"? Or "has not been delegated in the global DNS"? And for TLD: " TLD, top-level label: The last visible label in either a fully-qualified domain name or a name that is qualified relative to the root." Luckily we now have https://datatracker.ietf.org/doc/html/rfc8499 , which has done the hard work for us, and says: " Top-Level Domain (TLD): A Top-Level Domain is a zone that is one layer below the root, such as "com" or "jp". There is nothing special, from the point of view of the DNS, about TLDs. Most of them are also delegation-centric zones (defined in Section 7), and there are significant policy issues around their operation. TLDs are often divided into sub-groups such as Country Code Top-Level Domains (ccTLDs), Generic Top-Level Domains (gTLDs), and others; the division is a matter of policy and beyond the scope of this document." Perhaps we can just remove our definition of TLD and point at that instead? > Thanks to the editors and the WG for considering these comments. > Thank you for the comments, review and feedback; they are very helpful, W > > Best, > Suzanne > (For the chairs) >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
