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 there was more to it 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 the new domain name. For instance, if the fx.movie.edu zone were renamed to magic.movie.edu, we'd be tempted to create a single CNAME record to map all the old names to the new names:

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

With this record 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. So, instead of using a single CNAME record to rename a complete zone, we'll have to do it the old-fashioned way—a CNAME record for each individual host 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 to it, you can create an alias for fx.movie.edu, but it will apply only to the domain name fx.movie.edu and not to domain names under fx.movie.edu.

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 of your zone to a domain name inside your zone. You may not have any control over the alias outside of your zone. What if you want to change the domain name to which it points? Can you simply add another CNAME record?

The answer is yes: you can chain together CNAME records. The Microsoft DNS Server 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 if something breaks.

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, many mailers recognize only the canonical name of the local host on the right side of an MX record. If a mailer doesn't recognize the local host, it won't strip out the right MX records when paring down the MX list and may deliver mail to itself or to less-preferred mail exchangers, causing mail to loop.

16.1.4 Looking Up CNAMEs

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

C:\> nslookup 
Default Server:  wormhole.movie.edu 
Address:  192.249.249.1 

> set query=cname 
> bigt 
Server:  wormhole.movie.edu 
Address:  192.249.249.1 

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

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

16.1.5 Finding Out a Host's Aliases

One thing you can't easily do with nslookup—or any query tool, for that matter—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, as shown in the following excerpt from 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:

C:\> nslookup 
Default Server:  wormhole.movie.edu 
Address:  192.249.249.1 

> terminator 
Server:  wormhole.movie.edu 
Address:  192.249.249.1 

Name:    terminator.movie.edu 
Address:  192.249.249.3

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

C:\> nslookup 
Default Server:  wormhole.movie.edu 
Address:  192.249.249.1 

> bigt 
Server:  wormhole.movie.edu 
Address:  192.249.249.1 

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

You can find out all the CNAMEs for a host in a particular zone by transferring the whole zone and picking out the CNAME records in which that host is the canonical name. You can have nslookup filter on CNAME records:

C:\> nslookup 
Default Server:  wormhole.movie.edu 
Address:  192.249.249.1 

> ls -t cname movie.edu 
[wormhole.movie.edu] 
 bigt                           terminator.movie.edu 
 wh                             wormhole.movie.edu 
 dh                             diehard.movie.edu

You can also do this with dnscmd:

C:\> dnscmd /enumrecords movie.edu @ /type A

This method won't show you aliases in other zones that point to the canonical name, though.