Troubleshooting DHCP clients

Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2

Troubleshooting DHCP clients

What problem are you having?

 The DHCP client does not have an IP address configured or indicates that its IP address is 0.0.0.0.

 The DHCP client appears to have automatically assigned itself an IP address that is incorrect for the
current network.

 The DHCP client appears to be missing some network configuration details or is unable to perform related
tasks, such as resolving names.

 The DHCP client appears to have incorrect or incomplete options, such as an incorrect or missing router
(default gateway) configured for the subnet on which it is located.

 Many DHCP clients are unable to get IP addresses from the DHCP server.

 The DHCP client appears to be affected by another problem not described above.

The DHCP client does not have an IP address configured or indicates that its IP address is 0.0.0.0.

 Cause:  The client was not able to contact a DHCP server and obtain an IP address lease, either because
of a network hardware failure or because the DHCP server is unavailable.

 Solution:  Verify that the client computer has a valid functioning network connection. First, check that
related client hardware (cables and network adapters) are working properly at the client using basic
network and hardware troubleshooting steps.

If the client hardware appears to be prepared and functioning properly, check that the DHCP server is
available on the network by pinging it from another computer on the same network as the affected DHCP
client.

The DHCP client appears to have automatically assigned itself an IP address that is incorrect for the
current network.

 Cause:  The client running Windows 98, Windows Millennium Edition, or Windows XP could not find a
DHCP server and has used IP autoconfiguration to configure its IP address.

In some larger networks, disabling IP autoconfiguration might be desirable for network administration.

 Solution:  First, use the ping command to test connectivity from the client to the server. Your next step
would be to either verify or manually attempt to renew the client lease. Depending on your network
requirements, it might be necessary to disable IP autoconfiguration at the client. You can learn more
about IP autoconfiguration and how it works prior to making this decision.
Troubleshooting DHCP servers
What problem are you having?

 The DHCP server is stopped.

 The DHCP server is unable to provide service to clients.

 One of two DHCP servers on the same subnet is not servicing clients.

 The DHCP server appears to have suffered some data corruption or loss.

 The server appears to be affected by another problem not described above.

The DHCP server is stopped.

 Cause:  The DHCP server has not been authorized to operate on the network.

 Solution:  Authorize the DHCP server in the enterprise where it is being used.

 See also:  Authorizing DHCP servers; Authorize a DHCP server in Active Directory; Delegate ability to
authorize DHCP servers to a non-enterprise administrator

 Cause:  Configuration details might be incorrect or missing at the server.

 Solution:  If you have just completed setting up or administering the DHCP server, you might want to
review the provided checklist to see if you have missed a crucial step in the installation process.

To help prevent the most common types of problems, review DHCP best practices for tips on deploying
and managing your servers.

Because many DHCP failures are first detected as client-side errors, you might want to start by
investigating the problem there.

 See also:  Checklist: Installing a DHCP server; DHCP Best Practices; Troubleshooting DHCP clients

 Cause:  The DHCP server has been stopped.

 Solution:  Check the system event log and DHCP server audit log files for details.

When the DHCP Server service either stops or cannot start, useful explanatory information about the
source of the service failure or shutdown can generally be found in these logs.

 See also:  Audit logging; Analyzing server log files; Using the Event Viewer snap-in; Search for specific
events

The DHCP server is unable to provide service to clients.

 Cause:  The server is a multihomed computer and is not providing service on one or more of its network
connections.
 Solution:  Review Windows Server 2003 DHCP binding defaults for network connections based on
whether you have elected to either statically or dynamically configure TCP/IP for any or all installed
connections on the server computer. Also, review an example of multihomed DHCP server configuration to
see if you have missed any critical details.

 See also:  Multihomed DHCP servers; Selectively set DHCP server bindings for network connections

 Cause:  Scopes or superscopes on the DHCP server have not been either configured or activated for use.

 Solution:  Add scopes and make sure that they are correctly configured along with any DHCP scope
options that need to be assigned for client use.

 See also:  Configuring scopes; Create a new scope; Assign a scope-based option

 Cause:  The server is located on a different subnet as some of its clients and is not providing service to
clients on remote subnets.

 Solution:  If you are using a DHCP server in a routed network, you might want to review issues related to
DHCP relay agents and the appropriate use of superscopes.

 See also:  DHCP/BOOTP Relay Agents; Using superscopes; Create a superscope

 Cause:  The scope in use is full and can no longer lease addresses to requesting clients.

 Solution:  If the DHCP server does not have IP addresses available to provide to its clients, it returns
DHCP negative acknowledgment messages (DHCPNAKs) to them. When this occurs, consider the following
possible solutions:

1. Expand the address range by increasing the End IP address for the current scope.

2. Create a new additional scope and a superscope, then add the current scope and the new scope to the
superscope.

3. Create a new scope or extend the range. Optimally, you could renumber your current IP network.
Deactivate the old scope as needed, and then configure and activate the new one.

4. Reduce the lease duration. This can help to expedite the reclaiming of lapsed scope addresses.

Other DHCP-related procedures and techniques might also help to accelerate or ease the transition from
an existing scope being retired to a new scope created to take its place at the server. These include
deleting client leases from the scope being retired, excluding addresses from that scope, and then
deactivating it once the new scope has been activated. This ensures that the DHCP client obtains leasing
from the new scope.

 See also:  Managing leases; Removing scopes; Delete a client lease; Exclude an address from a scope;
Activate a scope; Deactivate a scope

 Cause:  The range of IP addresses being offered by the DHCP server is in conflict with the range of
addresses being offered by another DHCP server on the network.
 You can confirm that this is the likely cause if DHCP server logs still indicate that DHCP negative
acknowledgment messages (DHCPNAKs) are being returned to requesting clients or if you have tried
unsuccessfully at the client to renew its lease manually.

 Solution:  Modify the scope address pool for the scopes at each DHCP server to ensure that scope IP
addresses do not overlap. You can add exclusions to the scopes as necessary, delete client leases, and
temporarily enable server-side conflict detection to assist in solving the problem.

 See also:  Delete a client lease; Exclude an address from a scope; Enable address conflict detection;
DHCP Best Practices

One of two DHCP servers on the same subnet is not servicing clients.

 Cause:  The DHCP server is not authorized in Active Directory.

 Solution:  If the DHCP server is a domain member, authorize the server in Active Directory.

In some circumstances you might accidentally have a standalone server and a domain member server on
the same subnet. When the standalone server detects the domain member server, it attempts to verify
that it is authorized in Active Directory. Even if a domain controller resides on the same subnet as the
standalone DHCP server, the DHCP server cannot verify its status with the domain controller because the
DHCP server is not a domain member. When the standalone server is unable to access a domain controller
to discover whether it is authorized, it stops servicing clients and displays the red icon in the DHCP
console that indicates the server is unauthorized. If you want the standalone server to service clients on
the subnet, remove the authorized DHCP server from the subnet.

 See also:  Authorizing DHCP servers; Authorize a DHCP server in Active Directory; DHCP console icons
reference

The DHCP server appears to have suffered some data corruption or loss.

 Cause:  The DHCP server database has become corrupted or is missing server data, possibly reporting
JET database errors.

 Solution:  Use DHCP server data recovery options to restore the database and correct any of the reported
errors. You can also use the Reconcile feature in the DHCP console to verify and reconcile any database
inconsistencies that the server is able to find.

 See also:  Restoring server data; The DHCP database; Reconciling scopes; Reconcile the DHCP database;
Reconcile a scope

 See also:  Test a TCP/IP configuration by using the ping command; Verify, release, or renew a client
address lease; Configure TCP/IP for automatic addressing; Disable automatic address configuration

The DHCP client appears to be missing some network configuration details or is unable to perform
related tasks, such as resolving names.
  Cause:  The client might be missing DHCP options in its leased configuration, either because the DHCP
server is not configured to distribute them or the client does not support the options distributed by the
server.

 Solution:  For Microsoft DHCP clients, verify that the most commonly used and supported options have
been configured at the server, scope, client, or class level of options assignment.

 See also:  Manage Options and Classes; Assigning options

The DHCP client appears to have incorrect or incomplete options, such as an incorrect or missing router
(default gateway) configured for the subnet on which it is located.

 Cause:  The client has the full and correct set of DHCP options assigned but its network configuration
does not appear to be working correctly.

If the DHCP server is configured with an incorrect DHCP router option (option code 3) for the default
gateway address of the client, clients running Windows NT, Windows 2000, or Windows XP use the correct
address. However, DHCP clients running Windows 95 use the incorrect address.

 Solution:  Change the IP address list for the router (default gateway) option at the applicable DHCP scope
and server. If you are configuring the router option as a Server Option at the affected DHCP server,
remove it there and set the correct value in the Scope Options node for the applicable DHCP scope that
services the client.

In rare instances, you might have to configure the DHCP client to use a specialized list of routers different
from other scope clients. In such cases, you can add a reservation and configure the router option list
specifically for the reserved client.

 See also:   Assign a server-based option; Assign a scope-based option; Assign an option to a reserved
client; Add a client reservation; Assigning options

For more information about DHCP options, see "DHCP Options" at the Microsoft Windows Resource Kits
Web site.

Many DHCP clients are unable to get IP addresses from the DHCP server.

 Cause:  The IP address of the DHCP server was changed and now DHCP clients cannot get IP addresses.

 Solution:  A DHCP server can only service requests for a scope that has a network ID that is the same as
the network ID of its IP address.

Make sure that the DHCP server IP address falls in the same network range as the scope it is servicing.
For example, a server with an IP address in the 192.168.0.0 network cannot assign addresses from scope
10.0.0.0 unless superscopes are used.

 See also:  DHCP Best Practices; Using superscopes; Configuring scopes

 Cause:  The DHCP clients are located across a router from the subnet where the DHCP server resides and
are unable to receive an address from the server.
  Solution:  A DHCP server can provide IP addresses to client computers on remote multiple subnets only if
the router that separates them can act as a DHCP relay agent.

Completing the following steps might correct this problem:

1. Configure a BOOTP/DHCP Relay Agent on the client subnet (that is, the same physical network segment).
The relay agent can be located on the router itself, on a computer running Windows NT Server and the
DHCP Relay Agent component, on a computer running Windows 2000 Server with the Routing and Remote
Access service enabled and configured as a DHCP Relay Agent, or on a computer running a Windows
Server 2003 operating system with the Routing and Remote Access service enabled and configured as a
DHCP Relay Agent.

2. At the DHCP server, do the following:

a. Configure a scope to match the network address on the other side of the router where the
affected clients are located.

b. In the scope, make sure that the subnet mask is correct for the remote subnet.

c. Use a default gateway on the network connection of the DHCP server in such a way that it is not
using the same IP address as the router that supports the remote subnet where the clients are
located.

d. Do not include this scope (that is, the one for the remote subnet) in superscopes configured for
use on the same local subnet or segment where the DHCP server resides.

3. Make sure there is only one logical route between the DHCP server and the remote subnet clients.

 See also:  DHCP Best Practices; DHCP/BOOTP Relay Agents; BOOTP and DHCP

 Cause:  Multiple DHCP servers exist on the same local area network (LAN).

 Solution:  Make sure that you do not configure multiple DHCP servers on the same LAN with overlapping
scopes.

You might want to rule out the possibility that one of the DHCP servers in question is a computer running
Small Business Server. On a computer running Small Business Server, the DHCP Server service
automatically stops when it detects another DHCP server on the LAN.

Troubleshooting DNS clients

Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2

Troubleshooting DNS clients

What problem are you having?

 The DNS client received a "Name not found" error message.

  The DNS client appears to have received a response with stale or incorrect information in it.

 The DNS client appears to be affected by another problem not described above.

The DNS client received a "Name not found" error message.

Cause:  The DNS client computer does not have a valid IP configuration for the network.

Solution:  Verify that TCP/IP configuration settings for the client computer are correct, particularly those used for
DNS name resolution.

To verify a client IP configuration, use the ipconfig command. In the command output, verify that the client has a
valid IP address, subnet mask, and default gateway for the network where it is attached and being used.

If the client does not have a valid TCP/IP configuration, you can either:

1. For dynamically configured clients, use the ipconfig /renew command to manually force the client to
renew its IP address configuration with the DHCP server.

2. For statically configured clients, modify the client TCP/IP properties to use valid configuration settings or
complete its DNS configuration for the network.

See also:  Ipconfig; Configure TCP/IP for dynamic addressing; Configure TCP/IP for static addressing; Configure
TCP/IP to use DNS; Configuring DNS client settings.

Cause:  The client was not able to contact a DNS server because of a network or hardware related failure.

Solution:  Verify that the client computer has a valid and functioning network connection. First, check that related
client hardware (cables and network adapters) are working properly at the client using basic network and hardware
troubleshooting steps.

If the client hardware appears to be prepared and functioning properly, verify that it can ping other computers on
the same network.

See also:  Test a TCP/IP configuration by using the ping command.

Cause:  The DNS client cannot contact its configured DNS servers.

Solution:  If the DNS client has basic connectivity to the network, verify that it can contact a preferred (or
alternate) DNS server.

To verify whether a client has basic TCP/IP access to the DNS server, first try pinging the preferred DNS server by
its IP address.

For example, if the client uses a preferred DNS server of 10.0.0.1, type ping 10.0.0.1 at the command prompt on
the client computer. If you are not sure what the IP address is for the preferred DNS server, you can observe it by
using the ipconfig command.

For example, at the client computer, type ipconfig /all|more if necessary to pause the display so you can read
and note any IP addresses listed in DNS servers for the command output.

If no configured DNS servers respond to a direct pinging of their IP address, it indicates that the source of the
problem is more likely a network connectivity problem between the client and the DNS servers. If that is the case,
follow basic TCP/IP network troubleshooting steps to fix the problem.

See also:  Test a TCP/IP configuration by using the ping command.

Cause:  The DNS server is not running or responding to queries.

Solution:  If the DNS client can ping the DNS server computer, verify that the DNS server is started and able to
listen for and respond to client requests. Try using the nslookup command to test whether the server can respond
to DNS clients.

See also:  Verify DNS server responsiveness using the nslookup command; Start or stop a DNS server.
Cause:  The DNS server the client is using does not have authority for the failed name and cannot locate the
authoritative server for this name.

Solution:  Confirm whether the DNS domain name the client is trying to resolve is one for which its configured
DNS servers are authoritative.

For example, if the client is attempting to resolve the name host.example.microsoft.com, verify that the preferred
(or an alternate, if one is being used) DNS server queried by the client loads the authoritative zone where a host
(A) resource record (RR) for the failed name should exist.

If the preferred server is authoritative for the failed name and loads the applicable zone, determine whether the
zone is missing the appropriate RRs. If needed, add the RRs to the zone.

If the preferred server is not authoritative for the failed name, it indicates that configuration errors at the DNS
server are the likely cause. As needed, further troubleshoot the problem at the DNS server.

See also:  Manage Resource Records; Troubleshooting DNS servers.

