On Sun, Oct 16, 2022 at 7:20 PM, Paul Wouters <p...@nohats.ca> wrote:
> 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. > <no-hats (still!)> #include <terseness-apology-at-nanog.h> I'll note that I was one of the people initially pushing for a registry - I wanted to be able to lookup 'foo.alt' and see that I should read the specifications "The foo naming system", available on GitHub at <url> (and possibly also "foo-names - the protocol" available at <some url>). But: 1: as we've already seen, nothing stops people from just using whatever names they want[0], and so there is no guarantee that registry would be complete and correct. 2: if this happens to be widely used, we might end up with lots and lots of names using this, and having e.g the IANA maintain this has costs - even if they just note "FooNet says that they use foo.alt and their specification is at https://www.the-foo-project.example/foo-names.html";, this has costs. I really don't want us to end up with a "success failure". Having something like a list of what to read to understand how to resolve bar.foo.alt still seems useful, but it could (IMO) just be a list on GitHub that someone is willing to manage (similar to the PSL ( https://github.com/publicsuffix/list), but purely informational, and with no real validation/work. And, no, I'm not volunteering to run this). W [0]: I just changed the hostname on my laptop bar.foozle.wobble.alt, and there is nothing you can do to stop me… (actually I didn't, but I could have....) </no-hats> > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
