Frequently asked questions about Windows 2000 DNS and

Windows Server 2003 DNS

SUMMARY
This article describes DNS functionality in Windows 2000 and Windows Server 2003, and provides
answers to frequently asked questions about Windows 2000 and Windows Server 2003 DNS.

MORE INFORMATION
DNS is the backbone of Active Directory and the primary name resolution mechanism of Windows
2000 and Windows Server 2003. Windows 2000 and Windows Server 2003 domain controllers
dynamically register information about themselves and about Active Directory in DNS. Other
Windows 2000 and Windows Server 2003 domain controllers, servers, and workstations that are part
of the domain query DNS to find Active Directory-related information. If DNS is not set up correctly,
domain-wide issues can occur such as replication between domain controllers. You may also be
unable to log on to the domain or to join the domain from a workstation or server.

Question: What are the common mistakes that are made when administrators set up DNS on
network that contains a single Windows 2000 or Windows Server 2003 domain controller?

Answer: The most common mistakes are:

• The domain controller is not pointing to itself for DNS resolution on all network interfaces.
• The "." zone exists under forward lookup zones in DNS.
• Other computers on the local area network (LAN) do not point to the Windows 2000 or Windows
Server 2003 DNS server for DNS.
Question: Why do I have to point my domain controller to itself for DNS?

Answer: The Netlogon service on the domain controller registers a number of records in DNS that
enable other domain controllers and computers to find Active Directory-related information. If the
domain controller is pointing to the Internet service provider's (ISP) DNS server, Netlogon does not
register the correct records for Active Directory, and errors are generated in Event Viewer. In
Windows Server 2003, the recommended DNS configuration is to configure the DNS client settings
on all DNS servers to use themselves as their own primary DNS server, and to use a different
domain controller in the same domain as their alternative DNS server, preferably another domain
controller in the same site. This process also works around the DNS "Island" problem in Windows
2000. You must always configure the DNS client settings on each domain controller's network
interface to use the alternative DNS server addresses in addition to the primary DNS server address.
Question: What does a domain controller register in DNS?

Answer: The Netlogon service registers all the SRV records for that domain controller. These
records are displayed as the _msdcs, _sites, _tcp, and _udp folders in the forward lookup zone that
matches your domain name. Other computers look for these records to find Active Directory-related
information.

Question: Why can't I use WINS for name resolution like it is used in Microsoft Windows NT 4.0?

Answer: A Windows 2000 or Windows Server 2003 domain controller does not register Active
Directory-related information with a WINS server; it only registers this information with a DNS server
that supports dynamic updates such as a Windows 2000 or Windows Server 2003 DNS server. Other
Windows 2000-based and Windows Server 2003-based computers do not query WINS to find Active
Directory-related information.

Question: If I remove the ISP's DNS server settings from the domain controller, how does it resolve
names such as Microsoft.com on the Internet?

Answer: As long as the "." zone does not exist under forward lookup zones in DNS, the DNS service
uses the root hint servers. The root hint servers are well-known servers on the Internet that help all
DNS servers resolve name queries.

Question: What is the "." zone in my forward lookup zone?

Answer: This setting designates the Windows 2000 or Windows Server 2003 DNS server to be a root
hint server and is usually deleted. If you do not delete this setting, you may not be able to perform
external name resolution to the root hint servers on the Internet.

For additional information, click the article number below to view the article in the Microsoft
Knowledge Base:
229840 DNS Server's Root Hints and Forwarder Pages Are Unavailable
Question: Do I need to configure forwarders in DNS?

Answer: No. By default, Windows 2000 and Windows Server 2003 DNS use the root hint servers on
the Internet; however, you can configure forwarders to send DNS queries directly to your ISP's DNS
server or other DNS servers. In most cases, when you configure forwarders, DNS performance and
efficiency increases, but this configuration can also introduce a point of failure if the forwarding DNS
server is experiencing problems. The root hint server can provide a level of redundancy in exchange
for slightly increased DNS traffic on your Internet connection.

Question: Should I point the other Windows 2000-based and Windows Server 2003-based
computers on my LAN to my ISP's DNS servers?

Answer: No. If a Windows 2000-based or Windows Server 2003-based server or workstation does
not find the domain controller in DNS, you may experience issues joining the domain or logging on
to the domain. A Windows 2000-based or Windows Server 2003-based computer's preferred DNS
setting should point to the Windows 2000 or Windows Server 2003 domain controller running DNS. If
you are using DHCP, make sure that you view scope option #15 for the correct DNS server settings
for your LAN.

