RE: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>

[John C Klensin <[e-mail]>]

--On Saturday, July 25, 2015 6:52 PM +0000 Christian Huitema
<[e-mail]> wrote:

> On Saturday, July 25, 2015 7:20 PM, John C Klensin wrote: 
>> ...
>>  My problem is that I don't see a stopping rule and the
>> idea of the IETF reserving names using our own collective but
>> very subjective judgment strikes me as risky, both wrt the
>> quality and completeness of the list and because I think ICANN
>> and IETF both benefit from clear delineation about boundaries
>> and responsibilities... 
>> 
>> I continue to believe that the most straightforward solution
>> is to turn the list-keeping over to them...
>> 
> 
> There is a technical problem: special purpose names, that have
> their own resolution process, different from the DNS. When a
> group developed such systems, the practice until now was to
> pick some reasonable top level name, such as ".local" or
> ".onion", and then ask for a special rule so that particular
> name could be excluded from the DNS. That was somewhat
> problematic, because it took some time for DNS code to be
> updated and exclude these names, but at least we "knew" that
> it did not conflict with ".net", ".org" or ".com." Well, we
> don't know that anymore.

Christian, as I have told others, there was, between
approximately when the DNS came into use and when ICANN decided
to ignore it, a firm rule about such names.  The rule was that
there would never been names (labels with delegation records) in
the DNS root longer than four characters, so one was free to
improvise with ".local", ".localhost", etc.  No special rules
(or additional special rules) needed.

"Onion." is another matter because, I assume, it started being
use after ICANN had abandoned the name-length restriction.

> We should note however that there is no technical requirement
> that special purpose domains be top level domains. When we
> developed the peer-to-peer naming system PNRP, we simply
> registered "PNRP.NET," and rooted the peer names there. That
> meets the "registration" requirement, but it does not meet the
> kind of special purpose processing that ".local" or ".onion"
> require, when security dictates that the special names must
> not me resolved by the DNS.

And that is exactly why I, and others, have been suggesting
since long before the most recent discussions started that, if
people believe in the DNS hierarchical structure, it was better
to use hierarchy than to create new special-purpose names at
root level, and far better the first squatting on such names and
then asking they be reserved on the grounds of deployment and
stability.  

> Suppose now that we reserved a special purpose top level
> domain, with the definition that it should not be resolved by
> the DNS, and that queries to it should always get an NXDOMAIN
> response from DNS servers. We might call it ".not" or ".nxd",
> or whatever other name ICANN might agree to. Developers of
> special purpose applications could reserve a second level
> domain such as "example.nxd". No risk of conflict with domain
> name entrepreneurs buying a conflicting domain, no risk of
> interference with DNS resolution.
> 
> Isn't that a reasonable path? 

Absolutely.  A few details aside, it is a path that several of
us have been suggesting on and off for years and that, as I
understand it, draft-ietf-dnsop-alt-tld is intended to
implement.  I also think that, once the TLD name is worked out
with ICANN and clearly delegated or reserved for this purpose,
it would be entirely reasonable to set up a registry of
reservations on a FCFS basis or something very close to it,
rather than having these painful IETF-list debates.

   john