Solving Other Common DNS Problems

  • Article

This section lists several common DNS problems and explains how to solve them.

Event ID 7062 appears in the event log.

If you see event ID 7062 in the event log, the DNS server has sent a packet to itself. This is usually caused by a configuration error. Check the following:

  • Make sure that there is no lame delegation for this server. A lame delegation occurs when one server delegates a zone to a server that is not authoritative for the zone.

  • Check the forwarders list to make sure that it does not list itself as a forwarder

  • If this server includes secondary zones, make sure that it does not list itself as a master server for those zones.

  • If this server includes primary zones, make sure that it does not list itself in the notify list.

Zone transfers to secondary servers that are running BIND are slow.

By default, the Windows 2000 DNS server always uses a fast method of zone transfer. This method uses compression and includes multiple resource records in each message, substantially increasing the speed of zone transfers. Most DNS servers support fast zone transfer. However, BIND 4.9.4 and earlier does not support fast zone transfer. This is unlikely to be a problem, because when the Windows 2000 DNS Server service is installed, fast zone transfer is disabled by default. However, if you are using BIND 4.9.4 or earlier, and you have enabled fast zone transfer, you need to disable fast zone transfer.

To disable fast zone transfer

  1. In the DNS console, right-click the DNS server, and then click Properties .

  2. Click the Advanced tab.

  3. In the Server options list, select the Bind secondaries check box, and then click OK .

You see the error message "Default servers are not available."

When you start Nslookup, you might see the following error message:

*** Can't find server name for address <address> : Non-existent domain

*** Default servers are not available

Default Server: Unknown

Address: 127.0.0.1

If you see this message, your DNS server is still able to answer queries and host Active Directory. The resolver cannot locate the PTR resource record for the name server that it is configured to use. The properties for your network connection must specify the IP address of at least one name server, and when you start Nslookup, the resolver uses that IP address to look up the name of the server. If the resolver cannot find the name of the server, it displays that error message. However, you can still use Nslookup to query the server.

To solve this problem, check the following:

  • Make sure that a reverse lookup zone that is authoritative for the PTR resource record exists. For more information about adding a reverse lookup zone, see "Adding a Reverse Lookup Zone" earlier in this chapter.

  • Make sure that the reverse lookup zone includes a PTR resource record for the name server.

  • Make sure that the name server you are using for your lookup can query the server that contains the PTR resource record and the reverse lookup zone either iteratively or recursively.

User entered incorrect data in zone.

For information about how to add or update records by using the DNS console, see Windows 2000 Server Help. For more information about using resource records in zones, search for the keywords "managing" and "resource records" in Windows 2000 Server Help.

Active Directory-integrated zones contain inconsistent data.

For Active Directory–integrated zones, it is also possible that the affected records for the query have been updated in Active Directory but not replicated to all DNS servers that are loading the zone. By default, all DNS servers that load zones from Active Directory poll Active Directory at a set interval — typically, every 15 minutes — and update the zone for any incremental changes to the zone. In most cases, a DNS update takes no more than 20 minutes to replicate to all DNS servers that are used in an Active Directory domain environment that uses default replication settings and reliable high-speed links.

User cannot resolve name that exists on a correctly configured DNS server.

First, confirm that the name was not entered in error by the user. Confirm the exact set of characters entered by the user when the original DNS query was made. Also, if the name used in the initial query was unqualified and was not the FQDN, try the FQDN instead in the client application and repeat the query. Be sure to include the period at the end of the name to indicate the name entered is an exact FQDN.

If the FQDN query succeeds and returns correct data in the response, the most likely cause of the problem is a misconfigured domain suffix search list that is used in the client resolver settings.

Name resolution to Internet is slow, intermittent, or fails.

If queries destined for the Internet are slow or intermittent, or you cannot resolve names on the Internet, but local Intranet name resolution operates successfully, the cache file on your Windows 2000–based server might be corrupt, missing, or out of date. You can either replace the cache file with an original version of the cache file or manually enter the correct root hints into the cache file from the DNS console. If the DNS server is configured to load data on startup from Active Directory and the registry, you must use the DNS console to enter the root hints.

To enter root hints in the DNS console

  1. In the DNS console, double-click the server to expand it.

  2. Right-click the server, and then click Properties .

  3. Click the Root Hints tab.

  4. Enter your root hints, and then click OK .

To replace your cache file

  1. Stop the DNS service by typing the following at the command prompt:
    net stop dns

  2. Type the following:
    cd % Systemroot % \System32\DNS

  3. Rename your cache file by typing the following:
    ren cache.dns cache.old

  4. Copy the original version of the cache file, which might be found in one of two places, by typing either of the following:
    copy backup\cache.dns
    – Or –
    copy samples\cache.dns

  5. Start the DNS service by typing the following:
    net start dns

