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

15.4 Potential Problem List

Let's go through some common real-world DNS
problems. Many of these problems are easy to recognize and correct.
We cover these problems as a matter of
coursethey're some of the most common
problems because they're caused by some of the most
common mistakes. Here are the contestants, in no particular order.

15.4.1 1. Forget to Increment Serial Number

This particular problem occurs only if
you make changes to your zone datafile by hand, without using the DNS
console. The DNS console remembers to increment the serial number in
the SOA record each time it changes zone data, so you
don't have to worry about it. However, this also
means that you probably won't be in the habit of
updating the serial number, so you may forget when making that
one-off manual modification.

The main symptom of this problem is that secondary name servers
don't pick up any changes you make to the zone on
the primary server. The secondaries think the zone data
hasn't changed since the serial number is still the
same.

How do you check if you remembered to increment the serial number?
Unfortunately, that's not so easy. If you
don't remember what the old serial number was and
your serial number gives you no indication of when it was updated,
there's no direct way to tell whether it has
changed.^[1] When
you start the primary, it loads the updated zone datafile regardless
of whether you've changed the serial number. About
the best you can do is to use nslookup to
compare the data returned by the primary and by a secondary. If they
return different data, you probably forgot to increment the serial
number. If you can remember a recent change you made, you can look
for that data. If you can't remember a recent
change, you can try transferring the zone from a primary and from a
secondary, sorting the results, and using a file-comparison tool to
compare them.

^[1] On the other hand, if you encode the date
into the serial number, as many people do (for example, 2004010500 is
the first rev of data on January 5, 2004), you may be able to tell at
a glance whether you updated the serial number when you made the
change. However, the DNS console makes this almost impossible since
it just increments by one for each change.

The good news is that, although determining whether the zone was
transferred is tricky, making sure the zone is transferred is simple.
Just increment the serial number on the primary's
copy of the zone by double-clicking the SOA record in the DNS console
and clicking the Increment button on
the Start of Authority (SOA) tab.
The secondaries should pick up the new data within their refresh
interval, or sooner if they use NOTIFY.

15.4.2 2. Forget to Restart Primary Master Server

Like
the last problem,
you'll see this problem only if you make changes to
your zone datafiles by hand. The DNS console adds and deletes data on
the fly, so there's no need to restart your primary
master name server.

If you're not using the DNS console, though, you may
forget to restart your primary master name server after editing a
zone datafile. The name server won't know to load
the new datait doesn't automatically check
the file to see if it has changed. Consequently, any changes
you've made won't be reflected in
the name server's data: new zones
won't be loaded, and new records
won't percolate out to the secondaries.

To check when you last restarted the name server, use the Event
Viewer to scan the DNS Server event log for Event ID 2, which
contains the following text:

The DNS server has started.

The date and time on these events tell you the last time you
restarted the name server.

If the time of the restart doesn't correlate with
the time you made the last change, use the DNS console to stop and
restart the name server and reload its data. Check that you
incremented the serial numbers on the zone datafiles you changed,
too.

15.4.3 3. Name Server Loses Manual Changes

One final but important note about
making manual changes: remember that the Microsoft DNS Server
periodically updates its zone datafiles. Each time you make changes
to a zone's data using the DNS console, a write is
pending: before the name server exits, it must rewrite the
zone's datafile or it will lose the changes you
made. Think of this as a dirty page in memory: the operating system
must write it to disk before exiting.

If you make a manual change to a zone datafile while a write is
pending, you'll mysteriously lose the change when
the name server exits. Say you add delegation to a new subdomain of
movie.edu while the server is running and a
write is pending. After you've made the change, you
have to stop the server and start it again to get it to read the zone
data again. But as the server exits, it rewrites the
movie.edu zone datafile, and your delegation
disappears. If you're watching the DNS Server event
log carefully (like you should be), you'll see a
message like this before the server stops:

The DNS server wrote version 37 of zone movie.edu to file movie.edu.dns.

