15. Miscellaneous
Contents:
"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 RecordsWe 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 CNAME s Attached to Interior NodesIf 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 CNAME s Pointing to CNAME sYou 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 RFC s don't expressly forbid it. But, while you can chain CNAME records, is it a wise thing to do? The RFC s 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]
15.1.3 CNAME s in the Resource Record DataFor 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 RecordsOne 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 CNAME sAt 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: % 15.1.6 Finding Out a Host's AliasesOne 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: % 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: % 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: % About the only way to find out all the CNAME s for a host is to transfer the whole zone and pick out the CNAME records where that host is the canonical name: % 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. |
|