9.4 How to Become a Parent: Creating Subdomains
Once
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 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 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 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 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 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.
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 Server
All 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 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 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 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.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.
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
|
