Paul, On Aug 13, 2022, at 7:26 PM, Paul Vixie <p...@redbarn.org> wrote: >> The problem is that every resolver implementation and deployment on the >> Internet, which assumes anything that looks like a domain name IS intended >> for the DNS, has to be modified to “do something different” when it sees >> that reservation and failure to do so mean the name is going to be looked up >> via the DNS. > that's a problem for future innovators.
Just to be clear: you’re saying to carve out namespace and let some future innovators figure out how to not dump queries for that namespace to the DNS? If so, I’m not sure what innovation you’re talking about -- this appears to largely be a solved problem via nsswitch (or equivalent). The actual problem is figuring out how to actually do the carve out. >> It didn’t block research into overloading the domain name namespace into >> protocols other than DNS (as Onion, mDNS, GNS, Namecoin, Handshake, >> Butterfly, etc., all demonstrate), it made it unscalable because of >> conventions of operating system vendors and application developers and >> assumptions of users. > if by unscalable you include the idea that if someone experiments with .XXX > they run the risk of having IANA later allocate that to some unique purpose, > then i agree with your use of that word. No. By "unscalable" I mean that if you want to use that carve out, you have get every stub resolver and every iterative resolver/forwarder on the planet to understand that the specified namespace partition is not to be handled by the DNS. Failure to do on both sides of any given session means one party won’t be able to establish the connection and (typically) the losing party sending queries to the root. It might be worth noting that according to https://ithi.research.icann.org <https://ithi.research.icann.org/>, .LOCAL, which shouldn’t be seen at the root, appears to account for 7% of all queries to the root. As for the concern you describe, the folks at IANA aren’t idiots and ICANN has already demonstrated (arguably over-) sensitivity to avoiding name collisions (see CORP, MAIL, and HOME). I suspect future name collision risk will be handled more or less the way it was handled in the last round, namely delegation won’t be done if the number of queries to the root for a particular label is above some arbitrary threshold. >>> warren's .ALT proposal can begin to undo that harm. internet standards >>> should describe roads not walls. i am no fan of blockchain naming, but i'd >>> like those systems to reach the market rather than be prevented from doing >>> so. >> Just to be clear: you believe folks like Handshake, Butterfly, Unstoppable >> Domains, etc., will be willing to be ghettoized into .ALT (or other)? And >> you also believe this will allow the use of (say) UD.ALT or HANDSHAKE.ALT to >> address the markets they’re trying to address? I’m not against moving >> forward with .ALT, but I’ll admit some skepticism that it will work as >> intended: it feels to me that it’s more an exercise in “if you build it, >> they will come” but without James Earl Jones. > i think GNU would use it. others can decide what to do. the worst case risk > is low, the best case benefit is high. so, to be clear, "yes". Not suggesting Martin speaks for GNU, but excerpting https://mailarchive.ietf.org/arch/msg/dnsop/S1Up3rDLNZi5RWCcMf_kY1clByQ/ <https://mailarchive.ietf.org/arch/msg/dnsop/S1Up3rDLNZi5RWCcMf_kY1clByQ/> "tl;dr: I am a bit ambivalent towards the ".alt" approach. For alternative name systems that are specified with status "Informational" the use of ".alt" seems highly unattractive as there is absolutely no benefit in using it but at the same time there are (obvious) disadvantages especially compared to other name systems which do not (try to) publish in the RFC series.” I agree with his analysis. >> As John Levine points out, this isn’t a technology issue: it is >> social/politica/economic/bureaucratic. ... > i'm aware of legal matters which could pertain, but i am not IETF's lawyer so > will not seek to advise them. Fair enough. I just think it is perhaps inadvisable for DNSOP to promote a model that attempts to short circuit efforts the IETF undertook back in 2000 to avoid this particular swamp. > what matters as an engineering question is that the domain name system camps > onto the whole of the domain-style / hierarchical / structure space of names, > and this was an error, and a carve-out is needed to facilitate innovation. It seems to me the “engineering question” is largely out of the purview of the IETF — folks who need to engineer solutions are operating system vendors and resolver implementers to write the code to understand that some TLDs shouldn’t be sent to the root. The real problem I see is how exactly the “carve out” is determined. ICANN’s process to partition the namespace resulted in a 300+ page application guide and entailed payment of (at least) US$185,000. Some people here think that’s wrong (would love to see their counter-proposal, but that’s off topic). The IETF has stabbed at this problem multiple times and not come up with an answer. Saying “we need a carve out because we made an error in 1984” seems unhelpful. Regards, -drc
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
