Dns On Windows Server 1002003 [Electronic resources] نسخه متنی

4.6 Running a Secondary Name Server

You need to set up another
name server for robustness. You can (and
probably will) set up more than two name servers. Two servers are the
minimum. If you have only one name server and it goes down, no one
can look up names in your zone. A second name server splits the load
with the first server or handles the whole load if the first server
is down. You could set up another primary master
name server, but we don't recommend it. Set up a
secondary name server instead.

How does a server know if it is a primary master or a secondary for a
zone? The DNS server configuration information in the Registry tells
the server it is a primary master or a secondary on a per zone basis.
The NS records don't tell us which server is the
primary master for a zone and which servers are secondaries for a
zonethey only say who the servers are. (Globally, DNS
doesn't care; as far as the actual name resolution
goes, secondary servers are as good as primary master servers.)

What is different between a primary master name server and a
secondary name server? The crucial difference is where the server
gets its data. A primary master name server reads its data from
files. A secondary name server loads its data over the network from
another name server. This process is called a zone
transfer.

A secondary
name server is not limited to loading zones from a primary master
name server; a secondary can load from another secondary. The big
advantage of secondary name servers is that you maintain only one set
of zone datafiles: the ones on the primary master name server. You
don't have to worry about synchronizing the files
among name servers; the secondaries do that for you.

A secondary name server doesn't need to retrieve
all of its datafiles over the network; the
cache.dns file is the same as on a primary
master, so you'll need a local copy on the
secondary. Fortunately, the DNS server installation process includes
this file.

4.6.1 Add a New Server to the DNS Console

The first step in configuring a
secondary server is to add the server to the DNS
console's world view. Just as we did when
configuring the primary master, select Action Connect to DNS Server, then enter the name or
IP address of the secondary. In this case our secondary will be
wormhole with IP address 192.249.249.1. Of
course, the DNS server has to be installed and running on the
secondary-to-be for the DNS console to be able to manage it.

4.6.2 Create a New Zone

This new
server will be a secondary for every zone on the primary, so
we'll have to go through the new zone process for
each zone. Let's start with
movie.edu. Select Action New Zone. This time, select Secondary zone in the second window of the
wizard. In the third window, select Forward
lookup zone. The fourth window is shown in Figure 4-29.

Figure 4-29. Creating a new secondary zone: specifying the zone's domain name

In the Zone name field, enter the
domain name of the zone (in this case,
movie.edu). Click Next to move to the next window, shown in
Figure 4-30.

Figure 4-30. Creating a new secondary zone: specifying master servers

At this point, the processes of creating a primary master zone and a
secondary zone really diverge. This is the screen where you specify
where this name server will get the zone data. In this example,
we're making wormhole a
secondary for the movie.edu zone. We need to
tell wormhole to load the zone from
terminator, the primary master. In fact, on this
screen you can specify multiple IP addresses. In advanced (and
complicated) configurations, a secondary can sometimes get the zone
information from multiple primaries or multiple sources. The DNS
console supports those configurations. You could also just specify
the IP address of another secondary after that of the primary: in
case the primary is down, this secondary can load from another
secondary. Of course, Movie U. doesn't have another
secondary (yet).

For now, we just specify
terminator's IP address,
192.249.249.3, then click Next. The
final window in the process is the same as when creating a primary
zone: it just tells you that you're done now and
asks you to click Finish.
We'll omit showing it to you.

When you're done, the new secondary immediately
initiates a zone transfer to the primary to download the zone. Within
a few seconds you should be able to double-click the
secondary's icon for the zone and see the records in
the zone.

4.6.3 Add an NS Record for the New Secondary Name Server

Your
new secondary won't be much good if the rest of the
world doesn't know about it. As a general rule, when
you add another name server for a zone, you also need to add an NS
record for it. (We'll discuss the exceptions to this
in Chapter 9.)

You need to add an NS record for the secondary on the
zone's primary. (Remember that all changes to a zone
are made on the primary and propagate automatically to the
secondaries. Don't get confused by the fact that the
DNS console lets you see all your name serversyou make the
changes only to the zone's primary.) In our case, we
need to add an NS record for wormhole to the
movie.edu zone. So we click on
movie.edu under terminator
and select Action
Properties. Click on the Name Servers tab and you'll
see a window like the one in Figure 4-31.

Figure 4-31. NS records for the movie.edu zone

This window shows that right now there's only one NS
record for the movie.edu zone, which specifies
terminator.movie.edu as an authoritative name
server. To add another, click Add
and you'll see the window shown in Figure 4-32.

