(Well, *that* will teach me not to go on vacation and not look at work email. Or maybe I should do that more often!)
> 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.) Warren and I will put out a new document before the draft submission cutoff next week to resolve the concerns given in the message and thus move the draft forward. > 1. As far as I can tell, this draft does not comply with RFC 6761. Correct. > 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. As we have seen, the IESG seems happy to publish standards-track documents for items that will go in the Special-Use Domain Names registry that do not comply with RFC 6761. There is no reason to believe that this draft will have a different fate. Having said that, we can add the text required by RFC 6761 in a way that meets the 6761 requirements that the IESG has been ignoring, but doesn't say anything more interesting than what is in the draft now. The IESG can then decide if it meets their requirements. > 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). That's a fair point; we can add that. > 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. Exactly right. Because .alt will not be in the global DNS root, those requests will be treated like every other request with a TLD that is not in the global DNS root: resolvers do not need to look them up in the DNS context. When I became co-editor on the draft, I removed Warren's 6761ish text because saying "treat this like every other name". I see now that I should have instead fixed the 6761ish text; we'll do that soon in the next draft. > (“Do not need to” isn’t even “SHOULD not”.) Exactly right. More importantly, it is not "MUST NOT". In the case of a TLD that is not in the global DNS root, RFC 1035 is already completely clear, and this document should not update RFC 1035. RFC 6761 does not require SHOULD/MUST language. > It’s implied that .alt is simply not in the public DNS root zone That is not an "implication", it is explicit because the zone will be part of the RFC 6761 registry. We will add a redundant sentence in the introduction to make this clearer. > and the root servers (or better yet, any intermediate resolver) should answer > “name error”/NXDOMAIN for such queries. Can you show where there is that implication? If so, we will certainly nuke it from the draft. .alt should be treated by all systems just like any TLD that is not in the global DNS root, and this draft should not update RFC 1035 to list the dos and don'ts for those systems. This is the same for every other TLD in the 6761 registry. > 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 fully disagree that adding a section of "something we discussed that we decided not to do" will be helpful: it will be confusing. > 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. It meets the requirements of the IESG; it does not meet the requirements of the RFC because those requirements in that RFC is being actively ignored (for good reason, IMHO). It does not currently answer those substantiative questions because the answer is already in RFC 1035, but we will add them to the next draft to help move this along. > 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. Noted. Let's see if the revised draft gives you ease. > 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.) Having read the rest of this thread, it is clear that there is almost no support for the registry. Thus, we will nuke it in the next draft, and if the WG really wants it back, we at least have some worked-out wording for 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.) Good catch; we'll change that to "but which is not part of the global DNS". > 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. We'll just point to RFC 8499 for that definition. > Thanks to the editors and the WG for considering these comments. No problem. When the new draft is issued (soon!), I hope that the chairs will again strongly consider moving this to WG Last Call expeditiously. A few other things said on the list about this draft: On Oct 16, 2022, at 9:07 AM, Eliot Lear <l...@lear.ch> wrote: > First, absent at least an FCFS registry there will be no ability to > programmatically switch against the label. If multiple entries exist this is > particularly painful. If no registry exists, then perhaps multiple > unofficial registries will pop up and we're in the same boat. Let's not have > that. That programmatic switch is important. It allows multiple naming > systems to co-exist all the way to the level of the application (e.g., > end-to-end) without any ambiguity being introduced. > > Second, people have been concerned about the possibility of vanity > registries. Requiring an RFC puts an end to that. I don't think we want to > endorse any particular approach, but IANA maintains many registries, and > nobody has ever taken any of their entries as endorsements. This proposes two significant changes to the draft: make the registry FCFS and make entrance to it be by RFC. Those are both pretty heavy-weight for things *that are not part of our naming system*. I strongly prefer "drop the registry" and let the non-DNS folks figure out how to deal with their own issues. After you see the next draft, if you think the registry with your two changes is needed, you can propose to add it back in. On Oct 16, 2022, at 7:20 PM, Paul Wouters <p...@nohats.ca> 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. This draft should not be blocked on draft-hoffman-rfc6761bis. We will make a stab at the shortest possible text to fulfill the 6761 requirements, but if that fails, we'll let the IESG ignore it like y'all have the last few RFCs in the registry. > 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) Why say any of that? Systems "MAY" do whatever the heck they want as long as they conform to RFC 1035. There's nothing new here. > "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. I have never seen those called pseudo-TLD, and don't see evidence for that in searching around the Internets. On Oct 17, 2022, at 1:16 PM, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> wrote: > > While we're talking about this draft, I would like to suggest that the draft > discuss the interpretation of URIs containing ".alt" hostnames. I have great > difficulty understanding what "https://example.foo.alt/"; means ... but most > of the interest in alternative naming systems seems to be based on the idea > that this sort of URI is meaningful. .alt will be treated like any other pseudo-TLD regardless of the context. If you think that URIs that have names that are not part of the global DNS should be treated differently by URI consumers, by all means write a draft about it. That work will attract some people, and cause others to run away screaming. (Having worked on the URI update specs and even authoring some URI definitions, I will be in the third group that will be sauntering away while wishing the best for my friends in the first group.) --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
