لطفا منتظر باشید ...
9.2 Adding More Name Servers
When you need to create new name servers for your domain, the
simplest recourse is to add secondaries. You already know
howwe went over it in Chapter 4and
once you've set up one secondary, cloning it is a
piece of cake. But you can run into trouble if you add secondaries
indiscriminately.
If you run a large number of secondary name servers for a zone, the
primary master name server can take quite a beating just keeping up
with the secondaries' polling to check that their
zone data is current. There are a number of courses of action to take
for this problem, as described in the sections that follow:
Eliminate the secondary name servers altogether by using Active
Directory integration.
Increase the refresh interval so that the secondaries
don't check so often.
Direct some of the secondary name servers to load from other
secondary name servers.
Create caching-only name servers.
Create partial-secondary name servers.
9.2.1 Active Directory Integration
We
discuss
Chapter 8. Briefly, this feature eliminates the load on
the primary master from secondaries' polling by
eliminating the secondaries! Remember that the main purpose of the
primary master/secondary relationship is zone data replication: the
DNS designers created the zone transfer mechanism as a way to spread
zone data among multiple authoritative name servers. Windows stores
all kinds of information about the network in Active Directory and
replicates this information, too. With Windows Server 2003, you have
the option of storing the definitive version of your
zones' data in Active Directory rather than in zone
datafiles on the primary master. All name servers running on domain
controllers load the zone data stored in Active Directory, which also
takes care of replicating changes to the data. See Chapter 8 for more details and instructions on setting
up Active Directory.
9.2.2 Secondary Servers
You can have some of your
secondaries load zone data from other secondary name servers instead
of from a primary name server. The secondary name server
can't tell if it's loading from a
primary or another secondary. It's only important
that the name server serving the zone transfer is authoritative for
the zone. There's no trick to configuring this.
Instead of specifying the IP address of the primary in the
secondary's configuration, you simply specify the IP
address of another secondary
When you go to this second level of
distribution, though, be aware that it can take up to twice as long
for the data to percolate from the primary name server to all the
secondaries. Remember that the refresh interval is the period after
which the secondary servers check to make sure that their zone data
is still current. Therefore, it can take the first-level secondary
servers the entire length of the refresh interval to get a new copy
of the zone from the primary master server. Similarly, it can take
the second-level secondary servers the entire refresh interval to get
a new copy of the zone from the first-level secondary servers. The
propagation time from the primary master server to all the secondary
servers can therefore be twice the refresh interval.
Fortunately, using the DNS NOTIFY feature, which
we'll describe in Chapter 11,
avoids this delay. This feature is on by default and triggers zone
transfers soon after the zone is updated on the primary master.
Unfortunately, it doesn't work with any BIND Version
4 secondaries (they'll receive the NOTIFY messages,
but will not understand them). Active Directory-integration,
described in Chapter 8, also avoids zone
synchronization delays.
If you decide to configure your network with two (or more) tiers of
secondary servers, be careful to avoid updating loops. If we
configured wormhole to update from
diehard and then accidentally configured
diehard to update from
wormhole, neither would ever get data from the
primary master. They would merely check their out-of-date serial
numbers against each other and perpetually decide that they were both
up-to-date.
9.2.3 Caching-Only Servers
Creating caching-only
name servers is another alternative when you need more
servers. Caching-only name servers are name servers not authoritative
for any zones (except for the automatically created reverse-mapping
zones). The name doesn't imply that primary master
and secondary name servers don't cachethey
dobut rather that the only function this
server performs is looking up data and caching it. As with primary
master and secondary name servers, a caching-only name server needs a
cache.dns file and the automatically created
zones, 0.in-addr.arpa,
127.in-addr.arpa, and
255.in-addr.arpa. The configuration of a
caching-only server looks like Figure 9-4.
Figure 9-4. The DNS console showing a caching-only name server
A caching-only name server can look up domain names inside and
outside your zone, as can primary master and secondary name servers.
The difference is that when a caching-only name server initially
looks up a name within your zone, it ends up asking one of your
zone's primary master or secondary name servers for
the answer. A primary or secondary would answer the same question out
of its authoritative data. Which primary or secondary does the
caching-only server ask? As with name servers outside of your domain,
it finds out which name servers serve your zone from one of the name
servers for your parent zone. Is there any way to prime a
caching-only name server's cache so it knows which
hosts run primary and secondary name servers for your zone? No, there
isn't. You can't use
cache.dnsthe
cache.dns file is only for root name server
hints.
A caching-only name server's real value comes after
it builds up its cache. Each time it queries an authoritative name
server and receives an answer, it caches the records in the answer.
Over time, the cache grows to include the information most often
requested by the resolvers querying the caching-only name server. And
you avoid the overhead of zone transfersa caching-only name
server doesn't need to do them.
9.2.4 Partial-Secondary Servers
In between a caching-only name server
and a secondary name server is another variation: a name server that
is a secondary for only a few of the local zones. We call this a
partial-secondary name server (although probably
nobody else does). Suppose movie.edu had
20/24-sized (the old Class C) networks (and a corresponding 20
in-addr.arpa zones). Instead of creating a
secondary server for all 21 zones (all the
in-addr.arpa subdomains plus
movie.edu), we could create a partial-secondary
server for movie.edu and only those
in-addr.arpa zones the host itself is in. If the
host had two network interfaces, its name server would be a secondary
for three zones: movie.edu and the two
in-addr.arpa zones.
Let's say we scare up the hardware for another name
server. We'll call the new host
zardoz.movie.edu, with IP addresses
192.249.249.9 and 192.253.253.9. We'll create a
partial-secondary name server on zardoz, with
the configuration shown in Figure 9-5.
Figure 9-5. The DNS console showing a partial-secondary server
This server is a secondary for movie.edu and
only 2 of the 20 in-addr.arpa zones. A
"full" secondary would have 20
different zones (plus the three automatically created) under
Reverse Lookup Zones.
What's so useful about a partial-secondary name
server? They're not much work to administer because
their configuration doesn't change much. On a server
authoritative for all the in-addr.arpa zones,
we'd need to add and delete
in-addr.arpa zones as our network changed. That
can be a surprising amount of work on a large network.
A partial secondary can still answer most of the queries it receives,
though. Most of these queries are for data in
movie.edu and the two
in-addr.arpa zones. Why? Because most of the
hosts querying the name server are on the two networks to which
it's connected, 192.249.249/24 and 192.253.253/24.
And those hosts probably communicate primarily with other hosts on
their own network. This generates queries for data within the
in-addr.arpa
zone that corresponds to the local
network.