Figure 4-32. Adding an NS record

Enter the name and IP address of the secondary name server and click
OK.

4.6.4 Don't Forget the in-addr.arpa Zones!

Now repeat this secondary
zone creation process with the
249.249.192.in-addr.arpa and 253.
253.192.in-addr.arpa zones.

4.6.5 SOA Values

Remember this SOA record for the
movie.edu zone?

@                       IN  SOA terminator.movie.edu.  hostmaster.movie.edu. (
17           ; serial number
900          ; refresh
600          ; retry
86400        ; expire
3600       ) ; default TTL

We never explained what the values in between the parentheses were
for.

The serial number applies to all the data within the zone. Think of
it as a version number for the zone. When we created this zone with
the DNS console, the serial number began at 1. The DNS console
automatically increments the serial number in a
zone's SOA record whenever you make a change to the
zone. The current serial number of 17 shows we've
made a few changes since creating the zone. If you look at SOA
records from other zones, you might see the date encoded in the
serial numberfor example, 2000102301. This format is
YYYYMMDDNN, where YYYY is the year, MM is the month, DD is the day,
and NN is a count of how many times the zone data was modified that
day. Note that you can't use this convention with
the DNS console. It just increments the serial number by one each
time a change is made and doesn't understand the
date encoding.

When a secondary name server contacts a primary master server for
zone data, it first asks for the serial number of the data. If the
secondary's serial number is lower than the
primary's, the secondary's zone
data is out of date. In this case, the secondary pulls a new copy of
the zone. As you might guess, if you ever modify the zone datafiles
on the primary master by hand, you must increment the serial number,
too. Updating zone datafiles is covered in Chapter 7.

The next four fields specify various time intervals in seconds:

refresh

The refresh
interval tells the secondary how often to check that its data is up
to date. To give you an idea of the system load this feature causes,
a secondary will make one SOA query per zone per refresh interval.
The default value generated by the DNS console when the zone was
created, one hour, is reasonably aggressive. Most users will tolerate
a delay of half a working day for things like name server data to
propagate when they are waiting for their new workstation to be
operational. If you provide one-day service for your site, consider
raising this value to eight hours. If your data
doesn't change very often, or if all your
secondaries are spread over long distances (as the root name servers
are), consider a longer value, such as 24 hours.

retry

If a
secondary fails to reach the primary name server(s) after the refresh
period (the hosts or hosts could be down), it starts trying to
connect every retry seconds. The retry interval
is usually shorter than the refresh interval, but it
doesn't have to be.

expire

If a secondary
fails to contact the primary server(s) for
expire seconds, the secondary expires its data.
Expiring the data means the secondary stops giving out answers about
the data because the data is too old to be useful. Essentially, this
field says: at some point, the data is so old that having no data is
better than having stale data. We think Microsoft's
default expire time of 86,400 seconds (24 hours) is awfully short.
Expire times on the order of a week are common, and the interval can
be longer (up to a month) if you frequently have problems reaching
your updating source. The expiration time should always be much
larger than the retry and refresh intervals; if the expire time is
smaller than the refresh interval, your secondaries will expire their
data before trying to load new data.

default TTL

TTL
stands for time to live. This value applies to all the resource
records in the zone datafile. The name server supplies this TTL in
query responses, allowing other servers to cache the data for the TTL
interval. If your data doesn't change much, you
might consider using a minimum TTL of several days. One week is about
the longest value that makes sense. The default value of 3,600
seconds (one hour) is very short, which we don't
recommend because of the amount of DNS traffic it causes.

What values you choose for your SOA record will depend upon the needs
of your site. In general, longer times cause less loading on your
systems and lengthen the propagation of changes; shorter times
increase the load on your systems and speed up the propagation of
changes. We find the following values work well for most sites;
they're also a good starting point if
you're not sure what values to use:

       10800 ;  Refresh         3 hours
3600 ;  Retry           1 hour
2592000 ;  Expire         30 days
86400 ;  Minimum TTL     1 day

Some final notes about TTL values. First, the DNS console only
displays TTL values on individual records if you're
in advanced mode. Check out the setting on the View menu. Second, the DNS console displays
TTLs in a somewhat cryptic fashion. Take a look back at the NS record
we added in Figure 4-32. Notice the TTL specified as
0: 1: 0: 0. "What
the heck is that?" you ask. Well, the first field is
days, then hours, minutes, and seconds. So rather than display a
value in seconds and make you do the math, the DNS console
lets

you
specify a TTL in a more convenient way.