16.1 Using CNAME Records

We talked about CNAME resource records in Chapter 4. We didn't tell you everything about CNAME records, though; we saved that for this chapter. When you set up your first name servers, you didn't care about the subtle nuances of the magical CNAME record. Maybe you didn't realize that there was more than we explained; maybe you didn't care. Some of this trivia is interesting, some is arcane. We'll let you decide which is which.

16.1.1 CNAMEs Attached to Interior Nodes

If you've ever renamed your zone because of a company reorganization, you may have considered creating a single CNAME record that pointed from the zone's old domain name to its new domain name. For instance, if the fx.movie.edu zone were renamed magic.movie.edu, we'd be tempted to create a single CNAME record to map all the old domain names to the new names:

fx.movie.edu.  IN  CNAME  magic.movie.edu.

With this in place, you'd expect a lookup of empire.fx.movie.edu to result in a lookup of empire.magic.movie.edu. Unfortunately, this doesn't work—you can't have a CNAME record attached to an interior node like fx.movie.edu if it owns other records. Remember that fx.movie.edu has an SOA record and NS records, so attaching a CNAME record to it violates the rule that a domain name be either an alias or a canonical name, not both.

If you're running BIND 9, though, you can use the brand-spanking-new DNAME record (introduced in Chapter 10) to create an alias from your zone's old domain name to its new one:

fx.movie.edu.  IN  DNAME  magic.movie.edu.

The DNAME record can coexist with other record types at fx.movie.edu—like the SOA record and NS records that are undoubtedly there—but you can't have any other domain names that end in fx.movie.edu. It'll "synthesize" CNAME records from domain names in fx.movie.edu to like domain names in magic.movie.edu when the names in fx.movie.edu are looked up.

If you don't have BIND 9, you'll have to create aliases the old-fashioned way—a CNAME record for each individual domain name within the zone:

empire.fx.movie.edu.       IN  CNAME  empire.magic.movie.edu.
bladerunner.fx.movie.edu.  IN  CNAME  bladerunner.magic.movie.edu.

If the subdomain isn't delegated, and consequently doesn't have an SOA record and NS records attached, you can also create an alias for fx.movie.edu. However, this will apply only to the domain name fx.movie.edu and not to other domain names in the fx.movie.edu zone.

Hopefully, the tool you use to manage your zone data files will handle creating CNAME records for you. (h2n, which was introduced in Chapter 4, does just that.)

16.1.2 CNAMEs Pointing to CNAMEs

You may have wondered whether it was possible to have an alias (CNAME record) pointing to another alias. This might be useful in situations where an alias points from a domain name outside your zone to a domain name inside your zone. You may not have any control over the alias outside your zone. What if you want to change the domain name it points to? Can you simply add another CNAME record?

The answer is yes: you can chain together CNAME records. The BIND implementation supports it, and the RFCs don't expressly forbid it. But while you can chain CNAME records, is it a wise thing to do? The RFCs recommend against it because of the possibility of creating a CNAME loop and because it slows resolution. You may be able to do it in a pinch, but you probably won't find much sympathy on the Net if something breaks. And all bets are off if a new (non-BIND-based) name server implementation emerges.^[1]

^[1] And one has (the Microsoft DNS Server, shipped with Windows NT and Windows 2000). It also permits CNAMEs that point to CNAMEs, though.

16.1.3 CNAMEs in the Resource Record Data

For any other record besides a CNAME record, you must have the canonical domain name in the resource record data. Applications and name servers won't operate correctly otherwise. As we mentioned back in Chapter 5, for example, sendmail only recognizes the canonical name of the local host on the right side of an MX record. If sendmail doesn't recognize the local host's name, it won't strip the right MX records out when paring down the MX list, and may deliver mail to itself or to less-preferred hosts, causing mail to loop.

BIND 8 name servers log messages like these when they encounter aliases on the right side of a record:

