|
|
DNS and BIND, 3rd Edition
By Paul Albitz & Cricket Liu
3rd Edition September 1998
1-56592-512-2, Order Number: 5122
502 pages, $39.95
|
Chapter 9 ParentingThe 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 on the domain tree; 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 child domains, and then delegating
the subdomains to create new zones. Responsible parents also work hard
at maintaining the relationship between the name servers authoritative
for their zone and its children; they ensure 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 name servers can render
a site effectively unreachable, while the loss of connectivity to the
parent zone's name servers 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 a minimum of disruption and
inconvenience.
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 of the most
common reasons:
A need to delegate or distribute management of the domain to a
number of organizations
The large size of your domain - dividing it would make it
easier to manage and offload the name servers for the domain
A need to distinguish hosts' organizational affiliation by
including them in particular domains
Once you've decided to have children, the next question to ask
yourself is, naturally, how many children to have.
Of course, you won't simply say, "I want to create four
subdomains." Deciding how many child domains to implement is
really choosing the organizational affiliation of your 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
domain, because there's not much delegation to keep track of. However,
you wind up with larger subdomains, which require more memory and
faster name servers, 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 name space and a
single point of administration.
Delegating to many smaller subdomains can be a headache for the
administrator of the parent. Keeping delegation data current involves
keeping track of which hosts run name servers and which zones they're
authoritative for. The data change each time a subdomain adds a new
name server, or when the address of a name server for the subdomain
changes. If the subdomains are all administered by different people,
that means more administrators to train, more relationships for the
parent 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 subdomain data.
Given the advantages and disadvantages of either alternative, it
may seem difficult to make a choice. Actually, though, 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 name space:
Don't shoehorn your organization into a weird or uncomfortable
domain structure. Trying to fit 50 independent, unrelated
U.S. divisions into 4 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
domains - 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, then
departments should 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 their own subdomain (e.g., how many
hosts do you need to create a new subdomain, what level of support
must the group provide) and grow the namespace organically, only as
needed.
Once you've decided how many subdomains you'd like to create and what
they correspond to, you should choose good 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 nice to use a relatively
consistent naming scheme across your subdomains. It 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
(RAT) 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 not 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 it 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,[1] since the name of your parent zone may be in some of your
hosts' search lists.
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.
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
PCs' 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.
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
> 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
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.3
Server: 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.
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.
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.
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.
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]
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
Forward mapping domains aren't the only domains you can divide into
subdomains and delegate. If your in-addr.arpa name space is large enough,
you may need to divide it, too. Typically, you divide the domain that
corresponds to your network number into subdomains to correspond to
your subnets. How that works depends on the type of network you have
and on your network's subnet mask.
Since Movie U. just has three /24 (class C-sized) network numbers, 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. Their network is subnetted between the
third and fourth octet of the IP address; that is,
their subnet mask is 255.255.255.0. They've already created a number
of subdomains of their domain, altered.edu, including fx.altered.edu (okay, we copied them),
makeup.altered.edu, and
foley.altered.edu. Since
each of these departments also runs its own subnet (their special
effects department runs subnet 172.20.2.0, makeup runs 172.20.15.0,
and foley runs 172.20.25.0), they'd like to divvy up their in-addr.arpa namespace appropriately,
too.
Delegating in-addr.arpa
subdomains is no different from delegating subdomains of
forward-mapping domains. Within their db.172.20
file, they need 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 muppetshow.foley.altered.edu.
delegating the subdomain that corresponds to each subnet to the
correct name server in each subdomain.
Two important reminders: the Altered States administrators needed to use
the fully qualified domain names of the name servers in the
NS records, because the default origin in this file
is 20.172.in-addr.arpa, and
they didn't need glue address records, since the
names of the name servers they delegated the zone to weren't in the
zone.
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 subdomain, or
you have multiple in-addr.arpa subdomains per
subnet. Neither is particularly pleasing.
Let's take the case of the /8 (class A-sized) network 15.0.0.0,
subnetted with the subnet mask 255.255.248.0 (a thirteen-bit subnet
field and an eleven-bit host field, or 8192 subnets of 2048 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 database file for 15.in-addr.arpa, looks 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!
In the case of a subnetted /24 (class
C-sized) network, say 192.253.254.0, 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. You can solve this one of
three ways, none of them pretty.
Solution 1
The first 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 like MIT's WebDNS
(http://hem.passagen.se/hno/webdns/) to
allow each of the four administrators to take care of their 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'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.
130.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com.
194.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com.
194.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. 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";
};
Or, if ns1.foo.com were
running BIND 4, you'd expect to see these
directives in named.boot:
primary 1.254.253.192.in-addr.arpa db.192.253.254.1
primary 2.254.253.192.in-addr.arpa db.192.253.254.2
and in db.192.253.254.1, just the one
PTR record:
@ IN SOA ns1.foo.com. root.ns1.foo.com. (
1 ; Serial
10800 ; Refresh
3600 ; Retry
608400 ; Expire
86400 ; Default 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, since the zone's domain name corresponds to just
one IP address. Now, when a 254.253.192.in-addr.arpa name server
receives a query for the PTR record for 1.254.253.192.in-addr.arpa, it will refer
the querier to ns1.foo.com
and ns2.foo.com, which will
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 data file for each IP
address.[3] The organization responsible for the overall /24 network
creates CNAME records for each of the domain names
in the zone, pointing to domain names in new subdomains, called
0-63, 64-127, 128-191, and 192-255, which are then delegated to the
proper servers. Each subdomain will contain only the
PTR records in the range the subdomain is named
for.
Partial contents of file 254.253.192.in-addr.arpa.dns:
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.
The zone data file for 0-63.254.253.192.in-addr.arpa,
0-63.254.253.192.in-addr.arpa.dns, can contain
just PTR records for IP
addresses 192.253.254.1 through 192.253.254.63.
Partial contents of file
0-63.254.253.192.in-addr.arpa:
@ IN soa ns1.foo.com. root.ns1.foo.com. (
1 ; Serial
10800 ; Refresh
3600 ; Retry
608400 ; Expire
86400 ) ; Default 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.
...
When a resolver requests the PTR record for
1.254.253.192.in-addr.arpa, a
254.253.192.in-addr.arpa name
server will transparently (to the resolver) map this to a request for
the PTR record for 1.0-63.254.253.192.in-addr.arpa. This
request will wind up at one of the 0-63.254.253.192.in-addr.arpa name
servers, run by the organization that runs the low
(addresses 0-63)
subnet.
Now that the delegation to the fx.movie.edu name servers is in place,
we - responsible parents that we are - should check that
delegation using check_del. What? We haven't given
you check_del yet? Unfortunately,
check_del is too long to include in this book, but
we've made it available via anonymous ftp. See the
preface for details. Feel free to snatch the code there and compile
it if you want to follow along.
check_del "knows"
delegation. check_del reads NS
records. For each NS record,
check_del issues a query to the name server listed
for the zone's SOA record. The query is
nonrecursive, so the name server queried doesn't query other name
servers to find the SOA record. If the name server
replies, check_del checks the reply to see whether
the
aa - authoritative answer - bit in the
reply packet is set. If it is, the name server checks to make sure
that the packet contains an answer. If both these criteria are met,
the name server is flagged as authoritative for the zone. Otherwise,
the name server is not authoritative, and check_del
reports an error.
Why all the fuss over bad delegation? Incorrect delegation can
cause the propagation of old and erroneous root name server
information. When a name server is queried for data in a zone it isn't
authoritative for, it does its best to provide useful information to
the querier. This "useful information" comes in the form
of NS records for the closest ancestor domain the
name server knows. (We mentioned this briefly in Chapter 8, Growing Your Domain, when we discussed why you shouldn't register a
caching-only name server.)
For example, say one of the fx.movie.edu name servers mistakenly
receives an iterative query for the address of carrie.horror.movie.edu. It knows
nothing about the horror.movie.edu domain (except for what
it might have cached), but it likely has NS records
for movie.edu cached, since
those are its parent name servers. So it would return those records to
the querier.
In that scenario, the NS records may help the
querying name server get an answer. However, it's a fact of life on
the Internet that not all administrators keep their cache files up to
date. If one of your name servers follows a bad delegation and queries
a remote name server for records it doesn't have, look what can
happen:
% nslookup
Default Server: terminator.movie.edu
Address: 192.249.249.3
> set type=ns
> .
Server: terminator.movie.edu
Address: 192.249.249.3
Non-authoritative answer:
(root) nameserver = D.ROOT-SERVERS.NET
(root) nameserver = E.ROOT-SERVERS.NET
(root) nameserver = I.ROOT-SERVERS.NET
(root) nameserver = F.ROOT-SERVERS.NET
(root) nameserver = G.ROOT-SERVERS.NET
(root) nameserver = A.ROOT-SERVERS.NET
(root) nameserver = H.ROOT-SERVERS.NETNIC.NORDU.NET
(root) nameserver = B.ROOT-SERVERS.NET
(root) nameserver = C.ROOT-SERVERS.NET
(root) nameserver = A.ISI.EDU - These three name
(root) nameserver = SRI-NIC.ARPA - servers are no longer
(root) nameserver = GUNTER-ADAM.ARPA - roots
A remote name server tried to "help out" our local
name server by sending it the current list of roots. Unfortunately,
the remote name server was corrupt, and returned NS
records that were incorrect. And our local name server, not knowing
any better, cached that data.
Queries to misconfigured
in-addr.arpa name servers
often result in bad root NS records, because the
in-addr.arpa and arpa domains are the closest ancestors of
most in-addr.arpa subdomains,
and name servers very seldom cache either in-addr.arpa or arpa's NS
records. (The roots seldom give them out, since they delegate directly
to lower-level subdomains.) Once your name server has cached bad root
NS records, your name resolution may suffer.
Those root NS records may have your name
server querying a root name server that is no longer at that
IP address, or a root name server that no longer
exists at all. If you're having an especially bad day, the bad root
NS records may point to a real, non-root name
server that is close to your network. Even though it won't return
authoritative root data, your name server will favor it because it
will have a low RTT due to its proximity to your
network.
If our little lecture has convinced you of the importance of
maintaining correct delegation, you'll be eager to learn how to use
check_del to ensure that you don't join the ranks
of the miscreants.
check_del usually takes two arguments: the
name of a data file to check, and the default origin in the data
file. The default origin tells check_del the domain
name to append to relative names in the file. (When
named reads the db file, it learns the default
origin in the named.conf or
named.boot file; it's at the beginning of the
zone statement, and always the second field
in a primary or
secondary
directive. check_del doesn't read the conf or boot
file, though, so you need to specify the domain name on the command
line. If it read the conf or boot file, it'd be limited to checking
only db files listed in it.)
To check whether the db.movie file contains
proper delegation to fx.movie.edu (and any other subdomains),
we'd run:
% check_del -o movie.edu -f db.movie
If the delegation is correct, we'd see this:
5 domains properly delegated
Actually, it's one domain delegated to three authoritative
servers (movie.edu delegated
to terminator, wormhole, and zardoz), and one subdomain delegated to
two authoritative servers (fx.movie.edu delegated to bladerunner and outland), but
check_del doesn't know that. The point is that all
the NS records in db.movie are
correct.
If one of the fx.movie.edu name servers - say
outland - were
misconfigured, we'd see this:
Server outland.fx.movie.edu is not authoritative for fx.movie.edu
4 domains properly delegated
1 domains improperly delegated
Okay, check_del doesn't really understand
plurals, either.
If one of the fx.movie.edu name servers weren't running
at all, we'd see:
4 domains properly delegated
1 servers not running
Servers not running:
outland.fx.movie.edu
In this case, not running really means that
check_del tried to send the name server a query and
got an ICMP port unreachable error back, which
indicated that nothing was listening on the name server port.
And if the name server didn't answer in an acceptable amount of
time, you'd see:
4 domains properly delegated
1 servers not responding
Servers not responding:
outland.fx.movie.edu
If the special effects lab gets bigger, we may find that we need
additional name servers. We dealt with setting up new name servers in
Chapter 8, and even went over what information to
send to the parent zone's administrator. But we never explained what
the parent needed 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. They have a passel of new, high-powered graphics
workstations. One of them, alien.fx.movie.edu, will act as the
network's name server.
The administrators of fx.movie.edu (we delegated it to the
folks in the lab) send their parent zones' 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
ajs@fx.movie.edu
----- 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.
What if we're using h2n to create our name
server 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 hostmaster@internic.net
(administrator for the in-addr.arpa domain), requesting that the
20.254.192.in-addr.arpa
domain be delegated to alien.fx.movie.edu, bladerunner.fx.movie.edu, and outland.fx.movie.edu.
If you're running BIND 4.9 or
BIND 8 name servers, you don't have to manage
delegation information manually. BIND 4.9 and
BIND 8 name servers support an experimental
feature, called stub, which enables a name
server to pick up changes to delegation information
automatically.
Name servers that act as stubs for a subdomain do periodic zone
transfers of the subdomain's data, but they ignore everything in it
except for the NS records and the
SOA record. The NS records are
"promoted" into the parent zone, and the
SOA record governs how often the stub does zone
transfers. Now, when the administrators of a subdomain make changes
to the subdomain's name servers, they simply update their
NS records. The parent zone's authoritative name
servers will pick up the updated records within the refresh
interval.
On the movie.edu name
servers running BIND 8, here's what we'd add to
named.conf:
zone "fx.movie.edu" {
type stub;
file "db.fx";
masters { 192.253.254.2; };
};
On a BIND 4.9 name server, we'd use this
directive:
stub fx.movie.edu 192.253.254.2 db.fx
Note that we should configure all of the movie.edu name servers as stubs for
fx.movie.edu, because if the
fx.movie.edu delegation
information changes, that won't change the movie.edu zone's serial number.
We won't lie to you - the fx.movie.edu example we showed you was
unrealistic for several reasons. The main one is the magical
appearance of the special effects lab's hosts. In the real world, the
lab would have started out with a few hosts, probably in the
movie.edu zone. After a
generous endowment, an NSF grant, or a corporate
gift, they might expand the lab a little and buy a few more
computers. Sooner or later, the lab would have enough hosts to warrant
the creation of a new subdomain. By that point, however, many of the
original hosts would be well known by their names under movie.edu.
We briefly touched on using
CNAME records under the parent domain (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 like
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 will report 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 mail to accept mail addressed to the new domain
names. Modern versions of sendmail canonicalize the
host names in addresses in message headers using a name server before
sending the messages. This will turn 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'd 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 "The MX Algorithm" in Chapter 5, DNS and Electronic Mail.
How do you create all these aliases? You simply need to tell
h2n to create the
aliases for hosts on the fx.movie.edu networks (192.253.254 and
192.254.20), and indicate (in the /etc/hosts
file) what the new domain names for the hosts are. For example, using
the fx.movie.edu host table,
we could easily generate the aliases under 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 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
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'll
create 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 could create
aliases under movie.edu for
all fx.movie.edu
hosts.
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 name
space, when one of your motivations for implementing a subdomain may
have been making 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 the 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 at the parent zone
level.
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 line, for
example, would delete all the CNAME records for
fx.movie.edu hosts created
earlier, while still creating an A record for movie-gw (which is on the 192.253.254
network):
% h2n -d movie.edu -n 192.253.254 -n 192.254.20 \
-e fx.movie.edu -f options
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 life cycle
of a typical parent goes something like this:
You have a single zone, with all of 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 stubs, and periodically check delegation.
Okay, now that you know all there is to parenting, let's go on
to talk about more advanced name server features. You may need some of
these tools to keep those kids in line.
oreilly.com Home |
O'Reilly Bookstores |
How to Order |
O'Reilly Contacts
International |
About O'Reilly |
Affiliated Companies |
Privacy Policy
© 2001, O'Reilly & Associates, Inc.