[ No hats!] On Sun, Aug 18, 2019 at 2:29 PM John Levine <jo...@taugh.com> wrote: > > >So it would be helpful to know if you think the recommendations are in fact > >reasonable. > > I think they're reasonable but I would more clearly distinguish cases > by where the protocol switch is, where I think these are the > interesting ones: > > 1. Names handled totally unlike the DNS with nothing like an IP address > (.onion) > > 2. Names handled through mutant DNS which can returns IP addresses (.local, > .localhost, .homenet/.home.arpa) > > 3. Names that have other problems such as conflicting prior use (.test, > .example, .invalid, also .home, .belkin) > > For 1, we can reserve if if there's a compelling argument and evidence > of clear use. This leads to a catch 22 where the only way to get the > evidence is to squat on it, but I don't see any way around it. I > particularly do not want to reserve names just because someone claims > to have a great plan. I think this probably includes Warren's great > plan for .alt.
.... hey, that's my cue! ..alt was discussed at IETF 105, and it sounded to me like was good support for progressing it / discussing it again. A quick recap for those who've managed to swap out state on this... "This document reserves a string (ALT) to be used as a TLD label in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces." For all sorts of reasons (compatibility with existing apps being the main one!) people building alternate naming systems (like .onion, the GNUnet naming system, many of the blockchain-based / type systems) want to use names which follow the DNS convention. This means that they can and do leak into the DNS - for example, if I send you email with a link to https://facebookcorewwwi.onion/ and you don't have a TOR browser / shim you'll end up asking the DNS. This ruins much of the privacy they should be providing (and also being annoying :-), and also leads to the possibility of collisions. As John says, there isn't much that people who want to do this responsibly *can* do - there isn't a path for them. Reserving .alt will give people designing and using systems like this a responsible option -- they choose something under .alt (e.g: foo.alt). Below is a FAQ to answer to some of the previously discussed questions. FAQ: 1: Why not just suggest people choose something + <non-DNS-character> (like ASCII 168)? A: We need this to be usable with existing apps. e.g 'telnet www.example.bar<0xA8>' results sadness. It's also makes the solution really user-unfriendly. 2: Does this also get added to the"Locally Served DNS Zones" registry? A: "Earlier versions of this document requested that .ALT be added to the "Locally Served Zones" registry, and that a DNSSEC insecure delegation (a delegation with no DS record) be created at the root. Significant discussion on the DNSOP list (and an interim meeting) generated the consensus that these names are specifically not DNS names, and that them leaking into the DNS is an error. This means that the current (non-delegated) response of NXDOMAIN is correct as there is no DNS domain .alt, and so the document was updated to remove these requests. 3: Will there be a registry under .alt. A: Not one run by ICANN / the IETF, no. There is the expectation that people using this space will self-organize. A number of people have also offered to publish an informal list. 4: What is the current status / history? https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/history/ There was a WGLC started 2017-03-16: https://mailarchive.ietf.org/arch/msg/dnsop/tdp-OH3cYf6B9M0Kj1i7d2n6_KE This was then extended 2017-04-07: https://mailarchive.ietf.org/arch/msg/dnsop/zMchuCtfZU4jYFR5AEkAF1RB9wg I believe that we've addressed all open comments from the WGLC. It was marked as "Held by WG" (2018-07-17) while we dealt with the Special-Use Domain Names Problem Statement (which became RFC8244) It was discussed / presented at: DNSOP Interim meeting on Special Use Names, RFC6761 (May 12, 2015) - http://www.owl-stretching-time.com/presentations/IETF_DNSOP_Interim_May_2015.pdf IETF92 - https://www.ietf.org/proceedings/92/slides/slides-92-dnsop-5.pdf IETF95, IETF96 - https://datatracker.ietf.org/doc/slides-96-dnsop-14/ (missing) The Special Use Names interim: http://www.owl-stretching-time.com/presentations/ALT_TLD_2017_Interim.pdf It was also mentioned on the joint IETF DNSOP / ICANN interim to discuss SUDN PS document, and ICANN was invited to participate in the LC. I've just posted a new version (bumped the version / date, aggressive-nsec is now RFC8198, ) to revive it. I'd appreciate review and comments; I personally believe that this document solves a real issue, and I'd like to see it progress... W > > For 2, we seem to agree that future reservations, if any, will go under .arpa. > > For 3, we already did .test, .invalid, and .example which seem to have > solved that particular problem. I think the question of what might be > too cruddy to delegate is ICANN's problem. As you know better than I > do, ICANN has a big project to characterize "cruddy" and I don't see > the IETF having anything to contribute there. > > R's, > JOhn > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop