Troubleshooting DNS clients

發行項
10/08/2009

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:

For dynamically configured clients, use the ipconfig /renew command to manually force the client to renew its IP address configuration with the DHCP server.
For statically configured clients, modify the client TCP/IP properties to use valid configuration settings or complete its DNS configuration for the network.

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.

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.

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.

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.

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.

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.

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:

Specify additional master servers for the secondary server to use when refreshing the zone.
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.
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.

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.

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.

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

Cause: My problem is not described above.

Solution: Search TechNet at the Microsoft Web site for the latest technical information that could relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at the Microsoft Web site.

To obtain the latest service pack updates for Windows NT Server, see the Microsoft Web site.

共用方式為

Troubleshooting DNS clients