--On Wednesday, July 15, 2015 22:59 +0000 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
...
I entirely agree that we should discourage people from
inventing new naming schemes that borrow top level names in
the DNS. Life would be easier all around if they put them
under .ARPA or .ALT or made them not look like domain names.
But since we are not the Network Police, people will do
whatever they do, and we as engineers need to make it work as
best we can.
...
John,
One thing that makes this particular range of cases interesting
is that, while there are no Network (or Protocol) Police for
dealing with violations of, e.g., HTTP or DNS specs, there is an
organization whose very explicit mission is to oversee and
manage the top-level domain name space and allocations and
reservations in it. We can, and have, placed limits on what
they can do based on protocol requirements or constraints
(consider, for example, the requirement that labels in the root
be either ASCII "LD" strings or non-ASCII strings in ACE form
and fully compliant with IDNA2008). By deciding that we are
going to make these decisions, we deprive ourselves of one of
the major sets of tools that is available to the overall
community. That may be a good choice for other reasons, but
"not the Network Police" isn't, IMO, one of them.
Similarly, "people will do whatever they do" does not translate
into an obligation on us to aid and abet. I note, for example,
that, while spammers and spreaders of malware will do whatever
they do, we've never published documents or designed facilities
to make their work more efficient. Indeed, the IETF and the
broader community have put a lot of effort into ways to make
their lives more difficult and their efforts less efficient and
effective.
So if some maniac invented a new application that used
.COCA-COLA outside the DNS, and we found that millions of
other maniacs around the world were using it, our job as
engineers is to make things work, which would likely involve
saying that .COCA-COLA can't be in the DNS. It's not hard to
imagine some people who'd be dismayed at that, but I don't see
that as our problem.
Where we may disagree is that I don't think "our job as
engineers" is to start banning names. It might be the best
possible solution for the community in the present environment
but that doesn't make it our problem. It _is_ "our job as
engineers" to make it easier to detect bogus-apparent root zone
entries. That is part of what DNNSEC is ultimately about and we
did that job. However, I note that, from an engineering
standpoint, the original and later vintage RFC 1591 rules and
design -- rules and design that involved a small number of names
at root level, very low volatility of those names and
definitions (allowing easy checking against lists), and a notion
that one could distinguish "special names" by simply making the
labels longer than four characters -- were far more satisfactory
than the current environment in which it is necessary to deal
with each name on a case-by-case basis and then hope for the
best and that everyone concerned gets the message. The present
situation may be entirely justified by other considerations and
we may have to engineer to adapt to it, but that doesn't make
any of this good engineering.
john