The DNS client appears to have received a response with stale or incorrect information in it.
Cause:  The DNS server the client is using does not have authority for the failed name and is using stale
information from its local DNS database.

Solution:  Determine whether the DNS server is authoritative for the name and proceed accordingly.

For example, if the client is attempting to resolve the name host.example.microsoft.com, verify that the preferred
(or an alternate, if one is being used) DNS server queried by the client loads the authoritative zone where a host
(A) resource record (RR) for the failed name should exist.

If the preferred server is authoritative for the name and answered using incorrect data, it indicates that the
applicable zone might have outdated or stale information in the applicable RR data. If that is the case, you can add
and remove the appropriate RRs in the zone.

Another option where dynamic updates are enabled is to force registration and update at the computer targeted by
the query. You can force it to update the registration of its resource records by typing the ipconfig /registerdns
command at a command prompt.

If the preferred server is not a direct authority for the queried name, it likely answered the query based on
information obtained and cached during an earlier recursive lookup. In this case, you might consider clearing the
server names cache. This compels the server to use new recursive queries for this RR data and rebuild its cache
contents based on current information.

See also:  Manage Resource Records; Troubleshooting DNS servers; Renew DNS client registration using the
ipconfig command; Clear the server names cache.

Cause:  The preferred DNS server is a secondary server for the zone containing the targeted name and has
outdated information.

Solution:  If the server that answered the client is a secondary server for the zone, the version of the zone in use
at that server might be stale and need to be updated more often.

As an immediate solution, you can initiate a zone transfer at the secondary server to its master server to update
the zone. You might also consider using any of the following to improve the freshness of secondary zone data in
the future:

1. Specify additional master servers for the secondary server to use when refreshing the zone.

2. Adjust the refresh interval on the zone slightly to decrease the length of time that all authoritative servers
for the zone can use the zone before they are required to refresh it.

3. Configure a notify list at a master server that acts as the zone source for the secondary server and enable
it to notify this server when the zone changes.
See also:  Initiate a zone transfer at a secondary server; Adjust the refresh interval for a zone; Create and
manage a notify list for a zone; Using secondary servers; Understanding zones and zone transfer.

Cause:  The name queried was specified in error, either through user input or in a stored client configuration.

Solution:  Verify that the name was correctly specified in the application where the name query originated.

In most cases, incorrect data in a positive query response indicates one of three possibilities:

 An incorrect DNS name was entered at the client by a user.

 A short unqualified name was used at the client and completed by the local resolver using an unintended
DNS suffix.

 Resource records specified in the query were not updated correctly at the DNS server.

Confirm that the name was not entered in error by the user. Verify the exact set of characters entered by the user
when the original DNS query was made or check in application settings, such as for any Internet mail or Web
browser configurations that were made.

If the name used in the initial query was unqualified, and not the fully qualified domain name (FQDN), try using the
FQDN instead in the client application and repeating the query. If you do, be sure to include the trailing dot (.) at
the end of the name to indicate that 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 DNS domain suffix search list used in the client resolver settings.

If you are using DNS in an environment that does not support dynamic updates, or generally administer zone data
manually, you might also want to verify that the RRs involved in answering the query were not entered incorrectly.
View them to ensure the record data stored in the zone is correct or modify it accordingly.

See also:  Configure TCP/IP to use DNS; Modify an existing resource record in a zone.

Cause:  The primary zone might have missing or errored data

Solution:  Verify that the primary server for the zone has complete and accurate data.

The most likely cause for a primary DNS server for a zone to have missing or incomplete data is because of a failed
update request. It is possible that support for dynamic update has not been fully implemented or configured. To
resolve the problem, review the DNS dynamic update protocol (RFC 2136) and any requirements it has for DNS
servers and clients that use it.

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

If you have specifically configured your zones to disable dynamic update, keep in mind that you need to manually
add and update most types of resource records used in a zone. If this is the case, use the DNS console to view and
update the affected records.

Another possibility for the errored data is in whether WINS lookup integration is enabled and used with the zone. If
you are using WINS lookup with your zones, verify that WINS is not the source of the errored data.

Troubleshooting DNS servers

Updated: January 21, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2

Troubleshooting DNS servers

What problem are you having?

 The DNS server is not responding to clients.

 The DNS server does not resolve names correctly.

 The DNS server appears to be affected by a problem for reasons not described above.

The DNS server is not responding to clients.

Cause:  The DNS server is affected by a network failure.

Solution:  Verify that the server computer has a valid functioning network connection. First, check that related
client hardware (cables and network adapters) are working properly at the client using basic network and hardware
troubleshooting steps.

If the server hardware appears to be prepared and functioning properly, check that it has network connectivity by
pinging other computers or routers (such as its default gateway) that are used and available on the same network
as the affected DNS servers.

See also:  Test a TCP/IP configuration by using the ping command.

Cause:  The DNS server is reachable through basic network testing but is not responding to DNS queries from
clients.

Solution:  If the DNS client can ping the DNS server computer, verify that the DNS server is started and able to
listen to and respond to client requests. Try using the nslookup command to test whether the server can respond
to DNS clients.

See also:  Verify DNS server responsiveness using the nslookup command; Start or stop a DNS server.

