| I l@ve RuBoard |
|
9.4 How to Become a Parent: Creating SubdomainsOnce you've decided on names, creating the 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 deciding 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 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 them is probably wasted effort. 9.4.1 Creating a Subdomain in the Parent's ZoneYou 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 could 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 could 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 that there's no SOA record for personnel.movie.edu ? There's no need for one, since the movie.eduSOA 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 SubdomainIf 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 zone for redundancy—a single fx.movie.eduname 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/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 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 zone data file 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 master name server: 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";
};
Here are the contents of the corresponding named.boot file for BIND 4: directory /var/named primary 0.0.127.in-addr.arpa db.127.0.0 ; loopback primary fx.movie.edu db.fx.movie.edu 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.movie.edu, 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 name 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
> jedi
Server: bladerunner.fx.movie.edu
Address: 192.253.254.2
Name: jedi.fx.movie.edu
Address: 192.253.253.6
> set type=mx
> empire
Server: 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.3
Server: 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 name server for fx.movie.eduand then delegate fx.movie.edu from movie.edu. 9.4.3 An fx.movie.edu SlaveSetting 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. 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";
};
Or, the equivalent named.boot file: directory /var/named primary 0.0.127.in-addr.arpa db.127.0.0 secondary fx.movie.edu 192.253.254.2 bak.fx.movie.edu secondary 254.253.192.in-addr.arpa 192.253.254.2 bak.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 Name ServerAll that's left now is to delegate the fx.movie.edu subdomain to the new fx.movie.edu name servers 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 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 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.edu give only 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 movie.edu zone data 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.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.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 caches 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. A BIND 4.9 or later name server automatically ignores any glue you include that isn't strictly necessary and logs the fact that it has ignored the record(s) to syslog on the primary master or in the slave's backup copy of the zone data. For example, if we had an NS record for movie.edu that pointed to an off-site name server, ns-1.isp.net, and we made the mistake of including its address in db.movie.edu on the movie.edu primary master name server, we'd see a message like this in named 's syslog output: Aug 9 14:23:41 terminator named[19626]: dns_master_load: db.movie.edu:55: ignoring out-of-zone data If we were running a pre-4.9 name server as our primary master and it mistakenly included an unnecessary glue record in a zone transfer to a newer name server, we'd see a message like this in the backup zone data file: ; Ignoring info about ns-1.isp.net, not in zone movie.edu ; ns-1.isp.net 258983 IN A 10.1.2.3 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 in movie.edupointing the old domain name to the new one: plan9 IN CNAME plan9.fx.movie.edu. This will allow people outside movie.eduto 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.edu file. The plan9 alias is actually in the movie.edu zone (the owner of the record is plan9.movie.edu), so it belongs in 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 were to put a record in the zone data file that was outside the zone the file described, a BIND 4.9 or later name server would ignore it, as shown earlier in the unnecessary glue example. An older name server might load it into 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 ZoneWe 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 in-addr.arpazone 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/8 or 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. 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 that chapter.) All that's left is for us to use the web-based " Modify Tool" at http://www.arin.net/cgi-bin/amt.pl to request registration of our reverse-mapping zone. 9.4.6 Adding a movie.edu SlaveIf 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.eduhosts can be answered locally. It seems logical to make one of the existing fx.movie.eduname 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: acting as the primary master name server 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]
The configuration change is simple: we add one statement to bladerunner 's named.conf file to tell named to load the movie.eduzone from the IP address of the movie.edu primary master name server, terminator.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";
};
Or, if you're using a BIND 4 name server, here are the contents of the named.boot file: directory /var/named primary 0.0.127.in-addr.arpa db.127.0.0 ; loopback primary fx.movie.edu db.fx.movie.edu primary 254.253.192.in-addr.arpa db.192.253.254 secondary movie.edu 192.249.249.3 bak.movie.edu cache . db.cache |
| I l@ve RuBoard |
|