Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[Alec Muffett <[e-mail]>]

On Aug 10, 2015, at 9:50 AM, Ted Hardie <[e-mail]> wrote:
> 
> I believe that the registry we have currently defined doesn't do a great job of capturing the actual needs here.  It doesn't define what the larger namespace encompassing the DNS is or could be well, and it doesn't provide a way to note the continuing evolution of the non-DNS resolution processes.  It does a fine job with .example since that's fundamentally just a reservation, but .onion is showing its warts.
> 
> I understand the urgency of the .onion case, but I suspect that we're going to have to split it back out of the current registry once we have fixed the problems with the registry itself.  I am wondering if there is a way forward here where we permit the registration in the existing registry, but with a note that it will likely move into either a different registry or an expanded registry in the future.
> 



Hi Ted, thanks for the feedback.

I don’t see any question in the above which impinges upon the draft so much as being related to internal operations of IETF and/or DNSOP, but I’d like to reinforce that CA/B-Forum are apparently happy so long as “.onion” is part of the recognised global namespace.

The minutiae of which bucket that lives in is probably not an issue? (Tag: Mark Nottingham, Richard Barnes)

It strikes me that if labels “beneath” the .onion special domain name may in future exceed the bounds expected of DNS - but the root is acknowledged to have global legitimacy - then it’s all to the better that DNS software is aware of “.onion” and basically ignores it, which it the other intent of the draft.


In an e-mail elsewhere I recently noted:

>> A scan of section 3.2.2 of RFC3986 “Uniform Resource Identifier (URI): Generic Syntax” - I won’t claim to have read the whole thing - seems quite open to the existence of [namespaces other than DNS being used in URIs]:
>> 
>> A host identified by a registered name is a sequence of characters usually intended for lookup within a locally defined host or service name registry, though the URI's scheme-specific semantics may require that a specific registry (or fixed name table) be used instead. The most common name registry mechanism is the Domain Name System (DNS).
>> 
>> [...dns format description elided...]
>> 
>> This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg-name beyond what is necessary for interoperability. Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. However, a globally scoped naming system, such as DNS fully qualified domain names, is necessary for URIs intended to have global scope. URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length.

Nothing appears in there about DNS’s (semantic) 63-character label lengths, instead the constraint defined is DNS “syntax” - arguably "strings of alnumhyphen separated by dots" - and an overall 255-character length limit.

Next-generation Onion Address Syntax has not yet been agreed, but the current plans exist within this syntax-and-255-limit definition, eg:
> a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion # first label exceeds 63 characters, hypothetical illustration only
Existing Onion-Address Syntax (facebookcorewwwi.onion) is completely within existing DNS’s apparent semantics as well as syntax.

Of course, this is orthogonal to the matter of registries within registries which you raise above, but I feel it worth raising.

    -a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London