Cause:  The DNS server has been configured to limit service to a specific list of its configured IP addresses. The IP
address originally used in testing its responsiveness is not included in this list.

Solution:  If the server was previously configured to restrict the IP addresses for which it responds to queries, it is
possible that the IP address being used by clients to contact it is not in the list of restricted IP addresses permitted
to provide service to clients.

Try testing the server for a response again, but specify a different IP address known to be in the restricted
interfaces list for the server. If the DNS server responds for that address, add the missing server IP address to the
list.

See also:  Verify DNS server responsiveness using the nslookup command; Restrict a DNS server to listen only on
selected addresses.

Cause:  The DNS server has been configured to disable the use of its automatically created default reverse lookup
zones.

Solution:  Verify that automatically created reverse lookup zones have been created for the server or that
advanced configuration changes have not been previously made to the server.

By default, DNS servers automatically create the following three standard reverse lookup zones based on Request
for Comments (RFC) recommendations:

These zones are created with common IP addresses covered by these zones that are not useful in a reverse lookup
search (0.0.0.0, 127.0.0.1, and 255.255.255.255). By being authoritative for the zones corresponding to these
addresses, the DNS service avoids unnecessary recursion to root servers in order to perform reverse lookups on
these types of IP addresses.

It is possible, although unlikely, that these automatic zones are not created. This is because disabling the creation
of these zones involves advanced manual configuration of the server registry by a user.

To verify that these zones have been created, do the following:

1. Open the DNS console.

2. From the View menu, click Advanced.

3. In the console tree, click Reverse Lookup Zones.

Where?

 DNS/applicable DNS server/Reverse Lookup Zones

4. In the details pane, verify that the following reverse lookup zones are present:

 0.in-addr.arpa

 127.in-addr.arpa

 255.in-addr.arpa

See also:  Open the DNS console; DNS RFCs.

Cause:  The DNS server is configured to use a non-default service port, such as in an advanced security or firewall
configuration.

Solution:  Verify that the DNS server is not using a non-standard configuration.

This is a rare but possible cause. By default, the nslookup command sends queries to targeted DNS servers using
User Datagram Protocol (UDP) port 53. If the DNS server is located on another network only reachable 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.

If this situation applies, determine whether any intermediate firewall or proxy server configuration is intentionally
used to block traffic on well-known service ports used for DNS. If not, you might be able to add such a packet filter
onto these configurations to permit traffic to standard DNS ports.

Also, check the DNS server event log to see if Event ID 414 or other critical service-related events have occurred
which might indicate why the DNS server is not responding.

See also:  DNS server log reference; View the DNS server system event log; Microsoft Windows Deployment and
Resource Kits.

The DNS server does not resolve names correctly.

Cause:  The DNS server provides incorrect data for queries it successfully answers.

Solution:  Determine the cause of the incorrect data for the DNS server.

Some of the most likely causes include the following:

 Resource records (RRs) were not dynamically updated in a zone.

  An error was made when manually adding or modifying static resource records in the zone.

 Stale resource records in the DNS server database, left from cached lookups or zone records not updated
with current information or removed when they are no longer needed.

To help prevent the most common types of problems, be sure to first review best practices for tips and suggestions
on deploying and managing your DNS servers. Also, follow and use the checklists appropriate for installing and
configuring DNS servers and clients based on your deployment needs.

If you are deploying DNS for Active Directory, note new directory integration features. These features can cause
some differences for DNS server defaults when the DNS database is directory-integrated, that differ from those
used with traditional file-based storage.

Many DNS server problems start with failed queries at a client, so it is often good to start there and troubleshoot
the DNS client first.

See also:  DNS best practices; DNS Checklists; Troubleshooting DNS clients; Modify an existing resource record in
a zone; Clear the server names cache; Modifying server defaults.

Cause:  The DNS server does not resolve names for computers or services outside of your immediate network,
such as those located on external networks or the Internet.

Solution:  The server has a problem based on its ability to correctly perform recursion. Recursion is used in most
DNS configurations to resolve names that are not located within the configured DNS domain name used by the
DNS servers and clients.

If a DNS server fails to resolve a name for which it is not authoritative, the cause is usually a failed recursive
query. Recursive queries are used frequently by DNS servers to resolve remote names delegated to other DNS
zones and servers.

For recursion to work successfully, all DNS servers used in the path of a recursive query must be able to respond to
and forward correct data. If not, a recursive query can fail for any of the following reasons:

 The recursive query times out before it can be completed.

 A remote DNS server fails to respond.

 A remote DNS server provides incorrect data.

If a server fails a recursive query for a remote name, review the following possible causes to troubleshoot the
problem. If you do not understand recursion or the DNS query process, review conceptual topics in Help to better
understand the issues involved.

See also:  How DNS query works.

Cause:  The DNS server is not configured to use other DNS servers to assist it in resolving queries.

Solution:  Check whether the DNS server can use both forwarders and recursion.

By default, all DNS servers are enabled to use recursion, although the option to disable its use is configurable using
the DNS console to modify advanced server options. The other possibility where recursion might be disabled is if
the server is configured to use forwarders and recursion has been specifically disabled for that configuration.

