Chapter 9. Parenting
“The way Dinah washed her children’s faces was this: first she held the poor thing down by its ear with one paw, and then with the other paw she rubbed its face all over, the wrong way, beginning at the nose: and just now, as I said, she was hard at work on the white kitten, which was lying quite still and trying to purr—no doubt feeling that it was all meant for its good.”
Once your domain reaches a certain size, or you decide you need to distribute the management of parts of your domain to various entities within your organization, you’ll want to divide the domain into subdomains. These subdomains will be the children of your current domain in the namespace; your domain will be the parent. If you delegate responsibility for your subdomains to another organization, each becomes its own zone, separate from its parent zone. We like to call the management of your subdomains—your children—parenting.
Good parenting starts with carving up your domain sensibly, choosing appropriate names for your subdomains, and delegating the subdomains to create new zones. A responsible parent also works hard at maintaining the relationship between his zone and its children; he ensures that delegation from parent to child is current and correct.
Good parenting is vital to the success of your network, especially as name service becomes critical to navigating between sites. Incorrect delegation to a child zone’s nameservers can render a site effectively unreachable, while the loss of connectivity to the parent zone’s nameservers can leave a site unable to reach any hosts outside the local zone.
In this chapter, we present our views on when to create subdomains, and we go over how to create and delegate them in some detail. We also discuss management of the parent/child relationship and, finally, how to manage the process of carving up a large domain into smaller subdomains with minimal disruption and inconvenience.
When to Become a Parent
Far be it from us to tell you when you should become a parent, but we will be so bold as to offer you some guidelines. You may find some compelling reason to implement subdomains that isn’t on our list, but here are some common reasons:
A need to delegate or distribute management of your domain to a number of organizations
The large size of your domain: dividing it would make it easier to manage and reduce the load on your authoritative nameservers
A need to distinguish hosts’ organizational affiliations by including them in particular subdomains
Once you’ve decided to have children, the next question to ask yourself is, naturally, how many children to have.
How Many Children?
Of course, you won’t simply say, “I want to create four subdomains.” Deciding how many subdomains to implement is really choosing the organizational affiliations of those subdomains. For example, if your company has four branch offices, you might decide to create four subdomains, each of which corresponds to a branch office.
Should you create subdomains for each site, for each division, or even for each department? You have a lot of latitude in your choice because of DNS’s scalability. You can create a few large subdomains or many small subdomains. There are trade-offs whichever you choose, though.
Delegating to a few large subdomains isn’t much work for the parent, because there’s not much delegation to keep track of. However, you wind up with larger subdomains, which require more memory to load and faster nameservers, and administration isn’t as distributed. If you implement site-level subdomains, for example, you may force autonomous or unrelated groups at a site to share a single zone and a single point of administration.
Delegating to many smaller subdomains can be a headache for the parent’s administrator. Keeping delegation data current involves keeping track of which hosts run nameservers and which zones they’re authoritative for. The data changes each time a subdomain adds a new nameserver or the address of a nameserver for the subdomain changes. If the subdomains are all administered by different people, that means more administrators to train, more relationships for the parent’s administrator to maintain, and more overhead for the organization overall. On the other hand, the subdomains are smaller and easier to manage, and the administration is more widely distributed, allowing closer management of zone data.
Given the advantages and disadvantages of either alternative, it may seem difficult to make a choice. Actually, there’s probably a natural division in your organization. Some companies manage computers and networks at the site level; others have decentralized, relatively autonomous workgroups that manage everything themselves. Here are a few basic rules to help you find the right way to carve up your namespace:
Don’t shoehorn your organization into a weird or uncomfortable structure. Trying to fit 50 independent, unrelated U.S. divisions into four regional subdomains may save you work (as the administrator of the parent zone), but it won’t help your reputation. Decentralized, autonomous operations demand different zones: that’s the raison d'être of the Domain Name System.
The structure of your domain should mirror the structure of your organization, especially your organization’s support structure. If departments run networks, assign IP addresses, and manage hosts, they should also manage the subdomains.
If you’re not sure or can’t agree about how the namespace should be organized, try to come up with guidelines for when a group within your organization can carve off its own subdomain (for example, how many hosts are needed to create a new subdomain and what level of support the group must provide) and grow the namespace organically, but only as needed.
What to Name Your Children
Once you’ve decided how many subdomains you’d like to create and what they correspond to, you must choose names for them. Rather than unilaterally deciding on your subdomains’ names, it’s considered polite to involve your future subdomain administrators and their constituencies in the decision. In fact, you can leave the decision entirely to them if you like.
This can lead to problems, though. It’s preferable to use a relatively consistent naming scheme across your subdomains. This practice makes it easier for users in one subdomain, or outside your domain entirely, to guess or remember your subdomain names and to figure out in which domain a particular host or user lives.
Leaving the decision to the locals can result in naming chaos. Some will want to use geographical names; others will insist on organizational names. Some will want to abbreviate; others will want to use full names.
Therefore, it’s often best to establish a naming convention before choosing subdomain names. Here are some suggestions from our experience:
In a dynamic company, the names of organizations can change frequently. Naming subdomains organizationally in a climate like this can be disastrous. One month the Relatively Advanced Technology group seems stable enough, the next month they’ve been merged into the Questionable Computer Systems organization, and the following quarter they’re all sold to a German conglomerate. Meanwhile, you’re stuck with well-known hosts in a subdomain whose name no longer has any meaning.
Geographical names are more stable than organizational names but sometimes aren’t as well known. You may know that your famous Software Evangelism Business Unit is in Poughkeepsie or Waukegan, but people outside your company may have no idea where it is (and might have trouble spelling either name).
Don’t sacrifice readability for convenience. Two-letter subdomain names may be easy to type, but impossible to recognize. Why abbreviate “Italy” to “it” and have it confused with your Information Technology organization when for a paltry three more letters you can use the full name and eliminate any ambiguity?
Too many companies use cryptic, inconvenient domain names. The general rule seems to be the larger the company, the more indecipherable the domain names. Buck the trend: make the names of your subdomains obvious!
Don’t use existing or reserved top-level domain names as subdomain names. It might seem sensible to use two-letter country abbreviations for your international subdomains or to use organizational top-level domain names like net for your networking organization, but doing so can cause nasty problems. For example, naming your Communications Department’s subdomain com might impede your ability to communicate with hosts under the top-level com domain. Imagine the administrators of your com subdomain naming their new Sun workstation sun and their new HP 9000 hp (they aren’t the most imaginative folks): users anywhere within your domain sending mail to friends at sun.com or hp.com could have their letters end up in your com subdomain because the name of your parent zone may be in some of your hosts’ search lists.[*]
How to Become a Parent: Creating Subdomains
Once you’ve decided on names, creating the child domains is easy. But first, you must decide how much autonomy you’re going to give your subdomains. Odd that you have to decide that before you actually create them . . . .
Thus far, we’ve assumed that if you create a subdomain, you’ll want to delegate it to another organization, thereby making it a separate zone from the parent. Is this always true, though? Not necessarily.
Think carefully about how the computers and networks within a subdomain are managed when choosing whether to delegate it. It doesn’t make sense to delegate a subdomain to an entity that doesn’t manage its own hosts or networks. For example, in a large corporation, the Personnel Department probably doesn’t run its own computers: the MIS (Management Information Systems) or IT (Information Technology—same animal as MIS) Department manages them. So while you may want to create a subdomain for personnel, delegating management for that subdomain to it is probably wasted effort.
Creating a Subdomain in the Parent’s Zone
You can create a subdomain without delegating it, however. How? By creating resource records that refer to the subdomain within the parent’s zone. For example, movie.edu has a host that stores its complete database of employee and student records, called brazil. To put brazil in the personnel.movie.edu domain, we can add records to db.movie.edu.
Partial contents of file db.movie.edu:
brazil.personnel IN A 192.253.253.10
IN MX 10 brazil.personnel.movie.edu.
IN MX 100 postmanrings2x.movie.edu.
employeedb.personnel IN CNAME brazil.personnel.movie.edu.
db.personnel IN CNAME brazil.personnel.movie.edu.Now users can log into db.personnel.movie.edu to get to the employee database. We can make this setup especially convenient for Personnel Department employees by adding personnel.movie.edu to their PCs’ or workstations’ search lists; they’d need to type only telnet db to get to the right host.
We can make this more convenient for ourselves by using the $ORIGIN control statement to change the origin to personnel.movie.edu so that we can use shorter names.
Partial contents of file db.movie.edu:
$ORIGIN personnel.movie.edu.
brazil IN A 192.253.253.10
IN MX 10 brazil.personnel.movie.edu.
IN MX 100 postmanrings2x.movie.edu.
employeedb IN CNAME brazil.personnel.movie.edu.
db IN CNAME brazil.personnel.movie.edu.If we had a few more records, we could create a separate file for them and use $INCLUDE to include it in db.movie.edu and change the origin at the same time.
Notice there’s no SOA record for personnel.movie.edu? There’s no need for one because the movie.edu SOA record indicates the start of authority for the entire movie.edu zone. Since there’s no delegation to personnel.movie.edu, it’s part of the movie.edu zone.
Creating and Delegating a Subdomain
If you decide to delegate your subdomains —to send your children out into the world, as it were—you’ll need to do things a little differently. We’re in the process of doing it now, so you can follow along with us.
We need to create a new subdomain of movie.edu for our special-effects lab. We’ve chosen the name fx.movie.edu—short, recognizable, unambiguous. Because we’re delegating fx.movie.edu to administrators in the lab, it’ll be a separate zone. The hosts bladerunner and outland, both within the special-effects lab, will serve as the zone’s nameservers (bladerunner will serve as the primary). We’ve chosen to run two nameservers for the zone for redundancy; a single fx.movie.edu nameserver would be a single point of failure that could effectively isolate the entire special-effects lab. Since there aren’t many hosts in the lab, though, two nameservers should be enough.
The special-effects lab is on movie.edu’s new 192.253.254/24 network.
Partial contents of /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 slave 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
First, we create a zone datafile that includes records for all the hosts that will live in fx.movie.edu.
Contents of file db.fx.movie.edu’:
$TTL 1d
@ IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. (
1 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; negative caching TTL
IN NS bladerunner
IN NS outland
; MX records for fx.movie.edu
IN MX 10 starwars
IN MX 100 wormhole.movie.edu.
; starwars handles bladerunner's mail
; wormhole is the movie.edu mail hub
bladerunner IN A 192.253.254.2
IN MX 10 starwars
IN MX 100 wormhole.movie.edu.
br IN CNAME bladerunner
outland IN A 192.253.254.3
IN MX 10 starwars
IN MX 100 wormhole.movie.edu.
starwars IN A 192.253.254.4
IN MX 10 starwars
IN MX 100 wormhole.movie.edu.
empire IN A 192.253.254.5
IN MX 10 starwars
IN MX 100 wormhole.movie.edu.
jedi IN A 192.253.254.6
IN MX 10 starwars
IN MX 100 wormhole.movie.edu.Then, we create the db.192.253.254 file:
$TTL 1d
@ IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. (
1 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; negative caching TTL
IN NS bladerunner.fx.movie.edu.
IN NS outland.fx.movie.edu.
1 IN PTR movie-gw.movie.edu.
2 IN PTR bladerunner.fx.movie.edu.
3 IN PTR outland.fx.movie.edu.
4 IN PTR starwars.fx.movie.edu.
5 IN PTR empire.fx.movie.edu.
6 IN PTR jedi.fx.movie.edu.Notice that the PTR record for 1.254.253.192.in-addr.arpa points to movie-gw.movie.edu. That’s intentional. The router connects to the other movie.edu networks, so it really doesn’t belong in fx.movie.edu, and there’s no requirement that all the PTR records in 254.253.192.in-addr.arpa map into a single zone—though they should correspond to the canonical names for those hosts.
Next, we create an appropriate named.conf file for the primary nameserver:
options {
directory "/var/named";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0";
};
zone "fx.movie.edu" {
type master;
file "db.fx.movie.edu";
};
zone "254.253.192.in-addr.arpa" {
type master;
file "db.192.253.254";
};
zone "." {
type hint;
file "db.cache";
};Of course, if we use h2n, we can just run:
%h2n -v 8 -d fx.movie.edu -n 192.253.254 -s bladerunner -s outland-u hostmaster.fx.movie.edu -m 10:starwars -m 100:wormhole.movie.edu
and save ourselves some typing. h2n creates essentially the same db.fx.movie.edu, db.192.253.254, and named.conf files.
Now we need to configure bladerunner’s resolver. Actually, this may not require creating resolv.conf. If we set bladerunner’s hostname to its new domain name, bladerunner.fx.movie.edu , the resolver can derive the local domain name from the fully qualified domain name. By default, of course, the resolver will configure the local nameserver.
Next, we start up the named process on bladerunner and check for syslog errors. If named starts okay, and there are no syslog errors that need tending to, we’ll use nslookup to look up a few hosts in fx.movie.edu and in 254.253.192.in-addr.arpa:
Default Server: bladerunner.fx.movie.edu Address: 192.253.254.2 >jediServer: bladerunner.fx.movie.edu Address: 192.253.254.2 Name: jedi.fx.movie.edu Address: 192.253.254.6 >set type=mx>empireServer: bladerunner.fx.movie.edu Address: 192.253.254.2 empire.fx.movie.edu preference = 10, mail exchanger = starwars.fx.movie.edu empire.fx.movie.edu preference = 100, mail exchanger = wormhole.movie.edu fx.movie.edu nameserver = outland.fx.movie.edu fx.movie.edu nameserver = bladerunner.fx.movie.edu starwars.fx.movie.edu internet address = 192.253.254.4 wormhole.movie.edu internet address = 192.249.249.1 wormhole.movie.edu internet address = 192.253.253.1 bladerunner.fx.movie.edu internet address = 192.253.254.2 outland.fx.movie.edu internet address = 192.253.254.3 >ls -d fx.movie.edu[bladerunner.fx.movie.edu] $ORIGIN fx.movie.edu. @ 1D IN SOA bladerunner hostmaster ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum 1D IN NS bladerunner 1D IN NS outland 1D IN MX 10 starwars 1D IN MX 100 wormhole.movie.edu. bladerunner 1D IN A 192.253.254.2 1D IN MX 10 starwars 1D IN MX 100 wormhole.movie.edu. br 1D IN CNAME bladerunner empire 1D IN A 192.253.254.5 1D IN MX 10 starwars 1D IN MX 100 wormhole.movie.edu. jedi 1D IN A 192.253.254.6 1D IN MX 10 starwars 1D IN MX 100 wormhole.movie.edu. outland 1D IN A 192.253.254.3 1D IN MX 10 starwars 1D IN MX 100 wormhole.movie.edu. starwars 1D IN A 192.253.254.4 1D IN MX 10 starwars 1D IN MX 100 wormhole.movie.edu. @ 1D IN SOA bladerunner hostmaster ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum >set type=ptr>192.253.254.3Server: bladerunner.fx.movie.edu Address: 192.253.254.2 3.254.253.192.in-addr.arpa name = outland.fx.movie.edu >ls -d 254.253.192.in-addr.arpa. [bladerunner.fx.movie.edu] $ORIGIN 254.253.192.in-addr.arpa. @ 1D IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum 1D IN NS bladerunner.fx.movie.edu. 1D IN NS outland.fx.movie.edu. 1 1D IN PTR movie-gw.movie.edu. 2 1D IN PTR bladerunner.fx.movie.edu. 3 1D IN PTR outland.fx.movie.edu. 4 1D IN PTR starwars.fx.movie.edu. 5 1D IN PTR empire.fx.movie.edu. 6 1D IN PTR jedi.fx.movie.edu. @ 1D IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum >exit
The output looks reasonable, so it’s now safe to set up a slave nameserver for fx.movie.edu and then delegate fx.movie.edu from movie.edu.
An fx.movie.edu Slave
Setting up the slave nameserver for fx.movie.edu is simple: copy named.conf, db.127.0.0, and db.cache over from bladerunner, and edit named.conf and db.127.0.0 according to the instructions in Chapter 4.
Contents of file named.conf:
options {
directory "/var/named";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0";
};
zone "fx.movie.edu" {
type slave;
masters { 192.253.254.2; };
file "bak.fx.movie.edu";
};
zone "254.253.192.in-addr.arpa" {
type slave;
masters { 192.253.254.2; };
file "bak.192.253.254";
};
zone "." {
type hint;
file "db.cache";
};Like bladerunner, outland really doesn’t need a resolv.conf file, as long as its hostname is set to outland.fx.movie.edu .
Again, we start named and check for errors in the syslog output. If the syslog output is clean, we’ll look up a few records in fx.movie.edu.
On the movie.edu Primary Nameserver
All that’s left now is to delegate the fx.movie.edu subdomain to the new fx.movie.edu nameservers on bladerunner and outland. We add the appropriate NS records to db.movie.edu.
Partial contents of file db.movie.edu:
fx 86400 IN NS bladerunner.fx.movie.edu.
86400 IN NS outland.fx.movie.edu.According to RFC 1034, the domain names in the resource record-specific portion of NS records (the right side, containing bladerunner.fx.movie.edu and outland.fx.movie.edu ) must be the canonical domain names for the nameservers. A remote nameserver following delegation expects to find one or more address records attached to that domain name, not an alias (CNAME) record. Actually, the RFC extends this restriction to any type of resource record that includes a domain name as its value; all must specify the canonical domain name.
These two records alone aren’t enough, though. Do you see the problem? How can a nameserver outside of fx.movie.edu look up information within fx.movie.edu? Well, a movie.edu nameserver would refer it to the nameservers authoritative for fx.movie.edu, right? That’s true, but the NS records in db.movie.edu give only the names of the fx.movie.edu nameservers. The foreign nameserver needs the IP addresses of the fx.movie.edu nameservers in order to send queries to them. Who can give it those addresses? Only the fx.movie.edu nameservers. A real chicken-and-egg problem!
The solution is to include the addresses of the fx.movie.edu nameservers in the movie.edu zone datafile. While these aren’t strictly part of the movie.edu zone, delegation to fx.movie.edu won’t work without them. Of course, if the nameservers for fx.movie.edu weren’t within fx.movie.edu, these addresses—called glue records —wouldn’t be necessary. A foreign nameserver would be able to find the address it needed by querying other nameservers.
So, with the glue records, the added records look like the following.
Partial contents of file db.movie.edu:
fx 86400 IN NS bladerunner.fx.movie.edu.
86400 IN NS outland.fx.movie.edu.
bladerunner.fx.movie.edu. 86400 IN A 192.253.254.2
outland.fx.movie.edu. 86400 IN A 192.253.254.3Don’t include unnecessary glue records in the file. BIND 8 and 9 nameservers automatically ignore any glue you include that isn’t strictly necessary and log the fact that they’ve ignored the record(s) to syslog. For example, if we had an NS record for movie.edu that pointed to an off-site nameserver, ns-1.isp.net, and we made the mistake of including its address in db.movie.edu on the movie.edu primary nameserver, we’d see a message like this in named’s syslog output:
Aug 9 14:23:41 toystory named[19626]: dns_master_load: db.movie.edu:55: ignoring out-of-zone data
Also, remember to keep the glue up to date. If bladerunner gets a new network interface, and hence another IP address, you should add another A record to the glue data.
We might also want to include aliases for any hosts moving into fx.movie.edu from movie.edu. For example, if we move plan9.movie.edu, a server with an important library of public-domain special-effects algorithms, into fx.movie.edu, we should create an alias in movie.edu pointing the old domain name to the new one. In the zone datafile, the record looks like this:
plan9 IN CNAME plan9.fx.movie.edu.
This allows people outside movie.edu to reach plan9 even though they’re using its old domain name, plan9.movie.edu.
Don’t get confused about the zone in which this alias belongs. The plan9 alias record is actually in the movie.edu zone, so it belongs in the file db.movie.edu. An alias pointing p9.fx.movie.edu to plan9.fx.movie.edu, on the other hand, is in the fx.movie.edu zone and belongs in db.fx.movie.edu’. If you put a record in the zone datafile that’s outside the zone the file describes, the nameserver will ignore it, as shown earlier in the unnecessary glue example.
Delegating an in-addr.arpa Zone
We almost forgot to delegate the 254.253.192.in-addr.arpa zone! This is a little trickier than delegating fx.movie.edu because we don’t manage the parent zone.
First, we need to figure out what 254.253.192.in-addr.arpa’s parent zone is and who runs it. Figuring this out may take some sleuthing; we covered how to do this in Chapter 3.
As it turns out, the 192.in-addr.arpa zone is 254.253.192.in-addr.arpa’s parent. And, if you think about it, that makes some sense. There’s no reason for the administrators of in-addr.arpa to delegate 253.192.in-addr.arpa to a separate authority, because unless 192.253/16 is all one big CIDR block, networks like 192.253.253/24 and 192.253.254/24 don’t have anything in common with each other. They may be managed by totally unrelated organizations.
To find out who runs 192.in-addr.arpa, we can use nslookup or whois, as we demonstrated in Chapter 3. Here’s how to use nslookup to find the administrator:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >set type=soa>192.in-addr.arpa. Server: toystory.movie.edu Address: 0.0.0.0#53 Non-authoritative answer: 192.in-addr.arpa origin = chia.arin.net mail addr = bind.arin.net serial = 2005112714 refresh = 1800 retry = 900 expire = 691200 minimum = 10800 Authoritative answers can be found from: 192.in-addr.arpa nameserver = chia.arin.net. 192.in-addr.arpa nameserver = dill.arin.net. 192.in-addr.arpa nameserver = basil.arin.net. 192.in-addr.arpa nameserver = henna.arin.net. 192.in-addr.arpa nameserver = indigo.arin.net. 192.in-addr.arpa nameserver = epazote.arin.net. 192.in-addr.arpa nameserver = figwort.arin.net. chia.arin.net has AAAA address 2001:440:2000:1::21 basil.arin.net internet address = 192.55.83.32 henna.arin.net internet address = 192.26.92.32 indigo.arin.net internet address = 192.31.80.32
So ARIN is responsible for 192.in-addr.arpa (remember them from Chapter 3?). All that’s left is for us to submit the form at http://www.arin.net/library/templates/net-end-user.txt to request registration of our reverse-mapping zone.
Adding a movie.edu Slave
If the special-effects lab gets big enough, it may make sense to put a movie.edu slave somewhere on the 192.253.254/24 network. That way, a larger proportion of DNS queries from fx.movie.edu hosts can be answered locally. It seems logical to make one of the existing fx.movie.edu nameservers into a movie.edu slave, too—that way, we can better use an existing nameserver instead of setting up a brand-new nameserver.
We’ve decided to make bladerunner a slave for movie.edu. This won’t interfere with bladerunner’s primary mission as the primary nameserver for fx.movie.edu. A single nameserver, given enough memory, can be authoritative for literally thousands of zones. One nameserver can load some zones as a primary and others as a slave.[*]
The configuration change is simple: we add one statement to bladerunner’s named.conf file to tell named to load the movie.edu zone from the IP address of the movie.edu primary nameserver, toystory.movie.edu .
Contents of file named.conf:
options {
directory "/var/named";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0";
};
zone "fx.movie.edu" {
type master;
file "db.fx.movie.edu";
};
zone "254.253.192.in-addr.arpa" {
type master;
file "db.192.253.254";
};
zone "movie.edu" {
type slave;
masters { 192.249.249.3; };
file "bak.movie.edu";
};
zone "." {
type hint;
file "db.cache";
};Subdomains of in-addr.arpa Domains
Forward-mapping domains aren’t the only domains you can divide into subdomains and delegate. If your in-addr.arpa namespace is large enough, you may need to divide it, too. Typically, you divide the domain that corresponds to your network number into subdomains that correspond to your subnets. How that works depends on the type of network you have and on your network’s subnet mask.
Subnetting on an Octet Boundary
Since Movie U. has just three /24 (Class C-sized) networks, one per segment, there’s no particular need to subnet those networks. However, our sister university, Altered State, has a Class B-sized network, 172.20/16. Its network is subnetted between the third and fourth octet of the IP address; that is, its subnet mask is 255.255.255.0. It’s already created a number of subdomains of its domain: altered.edu, including fx.altered.edu (okay, we copied them); makeup.altered.edu; and foley.altered.edu. Since each department also runs its own subnet (its Special Effects department runs subnet 172.20.2/24, Makeup runs 172.20.15/24, and Foley runs 172.20.25/24), it’d like to divvy up its in-addr.arpa namespace appropriately, too.
Delegating in-addr.arpa subdomains is no different from delegating subdomains of forward-mapping domains. Within its db.172.20 zone datafile, it needs to add NS records like these:
2 86400 IN NS gump.fx.altered.edu. 2 86400 IN NS toystory.fx.altered.edu. 15 86400 IN NS prettywoman.makeup.altered.edu. 15 86400 IN NS priscilla.makeup.altered.edu. 25 86400 IN NS blowup.foley.altered.edu. 25 86400 IN NS muppetmovie.foley.altered.edu.
These records delegate the subdomain that corresponds to each subnet to the correct nameserver in each subdomain.
A few important notes: the Altered States administrators can use only the third octet of the subnet in the owner name field because the default origin in this file is 20.172.in-addr.arpa. They need to use the fully qualified domain names of the nameservers in the right side of the NS records, though, to avoid having the origin appended. And they don’t need glue address records because the names of the nameservers they delegated the zone to don’t end in the domain name of the zone.
Subnetting on a Nonoctet Boundary
What do you do about networks that aren’t subnetted neatly on octet boundaries, like subnetted /24 (Class C-sized) networks? In these cases, you can’t delegate along lines that match the subnets. This forces you into one of two situations: you have multiple subnets per in-addr.arpa zone, or you have multiple in-addr.arpa zones per subnet. Neither is particularly pleasing.
/8 (Class A-sized) and /16 (Class B-sized) networks
Let’s take the case of the /8 (Class A-sized) network 15/8, subnetted with the subnet mask 255.255.248.0 (a 13-bit subnet field and an 11-bit host field, or 8,192 subnets of 2,048 hosts). In this case, the subnet 15.1.200.0, for example, extends from 15.1.200.0 to 15.1.207.255. Therefore, the delegation for that single subdomain in db.15, the zone datafile for 15.in-addr.arpa, might look like this:
200.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 200.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 201.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 201.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 202.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 202.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 203.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 203.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 204.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 204.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 205.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 205.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 206.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 206.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com. 207.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. 207.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com.
That’s a lot of delegation for one subnet!
Luckily, BIND 8.2 and later, as well as BIND 9.1.0 and later, nameservers support a control statement called $GENERATE, which lets you create a group of resource records that differ only by a numerical iterator. For example, you can create the 16 NS records just listed using these two $GENERATE control statements:[*]
$GENERATE 200-207 $.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. $GENERATE 200-207 $.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com.
The syntax is fairly simple: when the nameserver reads the control statement, it iterates over the range specified as the first argument, replacing any dollar signs ($) in the template that follows the first argument with the current iterator.
/24 (Class C-sized) networks
In the case of a subnetted /24 (Class C-sized) network, say 192.253.254/24, subnetted with the mask 255.255.255.192, you have a single in-addr.arpa zone, 254.253.192.in-addr.arpa, that corresponds to subnets 192.253.254.0/26, 192.253.254.64/26, 192.253.254.128/26, and 192.253.254.192/26. This can be a problem if you want to let different organizations manage the reverse-mapping information that corresponds to each subnet. You can solve this in one of three ways, none of which is pretty.
Solution 1
The first solution is to administer the 254.253.192.in-addr.arpa zone as a single entity and not even try to delegate. This requires either cooperation between the administrators of the four subnets involved or the use of a tool such as Webmin (http://www.webmin.com/) to allow each of the four administrators to take care of his own data.
Solution 2
The second is to delegate at the fourth octet. That’s even nastier than the /8 delegation we just showed you. You’ll need at least a couple of NS records per IP address in the file db.192.253.254, like this:
1.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. 1.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. 2.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. 2.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. ... 65.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. 65.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. 66.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. 66.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. ... 129.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. 129.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com. 130.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. 130.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com.
and so on, all the way down to 254.254.253.192.in-addr.arpa.
You can pare that down substantially using $GENERATE:
$GENERATE 0-63 $.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. $GENERATE 0-63 $.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. $GENERATE 64-127 $.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. $GENERATE 64-127 $.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. $GENERATE 128-191 $.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. $GENERATE 128-191 $.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com.
Of course, in ns1.foo.com’s named.conf, you’d also expect to see:
zone "1.254.253.192.in-addr.arpa" {
type master;
file "db.192.253.254.1";
};
zone "2.254.253.192.in-addr.arpa" {
type master;
file "db.192.253.254.2";
};and in db.192.253.254.1, just the one PTR record:
$TTL 1d
@ IN SOA ns1.foo.com. root.ns1.foo.com. (
1 ; Serial
3h ; Refresh
1h ; Retry
1w ; Expire
1h ; Negative caching TTL
IN NS ns1.foo.com.
IN NS ns2.foo.com.
IN PTR thereitis.foo.com.Note that the PTR record is attached to the zone’s domain name because the zone’s domain name corresponds to just one IP address. Now, when a 254.253.192.in-addr.arpa nameserver receives a query for the PTR record for 1.254.253.192.in-addr.arpa, it refers the querier to ns1.foo.com and ns2.foo.com, which respond with the one PTR record in the zone.
Solution 3
Finally, there’s a clever technique that obviates the need to maintain a separate zone datafile for each IP address.[*] The organization responsible for the overall /24 network creates CNAME records for each domain name in the zone, pointing to domain names in new subdomains, which are then delegated to the proper nameservers. These new subdomains can be called just about anything, but names such as 0-63, 64-127, 128-191, and 192-255 clearly indicate the range of addresses each subdomain will reverse-map. Each subdomain then contains only the PTR records in the range for which the subdomain is named.
Partial contents of file db.192.253.254:
1.254.253.192.in-addr.arpa. IN CNAME 1.0-63.254.253.192.in-addr.arpa. 2.254.253.192.in-addr.arpa. IN CNAME 2.0-63.254.253.192.in-addr.arpa. ... 0-63.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. 0-63.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. 65.254.253.192.in-addr.arpa. IN CNAME 65.64-127.254.253.192.in-addr.arpa. 66.254.253.192.in-addr.arpa. IN CNAME 66.64-127.254.253.192.in-addr.arpa. ... 64-127.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. 64-127.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. 129.254.253.192.in-addr.arpa. IN CNAME 129.128-191.254.253.192.in-addr.arpa. 130.254.253.192.in-addr.arpa. IN CNAME 130.128-191.254.253.192.in-addr.arpa. ... 128-191.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. 128-191.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com.
Again, you can abbreviate this with $GENERATE:
$GENERATE 1-63 $ IN CNAME $.0-63.254.253.192.in-addr.arpa. 0-63.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. 0-63.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. $GENERATE 65-127 $ IN CNAME $.64-127.254.253.192.in-addr.arpa. 64-127.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. 64-127.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com.
The zone datafile for 0-63.254.253.192.in-addr.arpa, db.192.253.254.0-63, can contain just PTR records for IP addresses 192.253.254.1 through 192.253.254.63.
Partial contents of file db.192.253.254.0-63:
$TTL 1d
@ IN SOA ns1.foo.com. root.ns1.foo.com. (
1 ; Serial
3h ; Refresh
1h ; Retry
1w ; Expire
1h ) ; Negative caching TTL
IN NS ns1.foo.com.
IN NS ns2.foo.com.
1 IN PTR thereitis.foo.com.
2 IN PTR setter.foo.com.
3 IN PTR mouse.foo.com.
...The way this setup works is a little tricky, so let’s go over it. A resolver requests the PTR record for 1.254.253.192.in-addr.arpa, causing its local nameserver to go look up that record. The local nameserver ends up asking a 254.253.192.in-addr.arpa nameserver, which responds with the CNAME record indicating that 1.254.253.192.in-addr.arpa is actually an alias for 1.0-63.254.253.192.in-addr.arpa and that the PTR record is attached to that name. The response also includes NS records telling the local nameserver that the authoritative nameservers for 0-63.254.253.192.in-addr.arpa are ns1.foo.com and ns2.foo.com. The local nameserver then queries either ns1.foo.com or ns2.foo.com for the PTR record for 1.0-63.254.253.192.in-addr.arpa, and receives the PTR record.
Good Parenting
Now that the delegation to the fx.movie.edu nameservers is in place, we—responsible parents that we are—should check that delegation using host. What? We haven’t given you host yet? A version of host for many Unix variants is available from http://www.weird.com/~woods/projects/host.html.
To build host, first extract it:
%zcat host.tar.Z | tar -xvf -Then build it on your system:
%makehost makes it easy to check delegation. With host, you can look up the NS records for your zone on your parent zone’s nameservers. If those look good, you can use host to query each nameserver listed for the zone’s SOA record. The query is nonrecursive, so the nameserver queried doesn’t query other nameservers to find the SOA record. If the nameserver replies, host checks the reply to see whether the aa—authoritative answer—bit in the reply message is set. If it is, the nameserver checks to make sure that the message contains an answer. If both these criteria are met, the nameserver is flagged as authoritative for the zone. Otherwise, the nameserver is not authoritative, and host reports an error.
Why all the fuss over bad delegation? Incorrect delegation slows name resolution and causes the propagation of old and erroneous nameserver information. Remote nameservers will waste time following your bad NS records, only to receive responses from your nameservers indicating that they aren’t, in fact, authoritative for the zone. The remote nameservers will be forced to query a nameserver listed in another NS record, which means resolving names will take longer. Worse, those remote nameservers will cache those bogus NS records and return them in responses to other nameservers, compounding the problem.
Using host
If our little lecture has convinced you of the importance of maintaining correct delegation, you’ll be eager to learn how to use host to ensure that you don’t join the ranks of the miscreants.
The first step is to use host to look up your zone’s NS records on a nameserver for your parent zone and make sure they’re correct. Here’s how we’d check the fx.movie.edu NS records on one of the movie.edu nameservers:
%host -t ns fx.movie.edu. toystory.movie.edu.If everything’s okay with the NS records, we’ll simply see the NS records in the output:
fx.movie.edu name server bladerunner.fx.movie.edu fx.movie.edu name server outland.fx.movie.edu
(The format of the output may vary with the version of host you use, but the gist is the same.) This tells us that all the NS records delegating fx.movie.edu from toystory.movie.edu are correct.
Next, we’ll use host’s “SOA check” mode to query each nameserver in the NS records for the fx.movie.edu zone’s SOA record. This also checks whether the response was authoritative.
%host -C fx.movie.edu.Normally, this produces a list of the nameservers for fx.movie.edu, along with the contents of the fx.movie.edu zone’s SOA record on each nameserver:
Nameserver bladerunner.fx.movie.edu:
fx.movie.edu SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu.
1 10800 3600 608400 3600
Nameserver outland.fx.movie.edu:
fx.movie.edu SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu.
1 10800 3600 608400 3600If one of the fx.movie.edu nameservers—say outland—is misconfigured, we might see this:
Nameserver bladerunner.fx.movie.edu:
fx.movie.edu SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu.
1 10800 3600 608400 3600
nxdomain.com has no SOA recordThis (subtly) indicates that the nameserver on outland is running, but isn’t authoritative for fx.movie.edu.
If one of the fx.movie.edu nameservers weren’t running at all, we’d see:
Nameserver bladerunner.fx.movie.edu:
fx.movie.edu SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu.
1 10800 3600 608400 3600
;; connection timed out; no servers could be reachedIn this case, the connection timed out message indicates that host sent outland a query and didn’t get a response back in an acceptable amount of time.
While we could have checked the fx.movie.edu delegation using nslookup or dig , host’s powerful command-line options make the task especially easy.
Managing Delegation
If the special-effects lab gets bigger, we may find that we need additional nameservers. We dealt with setting up new nameservers in Chapter 8 and even went over what information to send to the parent zone’s administrator. But we never explained what the parent needs to do.
It turns out that the parent’s job is relatively easy, especially if the administrators of the subdomain send complete information. Imagine that the special-effects lab expands to a new network, 192.254.20/24. It has a passel of new, high-powered graphics workstations. One of them, alien.fx.movie.edu , will act as the new network’s nameserver.
The administrators of fx.movie.edu (we delegated it to the folks in the lab) send their parent zone’s administrators (that’s us) a short note:
Hi! We've just set up alien.fx.movie.edu (192.254.20.3) as a name server for fx.movie.edu. Would you please update your delegation information? I've attached the NS records you'll need to add. Thanks, Arty Segue [email protected] ----- cut here ----- fx.movie.edu. 86400 IN NS bladerunner.fx.movie.edu. fx.movie.edu. 86400 IN NS outland.fx.movie.edu. fx.movie.edu. 86400 IN NS alien.fx.movie.edu. bladerunner.fx.movie.edu. 86400 IN A 192.253.254.2 outland.fx.movie.edu. 86400 IN A 192.253.254.3 alien.fx.movie.edu. 86400 IN A 192.254.20.3
Our job as the movie.edu administrator is straightforward: add the NS and A records to db.movie.edu.
What if we’re using h2n to create our nameserver data? We can stick the delegation information into the spcl.movie file, which h2n $INCLUDEs at the end of the db.movie file it creates.
The final step for the fx.movie.edu administrator is to send a similar message to [email protected] (the administrator of the 192.in-addr.arpa zone), requesting that the 20.254.192.in-addr.arpa subdomain be delegated to alien.fx.movie.edu , bladerunner.fx.movie.edu , and outland.fx.movie.edu .
Managing delegation with stubs
If you’re running a recent BIND nameserver, you don’t have to manage delegation information manually. BIND 8 and 9 nameservers support an experimental feature called stub zones, which enable a nameserver to pick up changes to delegation information automatically.
A nameserver that’s configured as a stub for a zone periodically sends discrete queries for the zone’s SOA and NS records, as well as any necessary glue A records. The nameserver then uses the NS records to delegate the zone from its parent, and the SOA record governs how often the nameserver does these queries. Now, when the administrators of a subdomain make changes to the subdomain’s nameservers, they simply update their NS records (and increment the serial number in the SOA record, of course). The parent zone’s authoritative nameservers, configured as stub for the child zone, pick up the updated records within the refresh interval.
On the movie.edu nameservers, here’s what we’d add to named.conf:
zone "fx.movie.edu" {
type stub;
masters { 192.253.254.2; };
file "stub.fx.movie.edu";
};Note that, if we’re running BIND 9 nameservers, we must configure all movie.edu nameservers—including slaves—as stubs for fx.movie.edu. BIND 9 nameservers don’t “promote” the fx.movie.edu delegation information into the parent zone, so the fx.movie.edu zone’s delegation isn’t included in zone transfers. Making all the movie.edu nameservers stubs for the subdomain keeps them synchronized.
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 have started out with a few hosts, probably in the movie.edu zone. After a generous endowment, an NSF grant, or a corporate gift, the lab might expand a little and a few more computers might be purchased. 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 reports 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 hostnames in message headers using a nameserver before sending the messages. This turns 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 the section "What’s a Mail Exchanger, Again?" in Chapter 5.
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 of the hosts. For example, using the fx.movie.edu host table, we can 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 slave 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 creates 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 can create aliases in movie.edu for all fx.movie.edu hosts.
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 even though one of your motivations for implementing a subdomain was to make 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 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 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, for example, deletes 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
The Life of a Parent
That’s a lot of parental advice to digest in one sitting, so let’s recap the highlights of what we’ve talked about. The lifecycle of a typical parent goes something like this:
You have a single zone, with all your hosts in that zone.
You break your zone into a number of subdomains, some of them in the same zone as the parent, if necessary. You provide CNAME records in the parent zone for well-known hosts that have moved into subdomains.
After a grace period, you delete any remaining CNAME records.
You handle subdomain delegation updates, either manually or by using stub zones, and periodically check delegation.
Okay, now that you know all there is to parenting, let’s go on to talk about more advanced nameserver features. You may need some of these tools to keep those kids in line.
[*] Actually, not all mailers have this problem, but some popular versions of sendmail do. It all depends on which form of canonicalization they do, as we discussed in the section "Local Nameserver" in Chapter 6.
[*] Clearly, though, a nameserver can’t be both the primary and a slave for a single zone. Either the nameserver gets the data for a given zone from a local zone datafile (and is a primary for the zone) or from another nameserver (and is a slave for the zone).
[*] Older BIND 8 nameservers are syntactically challenged and require that you omit the class (“IN”) field.
[*] We first saw this explained by Glen Herrmansfeldt of CalTech in the newsgroup comp.protocols.tcp-ip.domains. It’s now codified as RFC 2317.