If name resolution to the Internet still fails, repeat the procedure, copying the cache file from your Windows 2000 source media.

To copy the cache file from your Windows   2000 source media

  • At the command prompt, type the following:
    expand <drive>:\i386\cache.dn_ % Systemroot % \system32\dns\cache.dns
    where drive is the drive that contains your Windows 2000 source media.

Resolver does not take advantage of round robin feature.

Windows 2000 includes subnet prioritization, a new feature, which reduces network traffic across subnets. However, it prevents the resolver from using the round robin feature as defined in RFC 1794. By using the round robin feature, the server rotates the order of A resource record data returned in a query answer in which multiple resource records of the same type exist for a queried DNS domain name. However, if the resolver is configured for subnet prioritization, the resolver reorders the list to favor IP addresses from networks to which they are directly connected.

If you would prefer to use the round robin feature rather than the subnet prioritization feature, you can do so by changing the value of a registry entry. For more information about configuring the subnet prioritization feature, see "Configuring Subnet Prioritization" earlier in this chapter.

WINS Lookup record causes zone transfer to a third-party DNS server to fail.

If a zone transfer from a Windows 2000 server to a third-party DNS server fails, check whether the zone includes any WINS or WINS-R records. If it does, you can prevent these records from being propagated to a secondary DNS server.

To prevent propagation of WINS lookup records to a secondary DNS server

  1. In the DNS console, double-click your DNS server, right-click the zone name that contains the WINS record, and then click Properties .

  2. In the Properties dialog box for the zone, click the WINS tab and select the check box Do not replicate this record.

To prevent propagation of WINS-R records to a secondary DNS server

  1. In the DNS console, double-click your DNS server, right-click the reverse lookup zone that contains the WINS-R record, and then click Properties .

  2. In the properties page for the zone, click the WINS-R tab and select the check box Do not replicate this record .

WINS lookup record causes a problem with authoritative data.

If you have a problem with incorrect authoritative data in a zone for which WINS lookup integration is enabled, the erroneous data might be caused by WINS returning incorrect data. You can tell whether WINS is the source of the incorrect data by checking the TTL of the data in an Nslookup query. Normally, the DNS service answers with names stored in authoritative zone data by using the set zone or resource record TTL value. It generally answers only with decreased TTLs when providing answers based on non-authoritative, cached data obtained from other DNS servers during recursive lookups.

However, WINS lookups are an exception. The DNS server represents data from a WINS server as authoritative but stores the data in the server cache only, rather than in zones, and decreases the TTL of the data.

To determine whether data comes from a WINS server

  1. At the command prompt, type the following:
    nslookup -d2
    server < server>
    where <server> is a server that is authoritative for the name that you want to test.
    This starts nslookup in user-interactive, debug mode and makes sure that you are querying the correct server. If you query a server that is not authoritative for the name that you test, you are not able to tell whether the data comes from a WINS server.

  2. To test for a WINS forward lookup, type the following:
    set querytype=a
    – Or –
    To test for a WINS reverse lookup, type the following:
    set querytype=ptr

  3. Enter the forward or reverse DNS domain name that you want to test.

  4. In the response, note whether the server answered authoritatively or non-authoritatively, and note the TTL value.

  5. If the server does not answer authoritatively, the source of the data is not a WINS server. However, if the server answered authoritatively, repeat a second query for the name.

  6. In the response, note whether the TTL value decreased. If it did, the source of the data is a WINS server.

If you have determined that the data comes from a WINS server, check the WINS server for problems. For more information about checking the WINS server for problems, see "Windows Internet Name Service" in this book.

A zone reappears after you delete it.

In some cases, when you delete a secondary copy of the zone, it might reappear. If you delete a secondary copy of the zone when an Active Directory-integrated copy of the zone exists in Active Directory, and the DNS server from which you delete the secondary copy is configured to load data on startup from Active Directory and the registry, the zone reappears.

If you want to delete a secondary copy of a zone that exists in Active Directory, configure the DNS server to load data on startup from the registry, and then delete the zone from the DNS server that is hosting the secondary copy of the zone. Alternatively, you can completely delete the zone from Active Directory when you are logged into a domain controller that has a copy of the zone.

You see error messages stating that PTR records could not be registered

When the DNS server that is authoritative for the reverse lookup zone cannot or is configured not to perform dynamic updates, the system records errors in the event log stating that PTR records could not be registered. You can eliminate the event log errors by disabling dynamic update registration of PTR records on the DNS client. To disable dynamic update registration, add the DisableReverseAddressRegistrations entry, with a value of 1 and a data type of REG_DWORD, to the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \Tcpip\Parameters\Interfaces\< name of theinterface >

where name of the interface is the GUID of a network adapter.