Note

 If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.

See also:  Disable recursion on the DNS server; Configure a DNS server to use forwarders.
Cause:  Current root hints for the DNS server are not valid.

Solution:  Check whether server root hints are valid.

If configured and used correctly, root hints always should point to DNS servers authoritative for the zone
containing the domain root and top-level domains.

By default, DNS servers are configured to use root hints appropriate to your deployment, based on the following
available choices when using the DNS console to configure a server:

1. If the DNS server is installed as the first DNS server for your network, it is configured as a root server.

For this configuration, root hints are disabled at the server because the server is authoritative for the root
zone.

2. If the installed server is an additional DNS server for your network, you can direct the Configure DNS
Server Wizard to update its root hints from an existing DNS server on the network.

3. If you do not have other DNS servers on your network but still need to resolve Internet DNS names, you
can use the default root hints file which includes a list of Internet root servers authoritative for the
Internet DNS namespace.

See also:  Update root hints on the DNS server; Updating root hints.

Cause: The DNS server does not have network connectivity to the root servers.

Solution:  Test for connectivity to the root servers.

If root hints appear to be configured correctly, verify that the DNS server used in a failed query can ping its root
servers by IP address.

If a ping attempt to one root server fails, it might indicate that an IP address for that root server has changed.
Reconfiguration of root servers, however, is uncommon.

A more likely cause is a full loss of network connectivity or in some cases, poor network performance on the
intermediate network links between the DNS server and its configured root servers. Follow basic TCP/IP network
troubleshooting steps to diagnose connections and determine whether this is the problem.

By default, the DNS service uses a recursive time-out of 15 seconds before failing a recursive query. Under normal
network conditions, this time-out does not need to be changed. If performance warrants it, however, you can
increase this value.

To review additional performance related information on DNS queries, you can enable and use the DNS server
debug log file, Dns.log, which can provide extensive information about some types of service-related events.

See also:  Test a TCP/IP configuration by using the ping command; Using server debug logging options; View a
DNS server debug log file; Tuning advanced server parameters.

Cause: Other problems exist with updating DNS server data, such as an issue related to zones or dynamic
updates.

Solution:  Determine whether the problem is related to zones. As needed, Troubleshoot any issues in this area,
such as possible failure of zone transfer.

See also:  Troubleshooting dynamic updates; Troubleshooting zone problems.

Troubleshooting dynamic updates
Published: January 21, 2005

Updated: August 25, 2010

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2

Troubleshooting dynamic updates

What problem are you having?

 The DNS client is not performing dynamic updates.

 The DNS server is not performing dynamic updates.

 I am having a different problem related to dynamic updates than those described above.

The DNS client is not performing dynamic updates.

Cause:  The client (or its DHCP server) do not support the use of the DNS dynamic update protocol.

Solution:  Verify that your clients or servers support the DNS dynamic update protocol.

In order for client computers to be registered and updated dynamically with a DNS server, either:

1. Install or upgrade client computers to Windows XP or Windows Server 2003 .

2. Install and use the DHCP Server service on your network to lease client computers.

By default, computers attempt to register and perform dynamic update of their DNS names and IP addresses with
a DNS server.

For other types of computers, you can deploy Windows Server 2003 DHCP servers, which can perform proxied
registrations and updates as needed for non-dynamic clients.

Notes

 By default, the DNS client on Windows XP does not attempt dynamic update over a Remote Access Service
(RAS) or virtual private network connection. To modify this configuration, you can modify the advanced
TCP/IP settings of the particular network connection or modify the registry. For more information, see
Configure TCP/IP to use DNS and the Microsoft Windows Resource Kits Web site.

 By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone
named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company. To
configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level
Domain Zones policy setting or modify the registry.

Cause:  The client was not able to register with the DNS server because of intermittent problems with either the
DNS server or the network.

Solution:  At the client computer, use the ipconfig command as appropriate to retry registration or renewal and
update client information with the DNS server.

You can use the ipconfig /registerdns command option to manually force a retry of its dynamic registration.

For computers running earlier versions of Windows, you can use the options of the ipconfig command to verify,
view, or renew the client TCP/IP configuration details as appropriate.
For example, if the client computer obtains its IP address lease from a DHCP server, you might use the ipconfig
/renew command to force it to renew its lease with the DHCP server. This action would then cause the DHCP
server to proxy an update request to its configured DNS server on behalf of the client.

If the DHCP server succeeds in performing the proxied update with the DNS server, the result would be updated
DNS host name and IP address information for the client computer in the DNS database.

See also:  Renew DNS client registration using the ipconfig command.

Cause:  The client was not able to register and update with the DNS server because of missing or incomplete DNS
configuration.

Solution:  Verify that the client is fully and correctly configured for DNS, and update its configuration as needed.

One common cause of the client failing to update with the DNS server is that it does not have a DNS suffix (either
a primary suffix or connection-specific suffix) configured. This might result in the client attempting to register an
incorrect or unintended DNS domain name.