Sep 27 07:43:48 terminator named[22139]: "digidesign.com IN NS" points to a CNAME (ns1.digidesign.com)
Sep 27 07:43:49 terminator named[22139]: "moreland.k12.ca.us IN MX" points to a CNAME (mail.moreland.k12.ca.us)

16.1.4 Multiple CNAME Records

One pathological configuration that honestly hadn't occurred to us—and many pathological configurations have occurred to us—is multiple CNAME records attached to the same domain name. Some administrators use this with round robin to rotate between RRsets. For example, the records:

fullmonty  IN  CNAME  fullmonty1
fullmonty  IN  CNAME  fullmonty2
fullmonty  IN  CNAME  fullmonty3

could be used to return all the addresses attached to fullmonty1, then all the addresses of fullmonty2, then all the addresses of fullmonty3 on a name server that didn't recognize this as the abomination it is. (It violates the "CNAME and other data" rule, for one.)

BIND 4 doesn't recognize this as a misconfiguration; BIND 8 and 9.1.0 and later do. BIND 8 lets you permit it if you want to with:

options {
                multiple-cnames yes;
};

In BIND 9, there's no option to allow it. The default, naturally, is to disallow it.

16.1.5 Looking Up CNAMEs

At times you may want to look up a CNAME record itself, not data for the canonical name. With nslookup or dig, this is easy to do. You can either set the query type to cname, or set the query type to any and then look up the name:

% nslookup
Default Server:  wormhole
Address:  0.0.0.0

> set query=cname
> bigt
Server:  wormhole
Address:  0.0.0.0

bigt.movie.edu  canonical name = terminator.movie.edu
> set query=any
> bigt
Server:  wormhole
Address:  0.0.0.0

bigt.movie.edu  canonical name = terminator.movie.edu
> exit

% dig bigt.movie.edu cname
; <<>> DiG 8.3 <<>> bigt.movie.edu cname 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4
;; QUERY SECTION:
;;      bigt.movie.edu, type = CNAME, class = IN

;; ANSWER SECTION:
bigt.movie.edu.         1D IN CNAME     terminator.movie.edu.

16.1.6 Finding Out a Host's Aliases

One thing you can't easily do with DNS is find out a host's aliases. With the host table, it's easy to find both the canonical name of a host and any aliases: no matter which you look up; they're all there, together, on the same line:

% grep terminator /etc/hosts
192.249.249.3  terminator.movie.edu terminator bigt

With DNS, however, if you look up the canonical name, all you get is the canonical name. There's no easy way for the name server or the application to know whether aliases exist for that canonical name:

% nslookup
Default Server:  wormhole
Address:  0.0.0.0

> terminator
Server:  wormhole
Address:  0.0.0.0

Name:    terminator.movie.edu
Address:  192.249.249.3

If you use nslookup or dig to look up an alias, you'll see that alias and the canonical name. nslookup and dig report both the alias and the canonical name in the message. But you won't see any other aliases that might point to that canonical name:

% nslookup
Default Server:  wormhole
Address:  0.0.0.0

> bigt
Server:  wormhole
Address:  0.0.0.0

Name:    terminator.movie.edu
Address:  192.249.249.3
Aliases:  bigt.movie.edu

> exit
% dig bigt.movie.edu
; <<>> DiG 8.3 <<>> bigt.movie.edu 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 4
;; QUERY SECTION:
;;      bigt.movie.edu, type = A, class = IN

;; ANSWER SECTION:
bigt.movie.edu.         1D IN CNAME     terminator.movie.edu.
terminator.movie.edu.   1D IN A         192.249.249.3

About the only way to find out all the CNAMEs for a host is to transfer the whole zone and pick out the CNAME records in which that host is the canonical name:

% nslookup
Default Server:  wormhole
Address:  0.0.0.0

> ls -t cname movie.edu
 [wormhole.movie.edu]
$ORIGIN movie.edu.
bigt                    1D IN CNAME     terminator
wh                      1D IN CNAME     wormhole
dh                      1D IN CNAME     diehard
>

Even this method shows you the aliases only within that zone—there could be aliases in a different zone, pointing to canonical names in this zone.