Cause:  The Domain Name System (DNS) client computer does not have a valid IP configuration for the network.

Solution:  Verify that the TCP/IP configuration settings for the client computer are correct, particularly those settings that are 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 Dynamic Host Configuration Protocol (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. Do not configure clients to use both AD DS-integrated DNS servers and Internet Service Provider (ISP) DNS servers. Instead, configure clients only to use AD DS-integrated DNS servers and configure your AD DS-integrated DNS servers to forward queries to your ISP DNS servers.
  
  

For more information, see Managing Clients.

Cause:  The client was not able to contact a DNS server because of a network-related 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 by using basic network and hardware troubleshooting steps.

If the client hardware appears to be prepared and functioning properly, verify that it can contact other computers on the same network 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 contacting the preferred DNS server by its IP address by using the ping command.

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 view it by using the ipconfig command. For example, at the client computer, type ipconfig /all|more if necessary to pause the display so that you can read and note any IP addresses that are 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.

For more information, see Start or Stop a DNS Server.

Cause:  The DNS server that 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 that the client is trying to resolve is the DNS domain name for which its configured DNS servers are authoritative.

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

If the preferred server is authoritative for the failed name and it loads the applicable zone, determine whether the zone is missing the appropriate resource records. If necessary, add the resource records 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 necessary, troubleshoot the problem further at the DNS server.

For more information, see Managing Resource Records and Troubleshooting DNS Servers.

Cause:  The DNS server that the client is using does not have authority for the failed name, and it 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.widgets.tailspintoys.com, verify that the preferred DNS server (or an alternate, if one is being used) that is queried by the client loads the authoritative zone where a host (A) resource record for the failed name should exist.

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

Another option, when dynamic updates are enabled, is to force registration and update at the computer that is 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 that it 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 resource record data and to rebuild its cache contents based on current information.

For more information, see Managing Resource Records and Troubleshooting DNS Servers.

Cause:  The preferred DNS server is a secondary server for the zone that contains the targeted name, and it 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 it may 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 options 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 that was 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 that are 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 that was entered by the user when the original DNS query was made, or check application settings, such as settings for any Internet mail or Web browser configurations that may have been made.

If the name that was 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 in the client resolver settings.

If you are using DNS in an environment that does not support dynamic updates or you generally administer zone data manually, you might also want to verify that the resource records involved in answering the query were not entered incorrectly. View them to ensure that the record data that is 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 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 (Request for Comments (RFC) 2136) and any requirements that it has for DNS servers and clients that use it.

For directory-integrated zones, it is also possible that the affected records for the failed query have been updated in Active Directory Domain Services (AD DS) but not replicated to all DNS servers that are loading the zone. By default, all DNS servers that load zones from AD DS poll it at a set interval (typically every 15 minutes), and they 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 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 must manually add and update most types of resource records that are used in a zone. If this is the case, use DNS Manager to view and update the affected records.

Another possible source for the incorrect data is Windows Internet Name Service (WINS). Determine 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 incorrect data.

For more information, see Troubleshooting Dynamic Updates and Managing Resource Records.

Cause:  My problem is not described here.

Solution:  Search Microsoft TechNet (http://go.microsoft.com/fwlink/?LinkId=170) for the latest technical information that may 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 Microsoft Update (http://go.microsoft.com/fwlink/?LinkId=284).