For example, the client could be attempting to register its short or unqualified computer or host name as a top-
level domain name in the root zone. This happens because without a DNS suffix configured for the client computer,
it determines the configured short name of a computer (such as host-a) is its fully qualified domain name (FQDN).
This only occurs because the computer name does not have a DNS suffix to append to it and qualify the computer
name when registering it for the client in DNS.

To update the DNS configuration for a client, either:

1. Configure a primary DNS suffix at the client computer for static TCP/IP clients.

2. Configure a connection-specific DNS suffix for use at one of the installed network connections at the client
computer.

See also:  Configure the primary DNS suffix for a client computer; Configure TCP/IP to use DNS; Install and
Configure Clients; Managing Clients.

Cause:  The DNS client attempted to update its information with the DNS server but failed because of a problem
related to the server.

Solution:  If a client can reach its preferred and alternate DNS servers as configured, it is likely that the cause of
its failed updates can be found elsewhere.

At Windows-based client computers, you can use Event Viewer to check the System log for any event messages
that explain why attempts by the client to dynamically update its host (A) or pointer (PTR) resource records failed.

When reviewing messages in the System log, filter or order the display of all messages to view those that specify
DnsApi as the source for the message. Typically, these messages are related to the performance of DNS activities,
such as DNS queries or dynamic updates.

A common reason updates might fail for a mobile client is that the DNS server required to accept and perform the
update does not respond when the client starts at a remote location on the network. This could be due to network
performance issues or might indicate a problem in the underlying design of your network. Where these issues
persist or seem likely, you should review your DNS deployment and modify it accordingly.

See also:  Deploying DNS; Dynamic update.

The DNS server is not performing dynamic updates.

Cause:  The DNS server does not support dynamic updates.

Solution:  Verify that the DNS server used by the client can support the DNS dynamic update protocol, as
described in RFC 2136.

Only the Windows 2000 and Windows Server 2003 DNS Server service supports dynamic updates. The DNS Server
service provided with Windows NT Server 4.0 does not.
If you are using other DNS servers on your network, verify that they are running a DNS server implementation that
supports dynamic updates.

See also:  Dynamic update; DNS RFCs.

Cause:  The DNS server supports dynamic updates but is not configured to accept them.

Solution:  Verify that the primary zone where clients require updates is configured to allow dynamic updates.

The default for a new primary zone is to not accept dynamic updates. At the DNS server that loads the applicable
primary zone, modify zone properties to allow updates.

See also:  Allow dynamic updates.

Cause:  The zone database is not available.

Solution:  Verify that the zone is available for update.

First, if necessary, verify that the zone exists. For a standard primary zone, verify that the zone file exists at the
server and that the zone is not paused. If you are using Active Directory-integrated zones, verify that the DNS
server is running as a domain controller and has access to the Active Directory database where zone data is stored.

Secondary zones do not support dynamic updates. If you are trying to determine which server is the primary
server for a standard zone, review zone authority records to determine which server is referenced in both the start
of authority (SOA) and name server (NS) resource records for the zone. This is the primary server for the zone
which can accept dynamic updates to it.

If you need to, you can use the DNS console to change a secondary zone to become a primary zone so that it can
accommodate dynamic updates. However, because standard primary zones use a single-master update model, you
can only configure one server to accept dynamic updates for the zone.

If you change the zone type at a secondary server so that it becomes the primary server for that zone, you need to
either remove the zone or convert it to another zone type (such as a secondary zone) at the original primary
server. Otherwise, zone data would become inconsistent and cause additional problems.

If you want to have more than one DNS server be able to update a zone, it is recommended that you change the
zone type so that it becomes Active Directory-integrated. To be able to use this zone type, Active Directory must
be installed and the server computer must be promoted to a domain controller.

Once the zone is stored in the directory, other domain controllers can load the zone automatically and be allowed
to update it when they are running the DNS Server service. This is because Active Directory supports a multiple (or
floating) master update model where more than one computer can process updates to the directory database.

See also:  Change the zone type; Add and Remove Zones; Managing authority records; Active Directory
integration.

Cause:  The DNS server is configured to allow only secure dynamic updates and has a security-related problem.

Solution:  Verify that zone or resource record security does not block or prevent dynamic updates at the server.

Secure update can be enabled for directory-integrated zones and their resource records. If secure dynamic update
is in effect for a directory-integrated zone, then only users, groups, or computers that have write permissions may
add new resource records to the zone. If secure dynamic update is in effect for resource records, then only users,
groups, or computers that have write permissions can update these resource records. Consequently, security might
block or prevent a DNS client (or its DHCP server) from performing an update of its host (A) and pointer (PTR)
resource records.

In most cases, secure dynamic update does not prevent new records from being created or added to a zone, but it
does restrict who is given default permissions to update or modify records. Where necessary, you can use the
access control list (ACL) editing features available for directory-integrated zones to modify security permissions on
a zone or its resource records and enable update by another user, group, or computer.

Typically, this is only needed if the computer requesting the update is different from the one that owns the client
records and originally created them.

See also:  Dynamic update; Modify security for a directory-integrated zone; Modify security for a resource record.
Cause:  The DNS server required to perform the updates is not available on the network.

