لطفا منتظر باشید ...
2.4 Name Servers and Zones
The programs that store
information
about the domain namespace are called name
servers. Name servers generally have complete
information about some part of the domain namespace, called 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
contains mostly delegation information for the subdomains of
edu.
Figure 2-8. The edu domain broken into zones
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 totally different
groups of authoritative name servers.
Figure 2-9. The berkeley.edu domain broken into zones
A
zone contains all the domain names the domain with the same domain
name contains, except for domain names 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 domains 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. However, the zone
ca contains only the data in
ca (see Figure 2-10), which is
probably mostly pointers to the delegated subdomains.
ab.ca, on.ca, and
qc.ca are separate zones from the
ca zone.The zone also contains the domain
names and data in any subdomains that aren't
delegated away. For example, the bc.ca and
sk.ca (British Columbia and Saskatchewan)
subdomains of the ca domain may exist but not be
delegated. (Perhaps the provincial authorities in B.C. and
Saskatchewan aren't yet ready to manage their
subdomains, but the authorities running the top-level
ca domain 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.
Figure 2-10. The domain ca . . .
Figure 2-11. versus the zone ca . . .
Now it's clear why name servers load zones instead
of domains: a domain may contain more information than the name
server needs, since it can contain data delegated to other name
servers.[6] Since a zone is bounded by delegation,
it will never include delegated data.[6] Imagine if a root name server loaded the
root domain instead of the root zone: it would be loading the entire
namespace!
If you're just starting out, your domain probably
won't have any subdomains. In this case, since
there's no delegation going on, your domain and your
zone will 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 a subdomain 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 contact.
2.4.2 Types of Name Servers
The DNS specs define two types
of
name servers: primary masters and
secondaries. A
primary master name server
for a zone reads the data for the zone from a file on its host. A
secondary name server for a zone gets the zone
data from another name server authoritative for the zone, called its
master server. Quite often, the master server is the
zone's primary master, but that's
not required: a secondary can load zone data from another secondary.
When a secondary starts up, it contacts its master name server and,
if necessary, pulls the zone data over. This is referred to as a
zone transfer. Nowadays,
the preferred term for a secondary name server is a
slave, though many people (and some software,
including Microsoft's DNS console) still use the old
term.
Both
the primary master and secondary name servers for a zone are
authoritative for that zone. Despite the somewhat disparaging name,
secondaries 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 copy that data from host to host to create new name servers
for the zone. You simply set up secondary name servers that load
their data from the primary master for the zone. The secondaries you
set up will transfer new zone data when necessary.Secondary name servers are important because it's a
good idea to set up more than one authoritative name server for any
given zone. You'll want more than one for
redundancy, to spread the load around, and to make sure that all the
hosts in the zone have a name server close by. Using secondary name
servers makes this administratively workable.Calling a particular name server a primary
master name server or a secondary 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 secondary for another. Most name servers,
however, are either primary for most of the zones they load or
secondary for most of the zones they load. So if we call a particular
name server a primary or a secondary, we mean that
it's the primary master or a secondary for
most of the zones for which
it's
authoritative.
2.4.3 Datafiles
The files from which primary master name
servers load their zone data are called, simply enough,
zone datafiles. We often
refer to them as datafiles. Secondary name
servers can also load their zone data from datafiles. Secondaries are
usually configured to back up the zone data they transfer from a
master name server to datafiles. If the secondary is later killed and
restarted, it will read the backup datafiles 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.
