Managing the Transition to Subdomains (DNS and BIND, 4th Edition)

9.7. Managing the Transition to Subdomains

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 start 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 in movie.edu.

We briefly touched on using CNAME records in the parent zone (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 such as 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 plan9 
Trying...
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 sendmail 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 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 Section 5.3, "The MX Algorithm" in Chapter 5, "DNS and Electronic Mail".

How do you create all these aliases? You simply tell h2n to create the aliases for hosts on the fx.movie.edu networks (192.253.254/24 and 192.254.20/24) and indicate (in the /etc/hosts file) the new domain names for the hosts. For example, using the fx.movie.edu host table, we could easily generate the aliases in 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 -f options

(where options contains other command-line options for building data from other movie.edu networks), we could create aliases in movie.edu for all fx.movie.edu hosts.

9.7.1. Removing Parent Aliases

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 namespace 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 DNS, as 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 in the parent zone.

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.movie.edu (which is on the 192.253.254/24 network):

% h2n -d movie.edu -n 192.253.254 -n 192.254.20 \
-e fx.movie.edu -f options