Solution:  Verify that the DNS server is available on the network or troubleshoot any further issues as necessary.

See also:  Troubleshooting DNS servers.

Troubleshooting zone problems

Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server
2003 with SP2

Troubleshooting zone problems

What problem are you having?

 I am having a problem related to zone transfers.

 I am trying to use a zone delegation but it appears to be broken.

 I am having a different zone problem than the ones described above.

I am having a problem related to zone transfers.

Cause:  The DNS Server service is stopped or the zone is paused.

Solution:  Verify that the master (source) and secondary (destination) DNS servers involved in completing
transfer of the zone are both started and that the zone is not paused at either server.

See also:  Start or stop a DNS server; Start a zone; Understanding zones and zone transfer.

Cause:  The DNS servers used during a transfer do not have network connectivity with each other.

Solution:  Eliminate the possibility of a basic network connectivity problem between the two servers.

Using the ping command, ping each DNS server by its IP address from its remote counterpart.

For example, at the source server, use the ping command to test IP connectivity with the destination server. At
the destination server, repeat the ping test, substituting the IP address for the source server.

Both ping tests should succeed. If not, investigate and resolve intermediate network connectivity issues.

See also:  Command-line utilities.

Cause:  The serial number is the same at both the source and destination servers. Because the value is the same
at both servers, no zone transfer occurs between the servers.

Solution:  Using the DNS console, perform the following tasks:

1. Increase the value of the serial number for the zone at the master server (source) to a number greater
than the value at the applicable secondary server (destination).

2. Once you have increased the serial number at the master server to a higher value than is used currently
at the secondary server, initiate zone transfer at the secondary server.

When working within the DNS console, the zone serial number can be viewed from the Start of Authority (SOA)
tab in the applicable zone properties. To increase this number in the zone, click Increment.

See also:  Modify the start of authority (SOA) record for a zone; Initiate a zone transfer at a secondary server.
Cause:  The master server (source) and its targeted secondary server (destination) are having interoperability-
related problems.

Solution:  Investigate possible causes for any problems related to interoperability between DNS servers running
Windows Server 2003 and other DNS server implementations, such as an older version of the Berkeley Internet
Name Domain (BIND) distribution.

Older BIND servers use an uncompressed zone transfer format. By default, servers running Windows Server 2003
(and later version BIND servers) use a faster compressed format during zone transfers. To accommodate zone
transfer with older BIND servers, you need to change advanced server options at your DNS servers running
Windows Server 2003.

Another possible interoperability issue is the use and inclusion of WINS forward lookup (WINS) resource records in
a zone or their counterpart, the WINS reverse lookup (WINS-R) resource record used for reverse lookup zones.
BIND servers do not recognize these records when they are included in zone data being transferred and can flag
these records as bad data, possibly failing the zone transfer.

To prevent these records from being used or included in zone transfers to BIND-based servers and other servers
that do not recognize them, select Do not replicate this record when configuring WINS properties at the
applicable zone.

See also:  Interoperability issues; Enable or disable fast transfer format during zone transfers; Interoperability
issues; Using WINS lookup; Enable DNS to use WINS resolution.

Cause:  The zone has resource records or other data that cannot be interpreted by the DNS server.

Solution:  Verify that the zone does not contain incompatible data, such as unsupported resource records types or
data errors.

In most cases, the DNS Server service supports all resource record (RR) types that are approved and required for
Internet standard DNS usage.

Also, verify that the server has not been configured in advance to prevent loading a zone when bad data is found
and investigate its method for checking names. These settings can be configured using DNS console.

See also:  Resource records reference; Prevent loading of a zone when bad data is found; Change the name-
checking method used by the DNS server; Checking names and zone data.

Cause:  Authoritative zone data is incorrect.

Solution:  If a zone transfer continues to fail, ensure that the zone does not contain nonstandard data.

If you manually edit zone files, be aware that records need to be formatted and used according to standard record
usage and formatting guidelines as specified in the Request for Comments (RFCs) for DNS. In most cases, user
input and data errors can be avoided if records are added and managed using the DNS console.

To determine if errored zone data is a likely source for a failed zone transfer, look in the DNS server event log for
messages. You can also use the nslookup command with the -ls option to simulate and test a zone transfer, while
observing the data returned in a terminates before full transfer of the zone is complete.

See also:  Nslookup; DNS RFCs.

I am trying to use a zone delegation but it appears to be broken.

Cause:  Zone delegations are not configured correctly.

Solution:  Review how zone delegations are used and revise your zone configurations as needed.

Zones contain information about DNS domains and subdomains. For each new zone you create, the zone originally
begins as a single-node database for one DNS domain. As needed, new subdomain nodes can be added directly
below the original (parent) domain and stored as a single zone. Sometimes when new subdomains remain part of
the same zone, they are called sub-zones.

If used as sub-zones, new subdomains are retained as part of the zone and replicated and updated along with it as
a single entity. You can, however, delegate subdomains away and manage them in their own zones. For each
subdomain delegated to its own zone, the parent zone needs to have delegation records added to it.

You can use the New Delegation wizard provided in the DNS console to simplify adding these records