Autonomic quiescing of unresponsive name servers

In addition to specifying a failure threshold percentage on the UNRESPONSIVETHRESHOLD resolver setup statement, you can also specify the AUTOQUIESCE operand. If you specify the AUTOQUIESCE operand, in addition to network operator notification, the resolver stops sending DNS queries that are generated by an application to the unresponsive name server. While a name server is considered to be unresponsive, the resolver sends DNS polling queries to the name server every 6 seconds. When the name server is responsive to the resolver's DNS polling queries, the resolver resumes sending DNS queries that are generated by an application to the name server. The autonomic quiescing of unresponsive name servers function collects name-server statistics in intervals of 30 seconds, but makes decisions based on no more than two monitoring intervals.

Guideline: If all name servers specified on the TCPIP.DATA NSINTERADDR statements are unresponsive, the resolver sends DNS queries that are generated by an application to those name servers; the resolver does not fail the application queries immediately.

Restriction: If you specify the AUTOQUIESCE operand on the UNRESPONSIVETHRESHOLD statement, you must also specify the GLOBALTCPIPDATA statement. If you do not specify the GLOBALTCPIPDATA statement, the resolver issues message EZD2036I and ignores the AUTOQUIESCE operand. The resolver operates as if you requested the network operator notification function. For more information about the UNRESPONSIVETHRESHOLD statement, see z/OS Communications Server: IP Configuration Reference.

If you use multiple TCP/IP stacks in a common INET (CINET) environment, you must ensure that the IP addresses of the name servers that are specified in the global TCPIP.DATA file are accessible from all TCP/IP stacks. If a name server IP address is accessible only from a specific TCP/IP stack, the autonomic quiescing function could mistakenly consider that name server as unresponsive to DNS queries. For example, consider two TCP/IP stacks, TCPIP1 and TCPIP2, where the IP address for DNS1 is accessible using only TCPIP1 and the IP address for DNS2 is accessible using only TCPIP2. If the NSINTERADDR statement in the global TCPIP.DATA specifies DNS1 and DNS2, in that order, any application DNS queries with stack affinity to TCPIP2 results in DNS query failures to DNS1 because the IP address for DNS1 is not accessible using TCPIP2. If there is a sufficient volume of these queries with stack affinity to TCPIP2, or the UNRESPONSIVETHRESHOLD value is very small, the resolver might decide that DNS1 is unresponsive and stop using it temporarily, resulting in unnecessary failures for application DNS queries that use TCPIP1.

Guideline: If you cannot ensure that all DNS IP addresses are accessible from all your TCP/IP stacks, you should not use a global TCPIP.DATA file, and you should not code AUTOQUIESCE on the UNRESPONSIVETHRESHOLD setup statement in your resolver setup file.