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 course—they'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 data—it 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 true—you 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 behavior—namely, the loss of your network's link to the Internet—is 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 intervention—informing 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