Re: Last Call: Root Name Server Operational Requirements to BCP

["Donald E. Eastlake 3rd" <dee3@torque.pothole.com>]

Yes, it is true that DNS was, is, and will remain inherently insecure
until DNSSEC or something equivalent is deployed.

Donald

From:  "D. J. Bernstein" <djb@cr.yp.to>
Date:  27 Feb 2000 20:56:43 -0000
Message-ID:  <20000227205643.28700.qmail@cr.yp.to>
To:  iesg@ietf.org
Cc:  dnsop@cafax.se
References:  <200002251532.KAA11646@ietf.org>

>[This message is bcc'ed to some of the relevant administrators.]
>
>There is a serious conceptual error behind the ``security'' requirements
>in root-opreq-03. See
>
>   http://cr.yp.to/dnscache/bugtraq/20000123114946-2072-qmail@cr-yp-to
>
>for details.
>
>The basic problem is that, when X has an NS record of Y, anyone with
>control over the Y name can take control over all X names. For example,
>an attacker who breaks into galileo.cc.rochester.edu (which is running
>Sendmail 8.8.5 and BIND 8.2) can
>
>   (1) take control over *.utd.rochester.edu, then
>   (2) take control over *.rochester.edu, then
>   (3) take control over *.cornell.edu, then
>   (4) take control over *.se, then
>   (5) take control over *.ripe.net, then
>   (6) take control over *.root-servers.net, then finally
>   (7) take control over the entire network.
>
>It doesn't do any good to secure a high-level server without also
>protecting the _name_ of that server, which means securing the servers
>for that name, and the servers for the names of _those_ servers, etc.
>
>For a complete list of the servers that currently have this type of
>control over (say) aol.com, compile my DNScache package from
>
>   http://cr.yp.to/dnscache/install.html
>
>and run
>
>   dnstrace any aol.com `cat @` > TRUSTED-BY-AOL
>
>The output is over half a megabyte long, showing hundreds of different
>computers. Be happy that there aren't thousands!
>
>The simplest fix is an additional configuration requirement to use
>in-zone names for all NS records. This also improves the speed and
>reliability of DNS, as explained in
>
>   http://cr.yp.to/dnscache/notes.html#gluelessness
>
>This is current practice at many sites, and it's clearly better practice
>than what the high-level servers are doing.
>
>Note that NSI's prohibition on different server names with the same IP
>address will have to be scrapped. This would be a useless prohibition
>even if it weren't a security problem. (One NSI employee has told me
>that this prohibition stops people from pointing their domains at other
>people's servers without authorization. That's simply not true.)
>
>---Dan