Once you force the server to rewrite its zone datafiles with
Action Update Server Data Files, the server is in
sync with the zone datafiles and doesn't have to
rewrite them on exit. So, if you're going to make
manual changes to the zone datafiles, you should either stop the
server first (although that means your server won't
answer queries while you make the change), or use the DNS console to
sync the server with the zone datafiles and then make the
change.

15.4.4 4. Secondary Server Can't Load Zone Data

If a secondary name server
can't get the current serial number for a zone from
its master server, you won't be warned about it
initially. However, if the problem persists and the secondary
can't determine within the expire interval whether
or not its data is up to date, it expires the zone. On a Microsoft
DNS Server, you'll see a message like this in the
DNS Server event log:

Zone movie.edu expired before it could obtain a successful zone transfer or update 
from a master server acting as its source for the zone.
The zone has been shut down.

Once the zone has expired and the name server has shut it down,
you'll start getting Query
refused errors when you query the name server for data in
the zone:

C:\> nslookup robocop wormhole.movie.edu. 
Server:  wormhole.movie.edu 
Addresses:  192.249.249.1, 192.253.253.1 
*** wormhole.movie.edu can't find robocop.movie.edu: Query refused

Three leading causes of this problem
are a loss in connectivity to the master server due to network
failure, an incorrect IP address configured for the master server,
and a syntax error in the zone datafile on the master server.

First, use the DNS console to check the address of the master
server(s) from which the secondary is attempting to load data.
Right-click the domain name of the zone in the left pane, choose
Properties, and look at the
General tab, shown in Figure 15-3.

Figure 15-3. Zone properties window showing master server(s)

Make sure that's really the IP address of the master
name server. If it is, check connectivity to that IP address:

C:\> ping 192.249.249.3 
Pinging 192.249.249.3 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

If the master server isn't reachable, make sure that
the server's host is really running (for example, is
powered on) or look for a network problem.

You may also want to check that the master server is returning
authoritative responses to queries for data in the zone. If the
master server is responding as not authoritative for the zone, the
secondary won't transfer the zone from it.
Here's how you could use
nslookup to check for an authoritative response
for the zone's SOA record from the master server:

C:\> nslookup -norec -type=SOA movie.edu. 192.249.249.3

This command sends a nonrecursive query for the SOA record for
movie.edu to the name server at 192.249.249.3.
We need to send a nonrecursive query so that the name server at
192.249.249.3 doesn't try to forward the query to
another server.

If this master server is correctly configured, the answer to this
query should be authoritative. (Remember that unless
nslookup reports
"Non-authoritative answer," the
answer is authoritative.) A nonauthoritative reply may indicate that
the master server had a problem loading the zone, usually because of
a syntax error in the zone datafile. We've never
seen a Microsoft DNS Server go nonauthoritative for a zone based on a
syntax error in a zone datafile, but older BIND name servers exhibit
this behavior. So if your name server is a secondary to a zone whose
primary master is a BIND name server that's not
claiming authority for the zone, a syntax error could be your
problem. Contact the administrator of the master server and have him
check his name server's syslog
output for indications of a syntax error.

If the answer to the query is authoritative but the secondary server
still can't transfer the zone successfully, you can
use the nslookup's
ls command to try to transfer the zone manually
(ls, as we said in Chapter 12,
performs a zone transfer). If you see an error like this,
it's a good bet that the master server restricts
zone transfers:

C:\> nslookup - 192.249.249.3
Default Server:  terminator.movie.edu
Address:  192.249.249.3
> ls movie.edu
[terminator.movie.edu]
*** Can't list domain movie.edu: Query refused
>

Contact the administrator of the master server and ask whether he is
restricting zone transfers. Ask him to check the options on the
Zone Transfers tab of the Properties window for the zone
you're trying to transfer (if he's
running the Microsoft DNS Server). If the remote server is running
BIND, ask if he's using the
xfrnets or allow-transfer
features to restrict zone transfers.

Once the problem has been cleared up and your server successfully
transfers the zone, you'll see messages like these
in the DNS Server event log:

