“we have seen only one” is not true. What is true is that we pretty much told everyone who asked to go away, with the exception of .onion. E.g., .home was told to go away, and we wound up using home.arpa instead, which is perfectly fine for our use case.
Your observation about implementation is a bit of an overgeneralization from a fairly specific implementation. Different operating systems, and indeed different resolver libraries on Linux, do different things. There’s no reason this can’t be done in a way that is regular—it’s just that because there are so few exceptions, the motivation to clean this up isn’t that strong. But e.g. on Apple devices, if you want to do something like this, you have to do it the one way that it can be done, or build your own resolver library. Ultimately, though, that’s not the IETF’s problem. Our problem is to specify namespaces for which alternate resolution mechanisms are required (or you may think that is /not/ our job, of course!). Sent from my iPad > On Aug 18, 2022, at 6:30 PM, John Levine <[email protected]> wrote: > > It appears that Eliot Lear <[email protected]> said: >> 1. Conflicts can be avoided between deployments of cooperating name >> systems; and > > It seems to me that the key word here is "cooperating." Considering > how many projects squat on various bits of the DNS name space, we have > seen only one show any interest in the RFC route> I think it's fair to > assume most of the rest will continue to do what they're doing now if > we make them jump through our hoops. That's why we need to make it as > easy as possible to tell people what name you're using, i.e., FCFS > allowing duplicates. > >> 2. A protocol switch is created in that label (xyz.gns.alt->gns, >> xyz.eliot.alt->eliot name service) > > This is a swell research project but it is hard. Off the top of my > head I can think of at least three different places we do the protocol > switch now (socks for .onion, RRs for split horizon and homenet, fake > A/AAAA for mDNS.) I doubt I've thought of all the places people do it > now and I am sure I have not thought of ones people might try in the > future. > > R's, > John > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
