Diagnosing unresponsive zones

Messages EZD1278E and EZD1257I indicate when a zone is unresponsive and identify an unresponsive zone. An unresponsive zone does not accept updates or queries for information from ADNR. Unresponsive zones cause other symptoms, such as zones in a name server not being updated at all, or failure of the zone to contain up-to-date information regarding the status of resources in the sysplex. Use the following information to determine why a zone is not responsive.
  • Issue display commands through the ADNR MODIFY command to determine whether the name server is responding. A name server managed by ADNR can be comprised of one or more zones. A MODIFY procname,DISPLAY,DNS,DETAIL command shows a count of the number of zones defined under a dns statement and a count of the number of zones under that dns statement that are active. When all of the zones managed by a DNS server controlled by ADNR are not responding then the DNS server is considered dead. ADNR makes periodic probes to determine whether the zones for a dead server respond positively.
  • Verify that the DNS server being used supports RFC 2136, Dynamic Updates in the Domain Name System (DNS UPDATE)). Review your DNS server's documentation.
  • Verify the DNS name server is running and responsive by issuing the dig or nsupdate command for the zone. If it is not running then start the DNS server. See z/OS Communications Server: IP System Administrator's Commands, Querying and administrating a Domain Name System (DNS), for guidance on using the nslookup, dig and nsupdate commnands.
  • Verify that network connectivity exists for the DNS server as it must be listening on the IP address and port number specified by the server parameter value (IP address) of the dns statement in the ADNR configuration. Unexpected loss of network connectivity for the DNS server will result in a console message and related messages in the DNS log. Correct the underlying network connectivity problem. For guidance on using Netstat commands see z/OS Communications Server: IP System Administrator's Commands.
  • Review your firewall's log files to verify a firewall is not blocking communications between the system where ADNR resides and the name server on the port where the name server is listening for queries.
  • Verify the name server being used is listening at the IP address and port that is specified by the dns_id parameter of the dns statement in the ADNR configuration file. For DNS BIND9, the IP addresses and ports the DNS server will listen on may be specified by the listen-on and listen-on-v6 DNS option statements.
  • Verify that the name server IP address, optional port, zone domain suffix names, and optional Transaction Signature (TSIG) keys are correctly specified in the ADNR configuration file.
  • Verify that the DNS name server specified in the ADNR dns statement actually manages the zone specified by the domain_suffix parameter of the ADNR dns statement and is the authoritative, primary master name server for the zone. For DNS BIND9 on the name server's zone configuration statement, the type master option is used to specify that the server is an authoritative master. See BIND 9-based domain name system (DNS), z/OS Communications Server: IP Configuration Reference, configuration file statements, for guidance on coding the name server's configuration. The name server managing this zone must be configured for the specified zone before ADNR can add DNS records to it. ADNR cannot dynamically create a zone in a name server. It can only add records to a zone that already exists.
  • Verify that ADNR has the authority to manage the DNS resource records contained in this zone including the authority to request and receive zone transfers and perform dynamic updates. See Automated Domain Name Registration in z/OS Communications Server: IP Configuration Guide, for guidance on authorizing ADNR.
  • Verify that the transaction security (TSIG) keys represented in the update and transfer keys (if specified in the ADNR configuration file) match those specified in the DNS name server for the zones ADNR is managing.
  • Verify that the name server is configured with the same key names that ADNR is configured to use for the zone. Even if the name server configuration does not require a key to update or transfer an ADNR managed zone, the keys must at least be configured to the name server if ADNR is configured to use a key for that zone. If your security policies do not require you to use an update or a transfer key, they should be removed from the ADNR configuration, otherwise, the keys should be configured to the name server and used to restrict which entities are allowed to update the zone and request zone transfers.
  • Verify that the name server's working directory did not run out of disk space. ADNR makes dynamic updates to name severs. Many name server implementations require that dynamic updates be written to disk. If a name server is unable to do this, the dynamic updates from ADNR will fail causing the zone to go unresponsive. In this case, the zone emerges from the unresponsive state spontaneously, but again returns to the unresponsive state. This cycle will repeat until the storage problem on the name server host is corrected
  • Verify that the zone specified on the zone_label keyword of the ADNR dns configuration statement is not a DNSSEC signed zone. ADNR does not support the use of zones signed by DNSSEC.
  • Verify that OMVS has not run out of file descriptors. See the DISPLAY OMVS command in z/OS MVS System Commands for information about how to make this determination.
Parent topic: Diagnosing ADNR problems