A more recent version, version 212 of zone movie.edu was found at DNS server at 
192.249.249.3. Zone transfer is in progress.
The DNS server wrote version 212 of zone movie.edu to file movie.edu.dns.

15.4.5 5. Add Address to Zone, but Forget to Add Corresponding PTR Record

Because
the mappings from hostnames to IP addresses are disjointed from the
mappings from IP addresses to hostnames in DNS, it's
easy to forget to add a PTR record for a new host. Adding the A
record is intuitive, but many people who are used to host tables
assume that adding an address record takes care of the reverse
mapping, too. That's not trueyou need to add
a PTR record for the host to the appropriate
in-addr.arpa zone. Thankfully, the DNS console
makes that easy by providing a checkbox to Create associated pointer (PTR) record when
you choose New Host.

Neglecting to add the PTR record for a host usually causes that host
to fail authentication checks. For example, users on the host
won't be able to ssh or
scp to other hosts. The servers these programs
talk to need to be able to map the connection's IP
address to a domain name to check authorization files.

In addition, some large FTP archives, including
ftp.uu.net, used to refuse anonymous
ftp access to hosts whose IP addresses
don't map back to domain names.
ftp.uu.net's FTP server emitted
a message that read, in part:

530- Sorry, we're unable to map your IP address 140.186.66.1 to a hostname 
530- in the DNS. This is probably because your nameserver does not have a 
530- PTR record for your address in its tables, or because your reverse 
530- nameservers are not registered. We refuse service to hosts whose 
530- names we cannot resolve.

That made the reason you couldn't use anonymous
ftp pretty evident. Other FTP sites, however,
didn't bother printing informative messages; they
simply denied service.

nslookup is handy for checking whether or not
you've forgotten the PTR record:

C:\> nslookup  
Default Server:  terminator.movie.edu 
Address:  192.249.249.3 
> beetlejuice         Check for a hostname-to-address mapping. 
Server:  terminator.movie.edu 
Address:  192.249.249.3 
Name:    beetlejuice.movie.edu 
Address:  192.249.249.23 
> 192.249.249.23      Now check for a corresponding address-to-hostname mapping. 
Server:  terminator.movie.edu 
Address:  192.249.249.3 
*** terminator.movie.edu can't find 192.249.249.23: Non-existent domain

On the primary master for
249.249.192.in-addr.arpa, a quick check of the
DNS console or the 249.249.192.in-addr.arpa.dns
file tell you whether the PTR record has been added to the zone yet.

15.4.6 6. Wrong Domain Name in RDATA of Record

When you
add CNAME, MX, and NS records with the DNS console, remember to
specify the fully qualified domain name of the host for the resource
record-specific data. The DNS console assumes that the name you type
as the RDATA field is fully qualified.
So if you try to create a CNAME record as shown in Figure 15-4, the CNAME record looks like this in the zone
datafile:

bigt    IN  NS  terminator.

This is probably not what you intended, since
there's no top-level terminator
domain. You probably assumed the DNS console would append the name of
the zone to the name if you left off the dot. Nope.

Figure 15-4. Creating a CNAME record (the wrong way)

These mistakes are easy to discover if you simply examine the zone
datafile (after Action
Update Server Data
Files) or use nslookup:

C:\> nslookup -type=cname bigt.movie.edu. 
Server:  terminator.movie.edu 
Address:  192.249.249.3 
bigt.movie.edu  canonical name = terminator

15.4.7 7. Loss of Network Connectivity

Though the Internet is more
reliable


today than it was back in the wild and woolly days of the ARPANET,
network outages are still relatively common. These failures usually
look like poor performance:

C:\> nslookup nisc.sri.com. 
Server:  terminator.movie.edu 
Address:  192.249.249.3 
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 4 seconds.
DNS request timed out.
timeout was 8 seconds.
*** Request to terminator.movie.edu timed-out

Using nslookup, you can look
up the names and addresses of the name servers your name server needs
to talk to in order to resolve the name:

