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.netbut 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.combut 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.
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:
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:
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.
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.
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: