--On Saturday, July 25, 2015 6:52 PM +0000 Christian Huitema
<huitema(_at_)microsoft(_dot_)com> 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