Question: Do I need to point computers that are running Windows NT 4.0 or Microsoft Windows 95,
Microsoft Windows 98, or Microsoft Windows 98 Second Edition to the Windows 2000 or Windows
Server 2003 DNS server?

Answer: Legacy operating systems continue to use NetBIOS for name resolution to find a domain
controller; however it is recommended that you point all computers to the Windows 2000 or
Windows Server 2003 DNS server for name resolution.

Question: What if my Windows 2000 or Windows Server 2003 DNS server is behind a proxy server
or firewall?

Answer: If you are able to query the ISP's DNS servers from behind the proxy server or firewall,
Windows 2000 and Windows Server 2003 DNS server is able to query the root hint servers. UDP and
TCP Port 53 should be open on the proxy server or firewall.

Question: What should I do if the domain controller points to itself for DNS, but the SRV records still
do not appear in the zone?

Answer: Check for a disjointed namespace, and then run Netdiag.exe /fix. You must install
Support Tools from the Windows 2000 Server or Windows Server 2003 CD-ROM to run Netdiag.exe.

For additional information about checking for a disjointed namespace, click the article number below
to view the article in the Microsoft Knowledge Base:
257623 Domain Controller's DNS Suffix Does Not Match Domain Name
Question: How do I set up DNS for other domain controllers in the domain that are running DNS?

Answer: For each additional domain controller that is running DNS, the preferred DNS setting is the
parent DNS server (first domain controller in the domain), and the alternate DNS setting is the actual
IP address of network interface.

Question: How do I set up DNS for a child domain?

Answer: To set up DNS for a child domain, create a delegation record on the parent DNS server for
the child DNS server. Create a secondary zone on the child DNS server that transfers the parent
zone from the parent DNS server. Set the child DNS server to point to itself only.

For additional information, click the article number below to view the article in the Microsoft
Knowledge Base:
255248 How to Create a Child Domain in Active Directory and Delegate the DNS Namespace to the
Child Domain
DNS Server's Root Hints and Forwarder Pages Are
Unavailable
SYMPTOMS
Clients that use a DNS server may not be able to gain access to hosts on the Internet. When you try
to configure root hints or forwarders on the DNS server, the options for these items may be
unavailable.

CAUSE
A DNS server behaves as a root server if there is a zone named "." on the server. The "." zone
indicates that the server is a top-level root server. Because a root server is at the top of the DNS
hierarchy, it cannot be configured to forward and does not require root hints.

When you run the Active Directory Installation Wizard (Dcpromo.exe), you can configure a DNS
server on the local computer and configure the forward lookup zones. The wizard examines the
TCP/IP configuration on the computer and determines whether the computer is configured to use
any DNS servers. If so, the Active Directory Installation Wizard queries for the root servers. If the
computer is not configured to use any DNS servers, the wizard queries the root servers that are
listed in the Cache.dns file (the Internet root servers). If the wizard cannot contact any root servers,
it configures the local computer as a root server and creates the "." zone.

RESOLUTION
To resolve this issue:
1. Delete the "." zone by using DNS Manager, or type the following command at a command prompt:
dnscmd /ZoneDelete . /DsDel
Note The /DsDel switch is required only if the zone is integrated with Active Directory.
2. Right-click the DNS server name, and then click Refresh to refresh the screen. The root hints and
forwarders are now enabled.

The actual DNS request is being sent to the local DNS cache. If the entry is listed there, Windows
uses the entry and does not make the request to the DNS server. After the entry has timed out
(based on its Time to Live, or TTL value), it is cleared from the local DNS cache. The next attempt
sends the request to the DNS server.

To view the DNS cache, type ipconfig /displaydns at a command prompt.

To delete the entries in the DNS cache, type ipconfig /flushdns at a command prompt.

Windows 2000 DNS

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 the interface>

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

Windows 2000 DNS

Most failed name resolution attempts fail in one of two general ways:

 A user receives a negative response when attempting to resolve a name, such as an error message

indicating "name not found."

 A user receives a positive response when attempting to resolve a name, but the information returned is

incorrect.

Important

Whenever you are trying to troubleshoot problems with name resolution, always submit an FQDN. In that way, you can

make sure that your problem is not caused by an incorrect domain suffix appended to the queried name.

The following flowcharts and associated text in Figures 6.36–6.41 explain how to diagnose each of these problems. For

another good source of information for diagnosing common problems, see RFC 1912, "Common DNS Operational and

Configuration Errors."

Note

