 | Chapter 9 Parenting |  |
| Chapter 9 Parenting | |
We won't lie to you - the fx.movie.edu example we showed you was unrealistic for several reasons. The main one is the magical appearance of the special effects lab's hosts. In the real world, the lab would have started out with a few hosts, probably in the movie.edu zone. After a generous endowment, an NSF grant, or a corporate gift, they might expand the lab a little and buy a few more computers. Sooner or later, the lab would have enough hosts to warrant the creation of a new subdomain. By that point, however, many of the original hosts would be well known by their names under movie.edu.
We briefly touched on using CNAME records under the parent domain (in our plan9.movie.edu example) to help people adjust to a host's change of domain. But what happens when you move a whole network or subnet into a new subdomain?
The strategy we recommend uses CNAME records in much the same way, but on a larger scale. Using a tool like h2n, you can create CNAMEs for hosts en masse. This allows users to continue using the old domain names for any of the hosts that have moved. When they telnet or ftp (or whatever) to those hosts, however, the command will report that they're connected to a host in fx.movie.edu:
%telnet plan9Trying... Connected to plan9.fx.movie.edu. Escape character is '^]'. HP-UX plan9.fx.movie.edu A.09.05 C 9000/735 (ttyu1) login:
Some users, of course, don't notice subtle changes like this, so you should also do some public relations work and notify folks of the change.
On fx.movie.edu hosts running old versions of sendmail, we may also need to configure mail to accept mail addressed to the new domain names. Modern versions of sendmail canonicalize the host names in addresses in message headers using a name server before sending the messages. This will turn a movie.edu alias into a canonical name in fx.movie.edu. If, however, the sendmail on the receiving end is older and hardcodes the local host's domain name, we'd have to change the name to the new domain name by hand. This usually requires a simple change to class w or fileclass w in sendmail.cf; see the section "The MX Algorithm" in Chapter 5, DNS and Electronic Mail.
How do you create all these aliases? You simply need to tell h2n to create the aliases for hosts on the fx.movie.edu networks (192.253.254 and 192.254.20), and indicate (in the /etc/hosts file) what the new domain names for the hosts are. For example, using the fx.movie.edu host table, we could easily generate the aliases under movie.edu for all the hosts in fx.movie.edu.
Partial contents of file /etc/hosts:
192.253.254.1 movie-gw.movie.edu movie-gw # fx primary 192.253.254.2 bladerunner.fx.movie.edu bladerunner br # fx secondary 192.253.254.3 outland.fx.movie.edu outland 192.253.254.4 starwars.fx.movie.edu starwars 192.253.254.5 empire.fx.movie.edu empire 192.253.254.6 jedi.fx.movie.edu jedi 192.254.20.3 alien.fx.movie.edu alien
h2n's -c option takes a zone's domain name as an argument. When h2n finds any hosts in that zone on networks it's building data for, it'll create aliases for them in the current zone (specified with -d). So by running:
%h2n -d movie.edu -n 192.253.254 -n 192.254.20\-c fx.movie.edu -foptions
(where options contains other
command-line options for building data from other movie.edu networks), we could create
aliases under movie.edu for
all fx.movie.edu
hosts.
Although parent-level aliases are useful for minimizing the impact of moving your hosts, they're also a crutch of sorts. Like a crutch, they'll restrict your freedom. They'll clutter up your parent name space, when one of your motivations for implementing a subdomain may have been making the parent zone smaller. And they'll prevent you from using the names of hosts in the subdomain as names for hosts in the parent zone.
After a grace period - which should be well advertised to users - you should remove all the aliases, with the possible exception of aliases for extremely well-known Internet hosts. During the grace period, users can adjust to the new domain names, and modify scripts, .rhosts files, and the like. But don't get suckered into leaving all those aliases in the parent zone; they defeat part of the purpose of the DNS, because they prevent you and your subdomain administrator from naming hosts autonomously.
You might want to leave CNAME records for well-known Internet hosts or central network resources intact, because of the potential impact of a loss of connectivity. On the other hand, rather than moving the well-known host or central resource into a subdomain at all, it might be better to leave it at the parent zone level.
h2n gives you an easy way to delete the aliases you created so simply with the -c option, even if the records for the subdomain's hosts are mixed in the host table or on the same network as hosts in other zones. The -e option takes a zone's domain name as an argument, and tells h2n to exclude (hence -e) all records containing that domain name on networks it would otherwise create data for. This command line, for example, would delete all the CNAME records for fx.movie.edu hosts created earlier, while still creating an A record for movie-gw (which is on the 192.253.254 network):
%h2n -d movie.edu -n 192.253.254 -n 192.254.20\-e fx.movie.edu -foptions
|  | |
| 9.6 Good Parenting |  | 9.8 The Life of a Parent |