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

[Christian Huitema <[e-mail]>]

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.

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.

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? 

-- Christian Huitema