a.ns.fqdn

["D. J. Bernstein" <djb@cr.yp.to>]

Executive summary: RRP should be changed to allow, and perhaps require,
NS names for a domain to be within the domain. In particular, multiple
names with the same IP address have to be allowed.


Security issue #1: Out-of-domain NS records mean that the domain's
security relies not only on the security of its servers, but also on the
security of the servers _for the NS names_, and the servers for the
names of _those_ servers, etc.

Right now, for example, there are more than 200 computers that can
easily take over *.com by following out-of-domain NS chains. See

   http://www.securityfocus.com/vdb/bottom.html?vid=941

for details. This problem is eliminated by in-domain NS records.


Security issue #2: What stops an attacker from registering a new .com
domain with NS record www.yahoo.com and his own IP address? Caches will
accept this information as glue from the .com servers, and will then
forward www.yahoo.com requests to the attacker.

This problem is eliminated if out-of-domain server names are prohibited.
In fact, server names could be standardized as a.ns.fqdn, b.ns.fqdn,
etc. Side benefit: the .com database can be stored in much less space.

ISPs will still want the ability to say ``move all my 1.2.3.4 servers to
1.2.3.5'' on occasion, but this feature can be provided at a higher
level, just like ``remove all my 1.2.3.7 servers'' and ``split my
1.2.3.4 registrations randomly between 1.2.3.5 and 1.2.3.6'' and other
management features.

(Old names need to be left alone, in case *.ns.fqdn is already in use,
but registrants can be encouraged to switch.)


Security issue #3: An attacker can register hosts under a new site's IP
addresses, preventing the new site from registering its servers. The new
site has to complain to its .com registry, and then wait until the old
registration is manually removed.

This problem is eliminated if multiple names are allowed to have the
same IP address.

(How exactly does the manual procedure work? Can an attacker convince a
registry to remove a legitimate registration?)


Efficiency/reliability issue: When a domain under .com has an NS record
under (say) .net, the .com servers provide the address for that NS, but
caches discard the address as possible poison. Caches have to start
extra queries (``sysqueries'' in BIND) to look up the addresses.

This increases the frequency of long lookup delays. Even worse, when
there are too many out-of-domain NS records, resolutions start failing.
See

   http://cr.yp.to/dnscache/notes.html#gluelessness

for further comments. This problem doesn't occur with in-domain NS
records.


Convenience issue: It saves time for system administrators when software
can use automatic default server names of a.ns.fqdn, b.ns.fqdn, etc.,
without tripping over IP-address-uniqueness rules.


When I pointed out these problems to Scott in January, he wrote back:
``There's nothing inherently bad about allowing multiple name servers or
A records to share an IP address; I believe we'll remove that
restriction in either a subsequent version of the protocol or in a
standards track protocol to be developed through the IETF.''

Why not fix the protocol right now? It should be trivial to at least
change NSI's software to allow multiple names with the same IP address.

An NSI employee---he can identify himself if he wants, which I doubt---
subsequently told me that the IP-address prohibition stops people from
pointing their domains at other people's servers without authorization.
That's simply not true. People can use other people's server names in NS
records, achieving the same effect.


---Dan