Customizing the z/OS Communications Server IP Resolver

Answer

Background

Since z/OS V1R10, the Communications Server IP Resolver has been enhanced with several new functions. Most new functions are active by default and providing benefits whether or not you have customized the Resolver address space which you have been using ever since it was introduced with z/OS V1R2. For one of these functions, Extension Mechanisms for Domain Name System (DNS) (EDNS0) standards, no customization is appropriate since support for the enhanced capabilities of the name server is determined dynamically by the resolver. The other two functions, caching of information from resolved DNS queries and monitoring responsiveness level of DNS name servers, provide mechanisms for adjusting resolver operations for your environment.

In order to customize resolver functions, you must create a resolver procedure and a data set or file to contain the necessary resolver setup statements. Directions on creating the necessary procedure and file can be found in the IBM Technote Customizing the z/OS RESOLVER.

Customizing the Resolver Caching function

In z/OS V1R11 Communications Server, the resolver was enhanced to locally cache the results of resolved DNS queries. Resolver caching provides significant performance improvements over both the existing resolver query processing and the use of a local caching-only DNS name server. Two customization options are provided with the Resolver Caching function: the size of the local resolver cache (CACHESIZE), and the maximum duration an entry can remain in the resolver cache (MAXTTL).

The caching function by default uses up to 200 megabytes for the resolver cache, which represents approximately 80,000 possible resolver cache entries. It is unlikely that you will need to customize this storage limit:
• The 200 megabytes of storage is an upper boundary on the storage the resolver uses; the resolver does not reserve all 200 megabytes at once, but rather obtains only the storage needed to hold the current set of active cache entries.
• Expired entries are deleted by the resolver within 10 minutes, so resolver operations will naturally maintain primarily current information.
• The cache storage is allocated as 64-bit addressable, or “above the bar”, storage within the resolver address space, and thus is not a critical resource in need of close monitoring.

The caching function by default maintains a cache entry for the length of time specified by the DNS name server on the response data. The duration value, called the Time-to-Live (TTL), is defined for each entry at the DNS name server. A large TTL value can cause entries to remain in the cache for hours, days, even weeks, regardless of how often the information is used. You should strongly consider specifying a maximum time for how long the resolver leaves information in the cache, overriding when appropriate the value provided by the DNS name server for a given resource. This not only forces the resolver to periodically obtain the latest information about a resource, but also allows the resolver to more rapidly discard old, unused cache entries.

You can also turn off the caching function on a system-wide basis using the NOCACHE setup statement, but the significant performance improvements make it unlikely that you will not benefit from using the caching function.

For details of how to control the operation of the resolver caching function, please see the appended manual references.

Customizing the Monitoring Responsiveness level of DNS name servers function

In z/OS V1R12 Communications Server, the resolver was enhanced to monitor name server responsiveness and to alert the operator of name servers that were failing to respond to a significant percentage of resolver queries. The name server monitoring function provides notification of potential network or name server problems that can cause system performance issues. You can customize the error rate percentage used by the resolver to declare that a name server is unresponsive.

By default, the resolver alerts the operator when a name server fails to respond to more than 25% of the total resolver queries sent to the name server during a sliding 5-minute interval. Based on factors such as the value coded for the RESOLVERTIMEOUT statement in the TCPIP.DATA file and the level of network congestion, a 25% threshold rate might generate too few or too many alerts to be useful to the operator. You can specify a threshold value that is more appropriate for your environment using the UNRESPONSIVETHRESHOLD setup statement in the resolver setup file. For suggestions on how to select an appropriate threshold value for your environment, please see the appended manual references.

You can also turn off the name server monitoring by specifying a value of 0 for the UNRESPONSIVETHRESHOLD setup statement.

For details of how to control the operation of the monitoring responsiveness level of DNS name servers, please see the appended manual references.

Other useful customization

You may benefit from two other possibilities which have been available to you prior to z/OS V1R10:

1. At a minimum, the TCPIP.DATA statements relating to the use of name servers can be concentrated in the data set or file specified as the value of the resolver setup statement GLOBALTCPIPDATA. Using a global TCPIP.DATA file avoids problems of change control possibly caused by proliferation of other means to specify TCPIP.DATA statements, typically by means of SYSTCPD DD-statements. You can choose to specify the remaining TCPIP.DATA statements in the same data set or file, or alternatively allow individual users or applications to customize the remaining TCPIP.DATA statements for their unique conditions.

2. One very popular use of a customized Resolver address space is to specify the Resolver setup statement COMMONSEARCH so that the "ipnodes" format can be used for a local host table across all programming API's and for all resolver queries. The “ipnodes” format is a replacement for the original RFC 952 format and z/OS UNIX /etc/hosts format for local host tables. There are two benefits to the “ipnodes” format:

◦ The RFC 952 format requires you to convert the source data set into two files in a format which allowed early implementations to process queries more efficiently than the source data set itself would have permitted. The “ipnodes” format does not require any conversion steps prior to use with the resolver.
◦ The “ipnodes” format must be used to define IPv6 addresses.

Because the use of the function based on the RFC 952 format and z/OS UNIX format was already established prior to the introduction of the “ipnodes” format, by default the resolver searches for local host files using either the RFC 952 format or z/OS UNIX format when performing a query for an Ipv4 resource. Those same files, if defined, cannot be used for queries involving an IPv6 resource, so you could end up with multiple definition files. Specifying the COMMONSEARCH resolver setup statement instructs the resolver to search only for “ipnodes” format files for all queries, allowing you to code all local host definitions in just one file.

If COMMONSEARCH is specified in your Resolver setup file, there is also the opportunity to use the Resolver setup statements GLOBALIPNODES or DEFAULTIPNODES. The GLOBALIPNODES statement defines a system-wide “ipnodes” format file for all applications. The DEFAULTIPNODES statement defines an “ipnodes” format file to be used when the resolver does not find another local host table using the appropriate search order rules.

If the local host table is to be preferred over communication to a name server, whether derived from the RFC 952 format, z/OS UNIX format or using the "ipnodes" format, the order of host name and address resolution defined by the TCPIP.DATA statement LOOKUP needs to be changed from LOOKUP DNS LOCAL, the default, to LOOKUP LOCAL or LOOKUP LOCAL DNS.

Again, please see the appended manual references for full details of these other possible uses for a customized Resolver address space.

-

The manual references for this topic are the following:

- Chapter 14, "The resolver", in z/OS V1R12 Communications Server IP Configuration Guide

- Chapter 5, "TCP/IP Customization, Configuring the local host table (optional)", in z/OS V1R12 Communications Server IP Configuration Guide

- Chapter 5, "Resolver setup and TCPIP.DATA configuration statements" in z/OS V1R12 Communications Server IP Configuration Reference