[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: iesg@ietf.org
Cc: dnsop@cafax.se
From: "D. J. Bernstein" <djb@cr.yp.to>
Date: 27 Feb 2000 20:56:43 -0000
Sender: owner-dnsop@cafax.se
Subject: Re: Last Call: Root Name Server Operational Requirements to BCP

[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

Home | Date list | Subject list