2.4 Name Servers and Zones
The
programs that store information about the domain name space are
called name servers. Name servers generally have
complete information about some part of the domain name space (a
zone), which they load from a file or from
another name server. The name server is then said to have
authority for
that zone. Name servers can be authoritative for multiple zones, too.
The difference between a zone and a domain
is important, but subtle. All top-level domains, and many domains at
the second level and lower, such as berkeley.edu
and hp.com, are broken into smaller, more
manageable units by delegation. These units are called zones. The
edu domain, shown in Figure 2-8, is divided into many zones, including the
berkeley.edu zone, the
purdue.edu zone, and the
nwu.edu zone. At the top of the domain,
there's also an edu zone. It's
natural that the folks who run edu would break
up the edu domain: otherwise, they'd have
to manage the berkeley.edu subdomain themselves.
It makes much more sense to delegate
berkeley.edu to Berkeley. What's left for
the folks who run edu? The
edu zone, which would contain mostly delegation
information for subdomains of edu.
The berkeley.edu subdomain is, in turn, broken
up into multiple zones by delegation, as shown in Figure 2-9. There are delegated subdomains called
cc, cs,
ce, me, and more. Each of
these subdomains is delegated to a set of name servers, some of which
are also authoritative for berkeley.edu.
However, the zones are still separate, and may have a totally
different group of authoritative name servers.
A zone and a domain may share the same domain name but contain
different nodes. In particular, the zone doesn't contain any
nodes in delegated subdomains. For example, the top-level domain
ca (for Canada) has subdomains called
ab.ca, on.ca, and
qc.ca, for the provinces Alberta, Ontario, and
Quebec. Authority for the ab.ca,
on.ca, and qc.ca subdomains
may be delegated to name servers in each of the provinces. The domain
ca contains all the data in
ca plus all the data in
ab.ca, on.ca, and
qc.ca. But the zone ca
contains only the data in ca (see Figure 2-10), which is probably mostly pointers to the
delegated subdomains. And ab.ca, on.ca,
and qc.ca are separate zones from the
ca zone.
If a subdomain of the domain isn't delegated away, however, the
zone contains the domain names and data in the subdomain. So the
bc.ca and sk.ca (British
Columbia and Saskatchewan) subdomains of the ca
domain may exist, but might not be delegated. (Perhaps the provincial
authorities in B.C. and Saskatchewan aren't yet ready to manage
their own zones, but the authorities running the top-level
ca zone want to preserve the consistency of the
namespace and implement subdomains for all of the Canadian provinces
right away.) In this case, the zone ca has a
ragged bottom edge, containing bc.ca and
sk.ca but not the other ca
subdomains, as shown in Figure 2-11.
Now it's clear why name servers load zones instead of domains:
a domain might contain more information than the name server
needs. A domain could contain data delegated
to other name servers. Since a zone is bounded by delegation, it
never includes delegated data.
If you're just starting out, however, your domain probably
won't have any subdomains. In this case, since there's no
delegation going on, your domain and your zone contain the
same
data
.
2.4.1 Delegating Subdomains
Even
though you may not need to delegate parts of your domain just yet,
it's helpful to understand a little more about how the process
of delegating a subdomain works. Delegation, in the abstract,
involves assigning responsibility for some part of your domain to
another organization. What really happens, however, is the assignment
of authority for your subdomains to different name servers. (Note
that we said "name servers," not just "name
server.")
Your zone's data, instead of containing information in the
subdomain you've delegated, includes pointers to the name
servers that are authoritative for that subdomain. Now if one of your
name servers is asked for data in the subdomain, it can reply with a
list of the right name servers to talk to.
2.4.2 Types of Name Servers
The DNS specs define two types of name
servers: primary masters and
secondary masters. A primary
master name server for a zone reads the data for the zone
from a file on its host. A secondary master name
server for a zone gets the zone data from another name server that is
authoritative for the zone, called its master
server. Quite often, the master name server is
the zone's primary master, but that's not required: a
secondary master can load zone data from another secondary. When a
secondary starts up, it contacts its master server and, if necessary,
pulls the zone data over. This is referred to as a
zone transfer.
Nowadays, the preferred term for a secondary master name server is a
slave, though many people (and much software,
including Microsoft's DNS Manager) still use the old term.
Both the primary master and slave name servers for a zone are
authoritative for that zone. Despite the somewhat disparaging name,
slaves aren't second-class name servers. DNS provides these two
types of name servers to make administration easier. Once
you've created the data for your zone and set up a primary
master name server, you don't need to fool with copying that
data from host to host to create new name servers for the zone. You
simply set up slave name servers that load their data from the
primary master for the zone. Once they're set up, the slaves
transfer new zone data when necessary.
Slave name servers are important because it's a good idea to
set up more than one name server for any given zone. You'll
want more than one for redundancy, to spread the load around, and to
ensure that all the hosts in the zone have a name server close by.
Using slave name servers makes this
administratively workable.
Calling a particular name server a primary
master name server or a slave name server is a little imprecise,
though. We mentioned earlier that a name server can be authoritative
for more than one zone. Similarly, a name server can be a primary
master for one zone and a slave for another. Most name servers,
however, are either primary for most of the zones they load or slave
for most of the zones they load. So if we call a particular name
server a primary or a slave, we mean that it's the primary
master or a slave for most of the zones
it's authoritative for.
2.4.3 Zone Data Files
The files from which primary master name servers load their zone data
are called, simply enough, zone data files. We often refer to them as
data files or database files. Slave name
servers can also load their zone data from data files. Slaves are
usually configured to back up the zone data they transfer from a
master name server to data files. If the slave is later killed and
restarted, it will read the backup data files first, then check to
see whether its zone data is current. This both obviates the need to
transfer the zone data if it hasn't changed and provides a
source of the data if the master is down.
The data files contain resource records that describe the zone. The
resource records describe all the hosts in the zone and mark any
delegation of subdomains. BIND also allows special directives to
include the contents of other data files in a zone data file, much
like the #include statement in C
programming.
|
