Diagnosing Name Resolution Problems

  • Article

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-iconImportant

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-iconNote

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.

Cc959340.CNCF25(en-us,TechNet.10).gif

Figure 6.36 No Answer or Name Not Found

Cc959340.CNCF26(en-us,TechNet.10).gif

Figure 6.37 Answer Is Incorrect

Cc959340.CNCF27(en-us,TechNet.10).gif

Figure 6.38 Authoritative Data Is Incorrect

Cc959340.CNCF28(en-us,TechNet.10).gif

Figure 6.39 Recursion Problem

Cc959340.CNCF29(en-us,TechNet.10).gif

Figure 6.40 Zone Transfer Fails

Cc959340.CNCF30(en-us,TechNet.10).gif

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-iconNote

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.