IBM Support

Understanding how the z/OS Communications Server IP resolver queries DNS for a host name to IP address resolution

Question & Answer


Question

How do z/OS Communications Server TCPIP.DATA statements impact the method and amount of time that a host name resolution can take? The following describes the case of the resolver using UDP to send DNS queries to resolve a host name to its IP addresses.

Answer

The default behavior of the z/OS Communications Server resolver is to attempt to use any configured Domain Name Servers (DNS) for resolution requests. If the resolution request cannot be satisfied by the DNS or if no DNS usage is indicated then local host tables are used.

Starting with z/OS V1R11 the resolver supports caching of DNS responses. If the host name data is in the cache the cache contents will be used for completing the resolution request. In order to populate the cache a DNS needs to respond to a resolver query; that processing is described below. See the z/OS Communications Server IP Configuration Guide for information on resolver caching.



The following describes the common usage of UDP (the ResolveVia UDP TCPIP.DATA statement) to query Domain Name Servers (DNS) to resolve a host name to its IP addresses.

The following TCPIP.DATA statements can influence the amount of time it takes to resolve a host name:
  • The number of domain names in the SEARCH list
  • The number of DNSs to query (NameServer/NSInterAddr)
  • The number of "dots" in a name before it is considered a fully-qualified name (OPTIONS ndots:)
  • The time to wait for a DNS response (ResolverTimeOut)
  • The number of times to try the list of DNS (ResolverUDPRetries)

In addition, with the IPv6 resolver API support, a single request can generate queries for both an IPv4 resource and an IPv6 resource. Each use the logic in the following example for querying the DNS.

This example is for a GetAddrInfo API call to obtain an IPv4 address. Assume that the default of OPTIONS ndots:1 is used and that the input host name contains no dots.

The resolver builds a DNS query containing the fully-qualified domain name (FQDN) for the requested host name. Based on our assumptions, it does that in the following manner:

1. The resolver adds a domain name to the application input. The domain name is either specified by the DomainOrigin statement value or by the list of domain names specified by the SEARCH statement. If SEARCH is specified, the resolver starts with the first domain name specified by the search list, then uses the remaining domain names until the name is resolved by a DNS or until the list of domain names is exhausted.

2. The FQDN query is then sent using a UDP sendto to the first DNS IP address configured.
  • If the name server replies NOERROR, the resolution is complete and the resolution attempts terminate.
  • If the name server replies NXDOMAIN, the resolution attempt of this FQDN terminates. If there are other domain names in the SEARCH list, a new FQDN is created and another UDP sendto is performed.
  • If the query times out or a SERVFAIL reply or a REFUSED reply is received, the next name server, if any, is tried with the current FQDN. If the name servers all time out, the current query is tried again with the same list of DNS until the ResolverUDPRetries value is reached. (Note that ResolverUDPRetries is the total number of attempts to contact a DNS, not just the number of retries.) If the ResolverUDPRetries value is reached and all the name servers have timed out, the resolution is terminated, even if there are additional domain names in the SEARCH list specification.

3. If after trying all FQDN and the name is not resolved, the resolver tries one last DNS query specifying the original name as presented across the API as the FQDN.

4. If none of the DNS queries resolve the name, the resolver tries local host tables as determined by the API environment of the call (for example, Native MVS or z/OS UNIX).

See the z/OS Communications Server IP Configuration Guide for the Native MVS environment local host tables' search order and z/OS UNIX environment local host tables' search order.

See the z/OS Communications Server IP Configuration Reference for a description of TCPIP.DATA statements.

[{"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Business Unit":{"code":"BU009","label":"Systems - Server"},"Component":"All","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"1.6;1.7;1.8;1.9;1.10;1.11;1.12;1.13;2.1;2.2","Edition":""}]

Document Information

Modified date:
15 June 2018

UID

swg21115689