C:\> nslookup
Default Server:  terminator.movie.edu
Address:  192.249.249.3
> set type=ns
> sri.com.
Server:  terminator.movie.edu
Address:  192.249.249.3
Non-authoritative answer:
sri.com nameserver = ns.sri.com
sri.com nameserver = nsf.algx.net
sri.com nameserver = ns1.sri.com
ns.sri.com      internet address = 128.18.30.66
ns1.sri.com     internet address = 128.18.30.65
> com.
Server: terminator.movie.edu
Address:  192.249.249.3
Non-authoritative answer:
com     nameserver = j.gtld-servers.net
com     nameserver = k.gtld-servers.net
com     nameserver = l.gtld-servers.net
com     nameserver = m.gtld-servers.net
com     nameserver = a.gtld-servers.net
com     nameserver = b.gtld-servers.net
com     nameserver = c.gtld-servers.net
com     nameserver = d.gtld-servers.net
com     nameserver = e.gtld-servers.net
com     nameserver = f.gtld-servers.net
com     nameserver = g.gtld-servers.net
com     nameserver = h.gtld-servers.net
com     nameserver = i.gtld-servers.net

Then you can check your host's connectivity to those
servers. Odds are, ping won't
have much better luck than your name server did. If it does, you
should check that the remote name servers are really running:

C:\> ping 128.18.30.66           Ping first sri.com name server.
Pinging 128.18.30.66 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
C:\> ping 128.18.30.65           Ping second sri.com name server.
Pinging 128.18.30.65 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Now all
that's left to do is to locate the break in the
network. Utilities like tracert and
pathping can help you determine whether the
problem is on your network, on the destination network, or somewhere
in the middle.

You should also use common sense when tracking down the break. If,
for example, your ping testing showed that you
couldn't reach any of the
Internet's root name servers, it's
not likely that each root's local network went down
or that the Internet's commercial backbone networks
collapsed entirely. Occam's razor says that the
simplest condition that could cause this behaviornamely, the
loss of your network's link to
the Internetis the most likely cause.

15.4.8 8. Missing Subdomain Delegation

Even
though registrars do their best to process requests as quickly as
possible, it may take some time for your subdomain's
delegation to appear in the parent zone's name
servers. If your parent zone isn't one of the
generic top-level domains, your mileage may vary. Some parents are
quick and responsive; others are slow and inconsistent. Just like in
real life, though, you're stuck with them.

Until your delegation data appears in your parent
zone's name servers, your name servers can look up
data in the Internet domain namespace, but no one else on the
Internet (outside of your domain) will know how to look up data in
your namespace.

That means that even though you can send mail outside of your domain,
the recipients won't be able to reply to it.
Furthermore, no one can telnet to,
ftp to, or even ping your
hosts by name.

Remember that this applies equally to any
in-addr.arpa subdomains you may run. Until the
parent delegates those subdomains to your servers, name servers on
the Internet won't be able to reverse-map addresses
on your networks.

To
determine whether or not your zone's delegation has
made it into your parent zone's name servers, query
a parent name server for the NS records for your zone. If the parent
name server has the data, any name server on the Internet can find
it:

 C:\> nslookup   
Default Server:  terminator.movie.edu 
Address:  192.249.249.3 
> server arrowroot.arin.net.         Query a 192.in-addr.arpa name server. 
Default Server:  arrowroot.arin.net 
Address:  198.133.199.110 
> set norecurse                      Instruct the server to answer out of
> set type=ns                        its own data and to look for NS records 
> 249.249.192.in-addr.arpa.          for 249.249.192.in-addr.arpa.
Server:  arrowroot.arin.net 
Address:  198.133.199.110 
*** arrowroot.arin.net can't find 249.249.192.in-addr.arpa.: Non-existent domain

Here, the delegation clearly hasn't been added yet.
You can either wait patiently, or if an unreasonable amount of time
has passed since you requested delegation from your parent zone, you
can contact your parent zone's administrator and ask
what's up.

15.4.9 9. Incorrect Subdomain Delegation

