15. Miscellaneous

Contents:
Using CNAME Records
Wildcards
A Limitation of MX Records
DNS and Internet Firewalls
Dialup Connections
Network Names and Numbers
Additional Resource Records
DNS Versus X.500
DNS and WINS

"The time has come," the Walrus said, "To talk of many things: Of shoes - and ships - and sealing-wax - Of cabbages - and kings - And why the sea is boiling hot - And whether pigs have wings."

It's time we tied up loose ends. We've already covered the mainstream of DNS and BIND, but there's a handful of interesting niches we haven't explored. Some of these may actually be useful to you, like instructions on how to set up DNS on a network without Internet connectivity; others may just be interesting. We can't in good conscience send you out into the world without completing your education!

15.1 Using CNAME Records

We talked about CNAME resource records in Chapter 4, Setting Up BIND. We didn't tell you all 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 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.

15.1.1 CNAMEs Attached to Interior Nodes

If you've ever renamed your zone because of a company re-org, 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 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 a single CNAME record to rename a complete zone, you'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, 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 in fx.movie.edu.

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

15.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 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 Micrsoft DNS Server, shipped with Windows NT). It permits CNAMEs that point to CNAMEs, too, though.

15.1.3 CNAMEs in the Resource Record Data

For any other record besides a CNAME record, you must have the canonical name in the resource record data. Applications and name servers won't operate correctly otherwise. As we mentioned back in Chapter 5, DNS and Electronic Mail, 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 name, it won't strip the right MX records out when paring down the MX list, and may deliver mail to itself or less-preferred hosts, causing mail to loop.

15.1.4 Multiple CNAME Records

One pathological configuration that honestly hadn't occurred to us - and many pathological configurations have occurred to us - before we saw an option to allow it is multiple CNAME records attached to the same 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 of 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, for one, doesn't recognize this as a misconfiguration. BIND 8 does, but will let you permit it if you want to with:

options {
                multiple-cnames yes;
};

The default, naturally, is to disallow it.

15.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, this is easy to do. You can either set the query type to cname, or you can set 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

15.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 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:

% 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

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 where that host is the canonical name:

% nslookup
Default Server:  wormhole
Address:  0.0.0.0

> ls -t cname movie.edu
 [wormhole.movie.edu]
       1D IN SOA    terminator.movie.edu. al.robocop.movie.edu. (
              25              ; serial
              3H              ; refresh
              1H              ; retry
              1W              ; expire
              1D )            ; minimum

        1D IN NS    terminator.movie.edu.
        1D IN NS    wormhole.movie.edu.
        1D IN NS    zardoz.movie.edu.
        1D IN A     1.1.1.1
localhost.movie.edu.      1D IN A      127.0.0.1
awakenings.movie.edu.     1W IN A      192.253.253.254
classics.movie.edu.       1D IN NS     gwtw.classics.movie.edu.
gwtw.classics.movie.edu.  1D IN A  1.1.1.1
dh.movie.edu.             1D IN CNAME  diehard.movie.edu.
wormhole.movie.edu.       1D IN A      192.249.249.1
             1D IN A           192.253.253.1
web.movie.edu.            1D IN CNAME     www.movie.edu.
misery.movie.edu.         1D IN A      192.253.253.2
robocop.movie.edu.        1D IN A      192.249.249.2
carrie.movie.edu.         1D IN A      192.253.253.4
diehard.movie.edu.        1D IN A      192.249.249.4
fx.movie.edu.             1D IN NS     bladerunner.fx.movie.edu.
bladerunner.fx.movie.edu.  1D IN A  192.253.254.2
fx.movie.edu.             1D IN NS     outland.fx.movie.edu.
outland.fx.movie.edu.     1D IN A      192.253.254.3
rainman.movie.edu.        1W IN A      192.249.249.254
wh.movie.edu.             1D IN CNAME    wormhole.movie.edu.
wh249.movie.edu.          1D IN A      192.249.249.1
wh253.movie.edu.          1D IN A      192.253.253.1
bigt.movie.edu.           1D IN CNAME    terminator.movie.edu.
www.movie.edu.            1D IN CNAME    movie.edu.
zardoz.movie.edu.         1D IN A      192.249.249.9
             1D IN A           192.253.253.9
terminator.movie.edu.     1D IN A      192.249.249.3
             1H IN MX          10 terminator.movie.edu.
ftp.movie.edu.            1D IN A      192.249.249.1
             1D IN A              198.105.232.1
shining.movie.edu.        1D IN A      192.253.253.3
pma.movie.edu.            30S IN A     1.2.3.4
postmanrings2x.movie.edu.  1D IN A  1.1.1.1
             1D IN MX             10 postmanrings2x.movie.edu.
movie.edu.   1D IN SOA          terminator.movie.edu. al.robocop.movie.edu. (
                   25              ; serial
                   3H              ; refresh
                   1H              ; retry
                   1W              ; expire
                   1D )                    ; minimum

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


14.3 Perl Programming with Net::DNS		15.2 Wildcards