|
Chapter 9 Parenting |
|
9.4 How to Become a Parent: Creating Subdomains
Once you've decided on names, creating child domains is easy. But first, you've got to 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 or not to delegate it. It doesn't make sense to delegate a subdomain to an entity that doesn't manage its own hosts or nets. 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 them is probably wasted effort.
9.4.1 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, brazil . To put brazil in the personnel.movie.edu domain, we could add records to db.movie .
Partial contents of file db.movie :
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 could make this setup especially convenient for personnel department employees by adding personnel.movie.edu to their PC s' or workstations' search lists; they'd only need to type telnet db to get to the right host.
We can make this more convenient for ourselves by using the $ORIGIN directive to change the origin to personnel.movie.edu so that we can use shorter names.
Partial contents of file db.movie :
$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 into db.movie and change the origin at the same time.
Notice there's no SOA record for personnel.movie.edu ? There's no need for one, since 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.
9.4.2 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 name servers ( bladerunner will serve as the primary master). We've chosen to run two name servers for the domain for redundancy - a single fx.movie.edu name server 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, we feel two name servers should be enough.
The special effects lab is on movie.edu 's new 192.253.254 subnet.
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 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
First, we create a data file that includes records for all the hosts that will live in fx.movie.edu .
Contents of file db.fx :
@ IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. (
1 ; serial
10800 ; refresh every 3 hours
3600 ; retry every hour
604800 ; expire after a week
86400 ) ; minimum TTL of 1 day
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:
@ IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. (
1 ; serial
10800 ; refresh every 3 hours
3600 ; retry every hour
604800 ; expire after a week
86400 ) ; minimum TTL of 1 day
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 the fx.movie.edu domain, and there's no requirement that all the PTR records in 254.253.192.in-addr.arpa map into a single domain - though they should correspond to the canonical names for those hosts.
Next, we create an appropriate named.conf file for the primary master:
options {
directory "/usr/local/named";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0";
};
zone "fx.movie.edu" {
type master;
file "db.fx";
};
zone "254.253.192.in-addr.arpa" {
type master;
file "db.192.253.254";
};
zone "." {
type hint;
file "db.cache";
};
Here are the contents of the corresponding named.boot file for BIND 4:
directory /usr/local/named primary 0.0.127.in-addr.arpa db.127.0.0 ; loopback primary fx.movie.edu db.fx primary 254.253.192.in-addr.arpa db.192.253.254 cache . db.cache
Of course, if we'd used h2n , we could have just run:
%h2n -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 saved ourselves some typing. h2n would have created essentially the same db.fx , db.192.253.254 , and named.boot 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 from the fully qualified domain name.
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.253.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 starwars.fx.movie.edu internet address = 192.253.254.4 >ls fx.movie.edu[bladerunner.fx.movie.edu] 1D IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; serial 3H ; refresh 1H ; retry 1w1h ; expire 1D ) ; minimum 1D IN NS bladerunner.fx.movie.edu. 1D IN NS outland.fx.movie.edu. 1D IN MX 10 starwars.fx.movie.edu. 1D IN MX 100 wormhole.movie.edu. br.fx.movie.edu. 1D IN CNAME bladerunner.fx.movie.edu. jedi.fx.movie.edu. 1D IN A 192.253.254.6 1D IN MX 10 starwars.fx.movie.edu. 1D IN MX 100 wormhole.movie.edu. outland.fx.movie.edu. 1D IN A 192.253.254.3 1D IN MX 10 starwars.fx.movie.edu. 1D IN MX 100 wormhole.movie.edu. starwars.fx.movie.edu. 1D IN A 192.253.254.4 1D IN MX 10 starwars.fx.movie.edu. 1D IN MX 100 wormhole.movie.edu. bladerunner.fx.movie.edu. 1D IN A 192.253.254.2 1D IN MX 10 starwars.fx.movie.edu. 1D IN MX 100 wormhole.movie.edu. empire.fx.movie.edu. 1D IN A 192.253.254.5 1D IN MX 10 starwars.fx.movie.edu. 1D IN MX 100 wormhole.movie.edu. fx.movie.edu. 1D IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; serial 3H ; refresh 1H ; retry 1w1h ; expire 1D ) ; 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 254.253.192.in-addr.arpa.[bladerunner.fx.movie.edu] 1D IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; serial 3H ; refresh 1H ; retry 1w1h ; expire 1D ) ; minimum 1D IN NS bladerunner.fx.movie.edu. 1D IN NS outland.fx.movie.edu. 6.254.253.192.in-addr.arpa. 1D IN PTR jedi.fx.movie.edu. 1.254.253.192.in-addr.arpa. 1D IN PTR movie-gw.movie.edu. 2.254.253.192.in-addr.arpa. 1D IN PTR bladerunner.fx.movie.edu. 3.254.253.192.in-addr.arpa. 1D IN PTR outland.fx.movie.edu. 4.254.253.192.in-addr.arpa. 1D IN PTR starwars.fx.movie.edu. 5.254.253.192.in-addr.arpa. 1D IN PTR empire.fx.movie.edu. 254.253.192.in-addr.arpa. 1D IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; serial 3H ; refresh 1H ; retry 1w1h ; expire 1D ) ; minimum >^D
The output looks reasonable, so it's safe to set up a slave name server for fx.movie.edu and to delegate fx.movie.edu from movie.edu .
9.4.3 An fx.movie.edu Slave
Setting up the slave name server 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, Setting Up BIND .
Contents of file named.conf :
options {
directory "/usr/local/named";
};
zone "0.0.127.in-addr.arpa" {
type slave;
file "db.127.0.0";
masters { 192.253.254.2; };
};
zone "fx.movie.edu" {
type slave;
file "db.fx";
masters { 192.253.254.2; };
};
zone "254.253.192.in-addr.arpa" {
type slave;
file "db.192.253.254";
masters { 192.253.254.2; };
};
zone "." {
type hint;
file "db.cache";
};
Or, the equivalent named.boot file:
directory /usr/local/named primary 0.0.127.in-addr.arpa db.127.0.0 secondary fx.movie.edu 192.253.254.2 db.fx secondary 254.253.192.in-addr.arpa 192.253.254.2 db.192.253.254 cache . 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 .
9.4.4 On the movie.edu Primary Master
All that's left now is to delegate the fx.movie.edu domain to the new fx.movie.edu name servers on bladerunner and outland . We add the appropriate NS records to db.movie .
Partial contents of file db.movie :
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 these two lines ( bladerunner.fx.movie.edu and outland.fx.movie.edu ) must be the canonical domain names for the name servers. A remote name server 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 name server outside of fx.movie.edu look up information within fx.movie.edu ? Well, a movie.edu name server would refer it to the name servers authoritative for fx.movie.edu , right? That's true, but the NS records in db.movie only give the names of the fx.movie.edu name servers. The foreign name server needs the IP addresses of the fx.movie.edu name servers in order to send queries to them. Who can give it those addresses? Only the fx.movie.edu name servers. A real chicken-and-egg problem!
The solution is to include the addresses of the fx.movie.edu name servers in the db.movie file. While these aren't strictly part of the movie.edu zone, they're necessary for delegation to fx.movie.edu to work. Of course, if the name servers for fx.movie.edu weren't within fx.movie.edu , these addresses - called glue records - wouldn't be necessary. A foreign name server would be able to find the address it needed by querying other name servers.
So, with the glue records, the records added look like the following partial contents of file db.movie :
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.3
Be sure you don't include unnecessary glue records in the file. Older BIND name servers (pre-4.9) load these records into their cache and give them out in referrals to other name servers. If the name server listed in the address record changes IP addresses and you forget to update the glue, your name server will continue giving out the outdated address information, resulting in poor resolution performance for name servers looking for data in the delegated zone, or even rendering them unable to resolve names in the delegated zone.
BIND 4.9 and BIND 8 will automatically ignore any glue you include that isn't strictly necessary, and will log the fact that it's ignored the record(s) to the slave's backup copy of the zone data. For example, if we had an NS record for movie.edu pointing to an off-site name server, ns-1.isp.net , and we made the mistake of including its address in db.movie on the movie.edu primary, we'd see:
; Ignoring info about ns-1.isp.net, not in zone movie.edu ; ns-1.isp.net 258983 IN A 10.1.2.3
in db.movie on a movie.edu slave. Note that the extraneous A record has been commented out.
Also, remember to keep the glue up to date. If bladerunner gets a new network interface, and hence another IP address, then 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 were to 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 under movie.edu pointing the old name to the new one:
plan9 IN CNAME plan9.fx.movie.edu.
This will allow people outside of movie.edu to reach plan9 even though they're using its old domain name, plan9.movie.edu .
You shouldn't put any information about domain names in fx.movie.edu into the db.movie file. The plan9 alias is actually in the movie.edu zone, so it belongs in db.movie . 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 . If you were to put a record in the db file that was outside of the zone the file described, a BIND 4.9 name server would ignore it. Older name servers might load it into the cache or even into authoritative data, but since the behavior is unpredictable and is eliminated in newer versions of BIND , it's best to do it the right way even if the software doesn't force you to.
9.4.5 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. To figure this out may take some sleuthing; we covered how to do this in Chapter 3, Where Do I Start? .
As it turns out, the 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 or 192.in-addr.arpa to a separate authority, because unless 192.0.0.0 or 192.253.0.0 is all one big CIDR block, networks like 192.253.253 and 192.253.254 don't have anything in common with each other. They may be managed by totally unrelated organizations.
You might have remembered (from Chapter 3 ) that the in-addr.arpa zone is managed by ARIN , the American Registry of Internet Numbers. (Of course, if you didn't remember, you could always use nslookup to find the contact address in in-addr.arpa 's SOA record, like we showed you in Chapter 3 .) All that's left is for us to fill out inaddrtemplate.txt (there's a copy in Appendix E, in-addr.arpa Registration Form , or you can find it online at http://www.arin.net/templates/inaddrtemplate.txt ), and send it to the email address hostmaster@arin.net .
9.4.6 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 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 name servers into a movie.edu slave, too - that way, we can make better use of an existing name server, instead of setting up a brand-new name server.
We've decided to make bladerunner a slave for movie.edu . This won't interfere with bladerunner 's primary mission: the primary master for fx.movie.edu , that is. A single name server, given enough memory, can be authoritative for literally thousands of zones. One name server can load some zones as a primary master and others as a slave.[2]
[2] Clearly, though, a name server can't be both the primary master and a slave for a single zone. Either the name server gets the data for a given zone from a local file (and is a primary master for the zone) or from another name server (and is a slave for the zone).
The configuration change is simple: we add one line to bladerunner 's named.conf file to tell named to load the movie.edu zone from the IP address of the movie.edu primary master name server, terminator.movie.edu .
Contents of file named.conf :
options {
directory "/usr/local/named";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0";
};
zone "fx.movie.edu" {
type master;
file "db.fx";
};
zone "254.253.192.in-addr.arpa" {
type master;
file "db.192.253.254";
};
zone "movie.edu" {
type slave;
file "db.movie";
};
zone "." {
type hint;
file "db.cache";
};
Or, if you're using a BIND 4 name server, here are the contents of the named.boot file:
directory /usr/local/named primary 0.0.127.in-addr.arpa db.127.0.0 ; loopback primary fx.movie.edu db.fx primary 254.253.192.in-addr.arpa db.192.253.254 secondary movie.edu 192.249.249.3 db.movie cache . db.cache
|
|
|
|
| 9.3 What to Name Your Children |
|
9.5 Subdomains of in-addr.arpa Domains |