The flowcharts in Figures 6.36–6.41 direct you to other flowcharts in other figures. To locate the correct flow chart, see

the figure captions.

Figure 6.36 No Answer or Name Not Found
Figure 6.37 Answer Is Incorrect
Figure 6.38 Authoritative Data Is Incorrect
Figure 6.39 Recursion Problem
Figure 6.40 Zone Transfer Fails
Figure 6.41 Check Server for Problems

Cannot Find Name or IP Address

If a query fails because you get the response Non-existent domain from Nslookup or the response Unknown host

from Ping, the DNS server did not find the name or IP address that you are looking up. Use the following process, shown

in Figure 6.36, to help troubleshoot the problem:

1. Check that the client and server computers have a valid IP configuration.

To check IP configuration, type ipconfig /all at the command prompt. In the command-line output, verify the IP

address, subnet mask, and default gateway.

2. Check that the server is working properly. For more information about verifying that the server is working
properly, see "Checking the DNS Server for Problems" later in this chapter.

3. Check whether the DNS server is authoritative for the name that is being looked up.

If the DNS server is authoritative for the name that is being looked up, you probably have a problem with

authoritative data. For more information about checking for problems with authoritative data, see "Checking for

Problems with Authoritative Data" later in this chapter.

– Or –

If the DNS server is not authoritative for the name that is being looked up, proceed to the next step.

4. Query for the name by using Nslookup. At the command prompt, type the following:

Nslookup <query address> <IP address of server>

where IP address of server is the IP address of the server that you queried originally, and query address is the name

or IP address you are attempting to resolve. If you get the message "Server failed" or "Request to server timed out,"

you probably have a problem involving a broken delegation. For more information about problems with broken

delegations, see "Checking for Recursion Problems" later in this chapter.

– Or –

If you get an incorrect answer or the message "Non-existent domain," proceed to the next step.

5. Flush the resolver cache. At the command prompt, type the following:

Nslookup <query address> <IP address of server>

where IP address of server is the IP address of the server that you queried originally, and query address is the name

or IP address you are attempting to resolve. If the answer is correct, the problem was a stale cache entry, and your
 problem is solved.

– Or –

If the answer is still not correct, you probably have a problem with authoritative data. For more information about

problems with authoritative data, see "Checking for Problems with Authoritative Data" later in this chapter.

Incorrect Answer

If you query a DNS server and it responds with incorrect information, use the following process, shown in Figure 6.37, to

solve the problem.

1. Flush the resolver cache.

2. At the command prompt, type the following:

Nslookup <query address> <IP address of server>

where IP address of server is the IP address of the server that you queried originally, and query address is the name

or IP address you are attempting to resolve. If the answer is correct, the problem was a stale cache entry, and your

problem is solved.

– Or –

If the answer is still not correct, you probably have a problem with authoritative data. For more information about

how to diagnose problems with authoritative data, see "Checking for Problems with Authoritative Data" later in this

chapter.

Checking the DNS Server for Problems

Use the following process, shown in Figure 6.41, to check the DNS server for problems.

1. Check Event Viewer for error messages. For information about Event Viewer, see "Troubleshooting Tools"
earlier in this chapter.

2. Check for basic connectivity between the client computer and the DNS server that you used for your original
query by pinging the DNS server by its IP address.

If the DNS server does not respond to a direct ping of its IP address, you probably have a network connectivity

problem between the client and the DNS server.

3. At the command prompt on the client computer, type the following:

nslookup 127.0.0.1 <IP address of server>

 If the resolver returns the name of the local host, the server does not have any problems.

– Or –

If the resolver returns the response "Server failure," proceed to step 4.

– Or –

If the resolver returns the response "Request to server timed out" or "No response from server," proceed to step 5.

4. If the resolver returns the response "Server failure," the zone 1.0.0.127.in-addr.arpa is probably paused, or the
server is possibly overloaded. You can find out whether it is paused by checking the General tab of the zone
properties, from within the DNS console.

5. If the resolver returns the response "Request to server timed out" or "No response from server," the DNS server
probably is not running. Try to restart the server by typing the following at the command prompt on the server:

net start DNS

– Or –

If it is running, the server might not be listening on the IP address that you used in your Nslookup query. From the

Interfaces tab of the server properties page in the DNS console, administrators can restrict a DNS server to listen

only on selected addresses. If the DNS server has been configured to limit service to a specific list of its configured

IP addresses, it is possible that the IP address used to contact the DNS server is not in the list. You can try a

different IP address in the list or add the IP address to the list. For more information about restricting a DNS server

