17.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 nameservers, you probably wouldn't have cared about the subtle nuances of the magical CNAME record. Some of this trivia is interesting, some is arcane. We'll let you decide which is which.

17.1.1. CNAMEs Attached to Interior Nodes

If you've ever renamed your zone because of a company reorganization or acquisition, 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.edulike the SOA record and NS records that are undoubtedly therebut 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 waya 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 applies 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 datafiles can handle creating CNAME records for you. (h2n, which was introduced in Chapter 4, does just that.)

17.1.2. CNAMEs Pointing to CNAMEs

You may have wondered whether it is 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) nameserver implementation emerges.^[*]

^[*] And one has (the Microsoft DNS Server, shipped with server versions of Windows). It also permits CNAMEs that point to CNAMEs, though.

17.1.3. CNAMEs in the Resource Record Data

For any other record besides a CNAME record, you must use canonical domain names in the resource record data. Applications and nameservers won't operate correctly otherwise. As we mentioned back in Chapter 5, for example, sendmail recognizes only 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 correct MX records out when paring down the MX list and may try to deliver mail to itself or to less preferred hosts, causing mail to loop.

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

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

BIND 9 nameservers, unfortunately, don't seem to notice.

17.1.4. Multiple CNAME Records

One pathological configuration that honestly hadn't occurred to usand many pathological configurations have occurred to usis 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

can be used to return all the addresses attached to fullmonty1, then all the addresses of fullmonty2, then all the addresses of fullmonty3 on a nameserver 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.

17.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
> toys
Server:  wormhole
Address:  0.0.0.0

toys.movie.edu  canonical name = toystory.movie.edu

> set query=any
> toys
Server:  wormhole
Address:  0.0.0.0

toys.movie.edu  canonical name = toystory.movie.edu
> exit

% dig toys.movie.edu cname
; <<>> DiG 9.3.2 <<>> toys.movie.edu cname
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43984
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;toys.movie.edu.                    IN    CNAME

;; ANSWER SECTION:
toys.movie.edu.         86400 IN CNAME     toystory.movie.edu.

17.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 toystory /etc/hosts
192.249.249.3  toystory.movie.edu toystory toys

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

% nslookup
Default Server:  wormhole
Address:  0.0.0.0

> toystory
Server:  wormhole
Address:  0.0.0.0

Name:    toystory.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

> toys
Server:  wormhole
Address:  0.0.0.0

Name:    toystory.movie.edu
Address:  192.249.249.3
Aliases:  toys.movie.edu

> exit

% dig toys.movie.edu

; <<>> DiG 9.3.2 <<>> toys.movie.edu
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29782
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
; toys.movie.edu.                    IN    A

;; ANSWER SECTION:
toys.movie.edu.         86400 IN CNAME     toystory.movie.edu.
toystory.movie.edu.     86400 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.
toys                    1D IN CNAME     toystory
wh                      1D IN CNAME     wormhole
mi                      1D IN CNAME     monsters-inc
>

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.