D. J. Bernstein
Internet publication
djbdns

The case against A6 and DNAME

Example: AOL committing A6 suicide

In an IPv6 world, dns-01.ns.aol.com and dns-02.ns.aol.com will probably share a common address prefix. The A6 specification encourages AOL to set up A6 records pointing to the common prefix:
     dns-01.ns.aol.com A6 ... prefix.aol.net
     dns-02.ns.aol.com A6 ... prefix.aol.net
     prefix.aol.net A6 ...
If AOL sets up these A6 records, nobody will be able to reach aol.com or aol.net.

Explanation: Let's say a cache needs the address of www.aol.com. It contacts the .com servers and learns

     aol.com NS dns-01.ns.aol.com
     aol.com NS dns-02.ns.aol.com
     dns-01.ns.aol.com A6 ... prefix.aol.net
     dns-02.ns.aol.com A6 ... prefix.aol.net
but it won't learn the address of prefix.aol.net. Even if the address is provided, the cache won't accept it, because .net addresses are not within the bailiwick of a .com server; this is the standard protection against poison.

(It is theoretically possible for caches to see that the prefix.aol.net address isn't poison, because the .com servers are the same as the .net servers. But let's fast forward to a time when the .com servers and the .net servers have been separated. The .com servers won't know the prefix.aol.net address, just as they don't know the ns1.nic.uk address today, and they won't have the authority to declare it even if they do know it.)

So the cache puts the www.aol.com query on hold. It needs the address of prefix.aol.net. It contacts the .net servers and learns

     aol.net NS dns-01.ns.aol.com
     aol.net NS dns-02.ns.aol.com
but it won't learn .com information from the .net servers.

So the cache puts the prefix.aol.net query on hold. It needs the address of dns-01.ns.aol.com. Repeat ad nauseam.

A quick overview of DNS lookups

I'm writing a program that talks to DNS servers to find an address given a domain name. How much memory do I need? How many servers do I need to contact?

I'll need as much as 64K for an incoming DNS message, during the brief moment before I parse it. There's not much persistent data:

A response from a server will give me the answer, or refer me to a closer zone. The number of queries is at most 4 for www.aol.com. Simple, isn't it?

Oops, that's not quite right. I might receive a CNAME. In that case I'll have to change the name and start over. This may happen several times. RFC 1034 says that the first CNAME ``should always'' get me to the canonical name, to avoid ``extra indirections,'' but it also says that I should follow chains if they do happen.

Suddenly there's no limit to the number of queries I need.

But wait. The algorithm still doesn't work. A referral to out-of-bailiwick names, such as the aol.net referral to dns-01.ns.aol.com and dns-02.ns.aol.com, won't include the addresses of those servers. I need to put the original query on hold while I look up those addresses. So here's what I actually have to store:

It doesn't end there. If there are names in the last list, I'll have to put the second lookup on hold while I look for the addresses of those names. And so on.

Suddenly there's no limit to the amount of space I need. I don't have a single small array of addresses; I have an unlimited-length array of small arrays of names and addresses. This isn't so simple any more.

DNS reliability problems

Out-of-bailiwick pointers destroy DNS lookups in three ways: These problems are not new. Lookups occasionally fail because system administrators have used too many out-of-bailiwick NS records, for example. (I tell my users to select in-bailiwick server names. My software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default server names for fqdn. I also tell my users to avoid CNAME records.)

What is new with A6 and DNAME is that out-of-bailiwick pointers are encouraged. System administrators are encouraged to set up giant A6 chains and giant DNAME chains reflecting their corporate structures and network structures. The result will be a tremendous increase in the frequency of DNS lookup failures.

I refuse to implement A6 and DNAME. I cannot bring myself to inflict such a rickety system on future Internet users. As of February 2001, nobody is relying on A6 or DNAME; I recommend that the A6 and DNAME proposals be terminated.

Server-side indirection

Why did the original DNS design include CNAME records? Why did it have names, rather than addresses, in NS records and MX records? Why do DNS packets have an ``additional section''?

RFC 1035 responds: If you copy a machine's address into an NS record, then you have to watch for changes in the address, and echo them. Indirection ``avoids the opportunity for inconsistency.''

I agree: indirection is good. But it didn't have to be a protocol feature handled by caches. It could have been handled by the server.

Instead of publishing ftp.isc.org CNAME isrv4.pa.vix.com, for example, the isc.org server can periodically look up the address of isrv4.pa.vix.com and copy it to the address of ftp.isc.org. It doesn't matter whether isrv4.pa.vix.com was copied from somewhere else. There are no chains of pointers to follow. The system is reliable.

Server-side indirection has three minor effects on DNS load:

The total effect could be positive or negative. It is certainly not overwhelming. I'm not going to throw away reliability, even if doing so might save a few DNS queries.