Incorrect
subdomain delegation is another familiar problem on the Internet.
Keeping delegation up-to-date requires human
interventioninforming your parent zone's
administrator of changes to your set of authoritative name servers.
Consequently, delegation information often becomes inaccurate as
administrators make changes without letting their parents know. Far
too many administrators believe that setting up delegation is a
one-shot deal: they let their parents know which name servers are
authoritative once, when they set up their zones, and then they never
talk to them again. They don't even call on
Mother's Day.

An administrator may add a new name server, decommission another, and
change the IP address of a third, all without telling the parent
zone's administrator. Gradually, the number of name
servers correctly delegated to by the parent zone dwindles. In the
best case this leads to long resolution times, as querying name
servers struggle to find an authoritative name server for the zone.
If the delegation information becomes badly out of date and the last
authoritative name server host is brought down for maintenance, the
information within the zone becomes inaccessible.

If you
suspect bad delegation, whether from your parent to your zone, from
your zone to one of your children, or from a remote zone to one of
its children, you can check with nslookup:

C:\> nslookup  
Default Server:  terminator.movie.edu 
Address:  192.249.249.3 
> server a.gtld-servers.net.          Set server to the parent name server you suspect has bad delegation. 
Default Server:  a.gtld-servers.net 
Address:  198.41.0.4 
> set type=ns          Look for NS records 
> hp.com.              for the zone in question. 
Server:  a.gtld-servers.net 
Address:  198.41.0.4 
Non-authoritative answer: 
hp.com          nameserver = RELAY.HP.COM 
hp.com          nameserver = HPLABS.HPL.HP.COM 
hp.com          nameserver = NNSC.NSF.NET 
hp.com          nameserver = HPSDLO.SDD.HP.COM 
Authoritative answers can be found from: 
hp.com          nameserver = RELAY.HP.COM 
hp.com          nameserver = HPLABS.HPL.HP.COM 
hp.com          nameserver = NNSC.NSF.NET 
hp.com          nameserver = HPSDLO.SDD.HP.COM 
RELAY.HP.COM    internet address = 15.255.152.2 
HPLABS.HPL.HP.COM       internet address = 15.255.176.47 
NNSC.NSF.NET            internet address = 128.89.1.178 
HPSDLO.SDD.HP.COM       internet address = 15.255.160.64 
HPSDLO.SDD.HP.COM       internet address = 15.26.112.11

Let's say you suspect that the delegation to
hpsdlo.sdd.hp.com is incorrect. Query
hpsdlo for data in the
hp.com zone, and check the answer:

> server hpsdlo.sdd.hp.com. 
Default Server:  hpsdlo.sdd.hp.com 
Addresses:  15.255.160.64, 15.26.112.11 
> set norecurse 
> set type=soa 
> hp.com. 
Server:  hpsdlo.sdd.hp.com 
Addresses:  15.255.160.64, 15.26.112.11 
Non-authoritative answer: 
hp.com 
origin = relay.hp.com 
mail addr = hostmaster.hp.com 
serial = 1001462 
refresh = 21600 (6 hours) 
retry   = 3600 (1 hour) 
expire  = 604800 (7 days) 
minimum ttl = 86400 (1 day) 
Authoritative answers can be found from: 
hp.com          nameserver = RELAY.HP.COM 
hp.com          nameserver = HPLABS.HPL.HP.COM 
hp.com          nameserver = NNSC.NSF.NET 
RELAY.HP.COM    internet address = 15.255.152.2 
HPLABS.HPL.HP.COM       internet address = 15.255.176.47 
NNSC.NSF.NET    internet address = 128.89.1.178

If hpsdlo really were authoritative, it would
have responded with an authoritative answer. The administrator of the
hp.com zone can tell you whether
hpsdlo should be an authoritative name server
for hp.com, so that's who you
should contact.

Checking delegation is even easier with DNSLint,
which we introduced in Chapter 8. To check
hp.com's delegation, we could
have run just:

C:\> dnslint /d hp.com