Your example has some problems for me. Problems which I guess your question was designed to draw out.
Firstly, *some* tor active clients operate by using bump-in-the-stack methods based or analogous to SOCKS. So, there is an API which intervenes on the normal operations and tunnels, and then its basically transparent. Where this happens, and how this happens begs questions about the DNS gethostby*() and getDNS*() api. -SOCKS does one set of things. the TOR-SOCKS model (I hypothesize, but I do believe this exists) may do something else. Secondly, applications which don't use generic bumps in (application) stacks, need to be re-coded to DTRT. So the .local example you gave, the different OS's do a different job of implementing a set-aside into mDNS: Its not uniformly available. "it depends" -And by analogy, one can expect that .onion set-aside logic will not be uniform: if I took an apparent FQDN xxxxx.onion on an SSH command line, and punched it into Opera, or Firefox, or Chrome, or Safari, or curl, or ftp, I *might* get different behaviours. I think the meta-question is a good question, but I don't think it only faces one way (into DNS, and how we think about DNS) -It faces into the problem space: "what is the set of mechanisms we have to hand, to try and do name-to-locator mapping" and some of them are domain names, and some aren't, and some have been coerced into the domain name space so that other processes (X.509 certificate behaviour) can work, because of the SubjectName and SubjectAlternateName being coerced into the dot-separated domain name form) On Mon, Sep 21, 2015 at 11:50 AM, Edward Lewis <edward.le...@icann.org> wrote: > On 9/18/15, 12:51, "DNSOP on behalf of Jim Reid" <dnsop-boun...@ietf.org > on behalf of j...@rfc1035.com> wrote: > > > > >On 18 Sep 2015, at 17:19, Joe Abley <jab...@hopcount.ca> wrote: > > > >> Whether or not we should call an onion or mdns name a "domain name" or > >>something else is just a detail. I don't think agreeing on the answer is > >>going to solve any of the problems that we actually have > > > >+1 > > I'm a little surprised at this response and the plus one. > > Here's the problem I see. > > Lets say I want to write a very basic SSH client (just to make the story > simple). Someone can then type "eds-ssh computer-name" and open up a > secured connection. > > If computer-name ends in .local, I open TCP to an IP address from the > lookup in mDNS. > > If computer-name ends in .onion, I open TCP to an IP address I get via Tor > (assuming that .onion supports remote shell). > > If computer-name ends in a digit, I suppose it's an address literal and > open TCP accordingly. > > If computer-name ends in whatever is in the DNS root zone, I find the > address in DNS. > > If computer-name ends in something not in the DNS root zone, I return an > error. > > The gotchas include, what if the latter two are indistinguishable because > the DNS resolver sent back a landing page - or the latter three if the > redirection service didn't recognize .onion as special. > > What if, in a year from now, .carrot becomes yet another way to resolve > names? > > What if, in the future, .alt is defined as having special meaning? (Note > - the fact that .alt is in an actual ID and .carrot is purely fictional > means .carrot is closer to being an RFC. ;)) > > It seems to me that a new layer of software is emerging between the UI and > the stub resolver, one that will need to know where to send a name > resolution query. (Perhaps even amongst DNS stub resolvers on different > interfaces.) This emerging layer needs to know how to direct it's work > flow. The Special Use Domain Names Registry would be the place to start > (but as it's written now, the emerging layer can't be future proofed). > > These are just TLD examples, perhaps a simplification. > > I see a fork in the codepath ahead regarding "whether the DNS is above > Domain Names" (like .alt) or whether "Domain Names are broader than what > was conveniently defined for a DNS". It's important to know which of > those two statements are true so we can get on with Special Use Domain > Names, and perhaps to find ways to objectively assign new names for new > uses. > > I think defining -whether- name.onion is a Domain Name will make us > re-think how Domain Names interoperate amongst protocols beyond the DNS. > > > _______________________________________________ > 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