to listen only on selected addresses, see Windows 2000 Help.

– Or –

In rare cases, the DNS server might be configured to disable the use of its automatically created default zones. By

default, the DNS service automatically creates the following standard reverse lookup zones based on RFC

recommendations:

 0.in-addr.arpa

 127.in-addr.arpa

 255.in-addr.arpa

The automatic creation of these zones can only be disabled through the registry, so it is unlikely that this has

happened. However, if you think automatic creation has been disabled, you can use the DNS console to make sure
 that the zones exist.

– Or –

In rare cases, the DNS server might have an advanced security or firewall configuration. If the server is located on

another network that is reachable only through an intermediate host (such as a packet filtering router or proxy

server), the DNS server might use a non-standard port to listen for and receive client requests. By default, Nslookup

sends queries to DNS servers on UDP port 53, so if the DNS server uses any other port, Nslookup queries fail. If you

think this might be the problem, check whether an intermediate filter is intentionally used to block traffic on well-

known DNS ports. If not, try to modify the packet filters or port rules on the firewall to allow traffic on UDP/TCP port

53.

Diagnosing Problems with Incorrect Authoritative Data

If you have determined that the server contains incorrect authoritative (non-cached) data, use the following process to

help troubleshoot the problem:

1. Determine whether the server that is returning the incorrect response is either a primary or secondary server
for the zone.

If the server is a primary server for the zone — either the standard primary server for the zone or a server that uses

Active Directory integration to load the zone — the data is incorrect on the primary zone. Go to step 5.

– Or –

If the server is hosting a secondary copy of the zone, proceed to the next step.

2. Examine the zone on the master server (the server from which this server pulls zone transfers). You can
determine which server is the master server by examining the properties of the secondary zone in the DNS console.
Is the name correct on the master server?

If the name is not correct on the master server, go to step 1. When prompted to examine a server, examine the

server from which this server pulls zone transfers.

– Or –

If the name was correct on the master server, proceed to the next step.

3. Check whether the serial number on the master server is lower than or equal to the serial number on the
secondary server. If not, proceed to the next step.
 – Or –

If the serial number on the master server is lower than or equal to the serial number on the secondary server,

modify either the master server or the secondary server so that the serial number on the master server is higher

than the serial number on the secondary server. Then, proceed to the next step.

4. Force a zone transfer from within the DNS console. (For information about how to force a zone transfer, see
Windows 2000 Server Help.) Next, examine the secondary server again to see whether the zone was transferred
correctly. If not, you probably have a zone transfer problem; see "Zone Transfer Problems" later in this chapter.

– Or –

If the zone was transferred correctly, check whether the data is now correct. If not, the data is incorrect on the

primary zone. Proceed to the next step.

5. If the data is incorrect on the primary zone, the problem might be caused by user error when entering data into
the zone, a problem with Active Directory replication, a problem with dynamic update, or a WINS lookup problem.
For information about problems with user error and Active Directory replication, see "Troubleshooting DNS
Problems" later in this chapter. For information about problems with dynamic update, see "Troubleshooting
Dynamic Update." For information about WINS lookup problems, see "Solving Common DNS Problems" later in this
chapter.

If you are responsible for maintaining the zone, you can solve the problem. Otherwise, ask the person who is

responsible for maintaining the zone to solve the problem.

Diagnosing Problems with Recursion

For recursion to work successfully, all DNS servers that are used in the path of a recursive query must be able to

respond and forward correct data. If they cannot, a recursive query can fail for any of the following reasons:

 The query times out before it can be completed.

 A server used during the query fails to respond.

 A server used during the query provides incorrect data.

If you have determined that you have a problem with recursion, use the following process, shown in Figure 6.39, to help

troubleshoot the problem. Start with the server used in your original query:

1. Check whether this server forwards queries to another server by examining the Forwarders tab in the server
properties in the DNS console. If the check box Enable forwarders is selected and one or more servers are listed,
this server forwards queries.

If this server does forward queries to another server, check for problems with the server to which this server

forwards queries. To check for problems, follow the troubleshooting steps in "Checking the DNS Server for
 Problems." When that section instructs you to perform a task on the client, perform it on the server instead.

If the server is healthy and can forward queries, repeat this step, examining the server to which this server forwards

queries.

– Or –

If this server does not forward queries to another server, proceed to the next step.

2. Test whether this server can query a root server by typing the following:

nslookup

server <IP address of the server you are examining>

set querytype=NS

If the resolver returns the IP address of a root server, you probably have a broken delegation between the root

