Re: domain names that are not DNS names, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jul 21, 2015, at 2:04 PM, John Levine <johnl@xxxxxxxxx> wrote:
Right.  But connect_to_name is just what SOCKS does.  I agree that
SOCKS has its problems, but in this case its API is pretty good for
name-that-is-not-in-the-DNS-for-service-that-is-not-TCP.

Okay, that’s an interesting point, but the way it works is that you have a switch based on the TLD.   There is no other way to make it work.   So this is basically orthogonal to the question we are discussing.

Even if we posit a cleaner connect_to_name than SOCKS, and an extended
nsswitch.conf that handles mappings from names to libraries that
implenent various non-TCP transports, we're still back to the question
of where does the list of names and libraries come from.

Happily, there is an IANA registry for special-use domain names!   :)

But if you mean “should we have some other process,” the answer may be yes, but I don’t see how to get there from here.   In order for us to have a process that could work, we’d need for it to be the case that ICANN doesn’t allocate new TLDs under some other process, and that ship has, for better or for worse, sailed.   I don’t see any way to put the toothpaste back in the tube.   I wish that the terms of service for ICANN back when we gave them authority over the namespace were that TLDs had to be allocated through an IETF process.   That would make a lot more sense than the status quo.   But the status quo is, by some strange definitional twist of fate, what we have.

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]