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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