server and the name or IP address that you are attempting to resolve. Follow the procedure "To test for a broken

delegation" to determine where you have a broken delegation.

–Or –

If the resolver returns the response "Request to server timed out," check whether the root hints points to

functioning root servers by following the procedure "To view the current root hints." If the root hints does point to

functioning root servers, you might have a network problem, or the server might use an advanced firewall

configuration that prevents the resolver from querying the server, as described in "Checking the Server for

Problems," earlier in this chapter. It is also possible that the recursive time-out default (15 seconds) is too short. For

information about how to change this time-out, see the Windows 2000 Server Help. Search for "tuning advanced

parameters."

Note

Begin the tests in the following procedure by querying a valid root server. The test takes you through a process of

querying all the DNS servers from the root down to the server that you are testing for a broken delegation.

To test for a broken delegation

1. At the command prompt on the server that you are testing, type the following:

nslookup

server <server IP address>

set norecursion

set querytype=<resource record type>

<FQDN >

where resource record type is the type of resource record that you were querying for in your original query, and

FQDN is the FQDN for which you were querying (terminated by a period).

2. If the response includes a list of NS and A resource records for delegated servers, repeat step 1 for each server
and use the IP address from the A resource records as the server IP address.

– Or –

If the response does not contain an NS resource record, you have a broken delegation.

–Or –

If the response contains NS resource records, but no A resource records, type set recursion and query individually

for A resource records of servers listed in the NS records. If for each NS resource record in a zone, you do not find at

least one valid IP address of an A resource record for each NS resource record, you have a broken delegation.

If you determine that you have a broken delegation, fix it by adding or updating an A resource record in the parent zone

with a valid IP address for a correct DNS server for the delegated zone.

To view the current root hints

1. Start the DNS console.

2. Add or connect to the DNS server that failed a recursive query.

3. Right-click the server and select Properties.
4. Click Root Hints.
5. Check for basic connectivity to the root servers.
6. If root hints appear to be configured correctly, verify that the DNS server used in a failed name resolution can
ping the root servers by IP address.

If the root servers do not respond to pinging by IP address, the IP addresses for the root servers might have

changed. However, reconfiguration of root servers, is uncommon.

Diagnosing Zone Transfer Problems

If you have determined that a secondary server cannot pull a zone transfer from a master server, use the following

process, shown in Figure 6.40, to diagnose and solve your zone transfer problems.

1. Check Event Viewer for both the primary and secondary DNS server. For information about Event Viewer, see
"Troubleshooting Tools" earlier in this chapter.

2. Check the master server to see whether it is refusing to send the transfer for security reasons. Check the Zone
Transfers tab of the zone properties in the DNS console. If the server restricts zone transfers to a list of servers,
such as those listed on the Name Servers tab of the zone properties, make sure that the secondary server is on
that list. Make sure that the server is configured to send zone transfers.
3. Check the master server for problems by following the steps in "Checking the DNS Server for Problems" earlier
in this chapter. When prompted to perform a task on the client, perform the task on the secondary server instead.
4. Check whether the secondary server is running another DNS server implementation, such as BIND. If so, the
problem might have one of several causes:

 The Windows 2000 master server might be configured to send fast zone transfers, but the third-

party secondary server might not support fast zone transfers. If so, disable fast zone transfers on the

master server by selecting the check box Bind secondaries on the Advanced tab of the properties for

your server, from within the DNS console.

 If a forward lookup zone on the Windows 2000 server contains a WINS lookup record or the

reverse lookup zone contains a WINS-R record, the BIND server might not be able to transfer the zone. For

information about diagnosing problems in which a BIND server cannot transfer a zone, see "Solving

Common DNS Problems" later in this chapter.

 If a forward lookup zone on the Windows 2000 server contains a record type (for example, an SRV

record) the secondary server does not support, the secondary server might have problems pulling the

zone.
5. Check whether the master server is running another DNS server implementation, such as BIND.

If so, it is possible that the zone on the master server includes incompatible resource records that Windows 2000

does not recognize. For a complete list of all RFC-compliant resource record types that are supported by DNS

servers that are running under Windows 2000 Server, see Windows 2000 Server Help.

6. If either the master or secondary server is running another DNS server implementation, check both servers to
make sure that they support the same features. You can check the Windows 2000 server from the Advanced tab of
the properties page for the server from within the DNS console. In addition to the Bind secondaries box, this page
includes the Name checking drop down list, which enables you to select enforcement of strict RFC compliance for
characters in DNS names.