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