Subject: Re: [DNSOP] Some distinctions and a request

From: str4d <[email-masked]>
Date: Wed, 1 Jul 2015 05:47:44 +0000 (UTC)

Andrew Sullivan wrote:
> On Tue, Jun 30, 2015 at 11:43:42AM +0000, Edward Lewis wrote:
>> I'm not aware of "the rule" that declares Onion names as part of
>> the domain name space.  Not an argument, just a data point.  I've
>> always heard, and have been running on this, that Onion names are
>> not part of the DNS name space.
> 
> You're conflating "DNS name space" and "domain name space" again.
> I didn't say they're part of the DNS name space; and given what
> the top-level label onion. does, they can't possibly be.  At the 
> beginning, I claimed that the domain name space was all the
> logically possible domain names, not all the ones in fact possibly
> in the DNS. Under this definition, local. is part of the domain
> name space and not part of the DNS name space (because of local.
> being registered in the special use names registry).
> 
> When I asked about this before, one of the onion proponents told
> me that onion names have to conform to DNS (and, he claimed, LDH)
> rules right now, though that is a possibly temporary convention.

.onion and .i2p (and to my knowledge, the other proposed P2P-Names
TLDs too) have to conform to DNS rules in order to be usable in legacy
applications that expect domain names. In some future where the
percentage of apps requiring this is much lower (by most apps natively
supporting Tor/I2P/etc), the restriction could be removed. But while
domain names are the de-facto standard, I don't see it changing.

>> Alain Durrand and I talked about this a few weeks back.  He made
>> the point that you can distinguish the namespace of an identifier
>> "on the right" or "on the left" imaging the use of names in URLs.
>> I.e., there could be a "http-tor://tor-name.onion/path" and use
>> http-onion to tag this as a Tor identifier or
>> "http://tor-name.onion/path" and assume it's Tor because of the
>> onion where I'd expect(*) a domain name to be.
> 
> I think this is a terrible confusion of URI schemes vs. name-space 
> switches.  It's true that if you treat the URI as an unformatted 
> string you can parse it this way; but there are already rules for 
> that.  But I think anyway that's a distraction.  We don't need 
> uri-schemes to creep into this.

+1. Besides the confusion, this would require native app support,
because URI schemes are generally handled separately to name
resolution - you couldn't just use a SOCKS/HTTP/DNS proxy to handle
legacy applications, like Tor/I2P/GNUnet do now.

str4d

> Best regards,
> A