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 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 the DNS console, you can create CNAMEs for hosts. 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 ...