Steps for resolving caching problems

Determine whether a hostname contains inaccurate information in the resolver cache.

Before you begin

You need to know the exact hostname that is suspected to have inaccurate information in the resolver cache, and the environment in which the application was running (for example, TSO, UNIX, or batch).

Procedure

  1. Determine whether the resolver cache contains any information about the host name, using the Netstat RESCache/-q report. The following command can be used to display information about the host name (which in this example is www.johndoe.com):
    netstat -q DETAIL -H www.john.doe

    The command should display all entries that exist in the resolver cache because of hostname-to-IP address resolution requests for www.johndoe.com. For more information about the Netstat RESCache/-q report, see z/OS Communications Server: IP System Administrator's Commands.

  2. Determine, using the dig command, if the name or address being queried is known to the DNS name server if you expect to resolve the hostname using DNS. The following example looks for the name www.johndoe.com from the DNS at IP address 1.2.3.4:
    dig@1.2.3.4 www.johndoe.com -t any
    The command should return all resource records of any type from the DNS at 1.2.3.4 for www.johndoe.com. For more information about dig, see z/OS Communications Server: IP System Administrator's Commands. The DNS name server to use for this search is the first name server listed in the NSINTERADDR list of name servers in the TCPIP.DATA data set used by the application experiencing the problems. For more information about NSINTERADDR, see z/OS Communications Server: IP Configuration Reference.
  3. Base your next course of action on the results of the dig command:
    If . . . Then . . . Solution
    Dig fails because it cannot contact DNS You need to check your link to the DNS IP address. See Diagnosing network connectivity problems to continue researching the problem.
    Dig fails because DNS reports that the resource was not found www.johndoe.com is not a resource record known to DNS. See the DNS administrator to add the name.
    If dig succeeds, and the resolver cache has different information from what was returned by dig The cache information might be information that was provided by a different name server, or might represent old information that was assigned a time-to-live (TTL) value that was excessive. The application might be acquiring inaccurate information about the hostname due to the resolver cache data. Because the dig command bypasses the resolver cache, the dig command is unaffected by the resolver cache information. To remove the cache information, issue the MODIFY RESOLVER,FLUSH,ALL command to delete all entries from the cache. For more information about MODIFY FLUSH processing, see z/OS Communications Server: IP System Administrator's Commands.
    If dig succeeds, but the resolver cache has the same information as dig, or has no information about the hostname The problem in resolving the hostname using ping or another application might be in configuring the resolver, or might result from the resolver treating the name server as unresponsive. The dig command bypasses the resolver cache, search orders, local host files, and domain names that are appended by the resolver. The best way to check the configuration is to start the Start of changeTrace ResolverEnd of change. It is important to use the Start of changeTrace ResolverEnd of change in the environment where the application is failing because the application might be using a different TCPIP.DATA file, environment variables, or search order than the environment where the dig command was issued.

    The resolver might not be sending DNS queries that are generated by applications because the name server is considered to be unresponsive. See Steps for responding to message EZZ9311E for more information.

  4. If the Trace Resolver output indicates errors in the resolver configuration, issue the MODIFY RESOLVER,DISPLAY command and base your course of action on the following conditions:
    If MODIFY RESOLVER,DISPLAY output . . . Then . . . Solution
    Includes message EZD2039I WARNINGS ISSUED DURING RESOLVER INITIALIZATION The resolver detected syntax errors or unrecognized setup statements when it was processing the resolver setup file statements during address space initialization. These errors might cause the resolver to use different settings than you intended. Correct the errors in the resolver setup file. Issue the MODIFY RESOLVER,REFRESH,SETUP command to correct the resolver configuration.
    Does not include message EZD2039I. No syntax errors were in the resolver setup file. The configuration error might still be a value that is incorrectly specified on a resolver setup statement, or it might be an error in the application TCPIP.DATA file. Correct the errors in the resolver setup file or application TCPIP.DATA file. Issue the MODIFY RESOLVER,REFRESH command to correct the configuration errors.

Results

You know that you are done when the application that previously failed to resolve the host name can now resolve it.