Re: [DNSOP] perspective Re: Thoughts on the top level name space

[Edward Lewis <[e-mail]>]

On 7/8/15, 7:36, "Suzanne Woolf" <[e-mail]> wrote:

>For example, the distinction between gTLDs and ccTLDs is of great
>importance to ICANN and to participants in its decisions, but of less
>obvious relevance to an application developer or DNS operator who sees
>only "name that gets a positive response to a DNS query against the
>public root zone."

It's not that the distinction between gTLDs and ccTLDs matters, I believe
that what matters first is whether this is an issue best handled in the
DNS protocol or in the operational conventions applied to placing names
into the root zone.  As much as I spend time trying to distinguish
characteristics of TLDs, I don't think any of that really matters in this
context, at least in the high level.

If a name is meant to be represented in the DNS, then delegate it, NS/DS
set and all.  If a name is not meant to be in the DNS, then we can 1)
simply reserve it from being delegated, 2) delegate it in a way that
shunts all queries to /dev/null or 3) alter code paths such that the name
is never spoken over port 53.

A clear definition that hasn't been made is what names are we talking
about.  Re-reading notes, it seems that all the use cases match, to date,
host names and there are specifications that bear that out.  Such as
pointing to RFC 1123's definition of a host name.  But the described use
of onion would break that assumption.  This lack of definition isn't a
show stopper but to be pedantic about it, no one has offered up why we
talk about "domain" names.  (RFC799 seems to be the origin, citing mail
domains, but that is in the context of mail servers.)

>It seems to me, as a first cut, that the important thing to take into
>account here is that the production DNS root zone is dynamic-- just as
>any other chunk of the namespace. We're accustomed to thinking of the
>root zone as special, and indeed it's still far less dynamic than other
>areas of the namespace, for good reason-- but it's not static. Rules we
>try to derive today could change within foreseeable time. (Some of us
>are/were opposed to the decisions that resulted in this fact, but it
>remains a fact.)

It's been dynamic for a decade, NS sets change and there has been activity
in ccTLDs and even some sporadic gTLD delegations, not to mention test
IDNs coming and going.  I sense the fear is more in the way other pieces
of software treat the root zone.  I recall a past version of a general
purpose, open-source name server that would refuse to load a zone as the
root unless explicitly informed the operator was sane.

The concern returns once again to what I see as a central question - is
this about the protocol or the operational convention of registering names
in the root zone?  If it is the former, we are tinkering with, perhaps,
the production of the root zone.  If it is the latter, we are tinkering
with the submission process.

>It further seems to me that an attempt to list names that are currently
>in the public root zone or might someday be in the public root zone has a
>high risk of being simply backwards if the purpose is to identify names
>it's "safe" to use in other contexts because they won't collide with
>names in the public root zone.  Our current approach as documented in RFC
>6761 comes at this question from the perspective that the IETF can
>declare whatever names it likes to be so "protected" by extending the
>standard with a new entry in the special use names registry, but takes no
>account of any possible distinctions between names currently in use at an
>arbitrary time for the DNS, names that will (or even might) be in use at
>a future time for the DNS, and any other categories.
>
>We might want to decide which, if any, of such distinctions are
>meaningful for the purposes of the IETF identifying "special use names".

"Special Use Domain Names"  The third word is central to this thread is
often omitted.  It is why we should have a definition of 'domain' names,
state whether this applied to the operation of the global public Internet
or is a matter of altering the standard, base, protocol.

One perspective I think needs to be addresses too is "what is the process"
for registering a name in the root zone registry?  What does it mean?

There is the ICANN process.  The process has been defined by a community
process akin to the IETF albeit with more structure to the community.
When I see words like "to ICANN and to participants in its decisions" I
cringe because that is giving credit to the wrong group when it comes to
many of the processes.  ICANN does implement what comes in from community
processes so there may be an appearance of the ICANN staff making
decisions.  But this is as much a function of what comes from the
community.  But this isn't what I want to impart.  (There have been
threads on whether it's as easy to participate in IETF or ICANN
communities.  I'll leave that as an open topic.)

There's been talk that the price of a TLD is high.  I am unable to
rationalize all of the price tag, but it covers a lot of work done by a
lot of people when it comes to clearing a name for registration and
delegation. I'm not going to try to justify the price here, but I do think
it's is instructive to keep in mind the work needed before a name is
delegated.

Is a name going to work?  Does it meet protocol limitations?  That's
pretty simple.

Is the name compatible with the existing set of code out there?  Are names
in use that would be disruptive?  For example, "local."  For this the IETF
list is important.

Is the name offensive?  This is something we don't talk about inside
engineering circles, it's highly subjective.  But what if some managed to
deploy a system using a top name what is, well, offensive.  Perhaps having
a thick skin makes one think it is okay, but still it might incite violent
reactions by others.

Does the name conflict with another use in a way that causes harm?  Could
someone, seeing it or copying it from hardcopy be fooled by the name?

Is it visually similar?  1 vs. i, Cyrillic 'a' vs. Latin 'a' and so on.

There are other reasons...but I'll skip to the last obvious one - will a
registry for the name work?  I raise this because this is a part of the
current process for gTLDs but is one that is not applicable to names that
are not meant to be registries.

I've been kicking the process around in my mind the past weeks.  I keep
thinking there's a easy way around all this work, but I don't think so
(except for the last one).  If it were, then the price of a new TLD need
not be so high.

But I keep coming to this, decidedly non-engineering, question:  What if
someone uses RFC 6761 to get an offensive name registered as a special-use
domain name?  What organization is going to bear the risk of dealing with
any potential fallout from the registration?  Well, maybe I'm wrong about
this - objections raised about operating something with an offensive name
more so than recognizing a name is offensive.  What if I have to have the
name in my code paths though?

I'm not against innovation and using (domain) names for things that will
not be in the DNS.  I am against altering code paths such that we restrict
the use the DNS protocol in other contexts or in the future.  I am against
putting the IETF in harms way if someone manages to "game the system" for
one purpose or another.

I do think an alt-TLD is needed, one that avoids the trouble some strings
might bring.  I do think that the IETF needs a process for determining
what names should not be activated (given NS sets in the root zone), or at
least provide recommendations for what should not be activated.

Perhaps IETF last call is what people feel is sufficient to judge whether
an idea has consensus.  In many ways, I'm not all that confident.  Last
calls are only heard by those that are subscribed to the lists.  (That's
behind my comment that I'm concerned by the not-engaged developer
population.)