Comments on Dotless Domains

[Dan Kaminsky <dan@xxxxxxxxxxx>]

My name is Dan Kaminsky.  I am best known in the DNS space for my work in
2008 helping to resolve a widespread security flaw in most DNS
implementations, that would allow malicious parties to hijack popular
domain names.  I write now to comment upon "dotless domains", i.e. the
potential behavior of Internet systems when faced with gTLDs that host
records at their apex and perhaps expect Internet links like "http://company";
to function.

In no uncertain terms, dotless domains cannot be expected to function, as
their "namespace" is already occupied.  They are already unstable; this
condition will increase, not diminish.

For a slightly larger explanation, the fundamental value proposition of DNS
is that it is a canonical namespace.  While ownership and control of
portions of the namespace are widely distributed, there is one (and only
one) owner and controller of google.com, one (and only one) controller of
microsoft.com, and so on.  While different answers may be provided to
different queriers (perhaps to provide more efficient servers to requestors
based on geographic proximity) the source of those answers is dependent
upon the one canonical source.

DNSSEC, the effort to apply cryptographic assurance to DNS responses,
leverages this canonical property to finally create a basis for trust on
the Internet.

There does exist a context within which there appear to be non-canonical
answers, and that is the dotless context.  A resolution attempt for
"company" will return different values when executed at Google headquarters
vs. Microsoft headquarters.  This resolution may apply different extensions
(upgrading company to company.google.com or company.microsoft.com) or may
not even occur using the DNS protocol.  But this context remains canonical;
the scope is reduced from "the entire world" to "this organizational unit".

This devolution of ground truth away from the root towards requesting
networks has both deep historical precedent, and active network dependency.
 All the way back in 1985, RFC 952 wrote:

   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
   sign (-), and period (.).  Note that periods are only allowed when
   they serve to delimit components of "domain style names".

Of course, many things were written in the 80's, the question is what
policy we can take from them.  RFC 2606 provides some guidance:

      The ".localhost" TLD has traditionally been statically defined in
      host DNS implementations as having an A record pointing to the
      loop back IP address and is reserved for such use.  Any other use
      would conflict with widely deployed code which assumes this use.

The standard of care in DNS then is one of "do no harm" -- one must not
conflict with widely deployed code, when altering the namespace.

Put simply, I can directly confirm that local namespaces in dotless forms
are extremely widely deployed, with dependencies all the way into network
architecture (via proxy configuration files) and web browser trust models.
 Furthermore, many systems, including many name servers and email systems,
are literally incompatible with the concept of querying via the root for
records that are not "domain style names".

gTLD operators control the records their servers emit, modulo policy or
contractual obligations.  They are in a technical position to host
responses to names that are not domain names.  Such actions, when they
work, override an existing canonical namespace (though one smaller than the
entire world).  When they do not work, they call into question the
universality of the global namespace.  "It might work" is simply not the
standard of functionality DNS has delivered for almost thirty years.

There is, of course, the security matter to consider.  Traffic that should
remain within organizational boundaries could very well leak globally, not
merely to the gTLD holder but also to each intermediate network -- possibly
across international lines.  Such traffic is particularly likely to be
unencrypted to do the implication of locality baked into the name itself.
 DNSSEC actually struggles with this as well, since now a validating stack
needs to ask -- for this dotless name, should a local key be used, or
should the key retrieved from the global root be used?

This is a particularly messy space, with deep history going back and
significant and difficult to debug engineering pain going forward.  I
recognize the marketing value of abandoning domain style names, but things
need to keep working.  I recommend that new gTLD operators be contractually
prohibited from hosting records at dotless domains.  I further recommend
that name server policy be officially updated to never query global roots
with dotless lookups.

Yours Truly,

   Dan Kaminsky
   Chief Scientist
   DKH