Skip to content

Troubleshooting

Jump to bottom
Jayson Hurst edited this page Jan 10, 2018 · 1 revision

Troubleshooting dnsupdate

This document covers common problems and fixes with dnsupdate.

Steps taken by dnsupdate

This section explains the process that dnsupdate follows when updating DNS records.

  1. Look for the file /etc/opt/quest/dnsupdate.conf and if it exists, read configuration options from it. Options given on the command line have priority.
  2. If option 'RegistrationEnabled' is 0, then exit immediately.
  3. Initialise the random transaction ID:
    • If the file /dev/random exists, read data from that; otherwise
    • Use the system clock and the C pseudo-random number generator.
  4. If option UpdateSecurityLevel is not "unsecure only" (16), then try to obtain the host credentials from /etc/opt/quest/vas/host.keytab. If this fails, and the UpdateSecurityLevel is "secure only" then fail.
  5. Determine the hostname being registered:
    • If the -h option was given, use that; otherwise
    • If secure updates were not disabled, and One Identity Authentication Services (QAS) is configured, then ask QAS for the fully qualified hostname with which it was configured; otherwise
    • Query the operating system for its hostname, then fully qualify it by performing a forward lookup using the system resolver (gethostbyname) and using the h_name response.
  6. If the determined hostname doesn't contain any dots, then append either
    • the authoritative domain given by the -a option; otherwise
    • the domain name given in the 'domain' entry in resolv.conf; or
    • the first domain from the 'search' entry given in resolv.conf; or
    • leave it alone.
  7. Connect to the system nameserver, which is the first connectable host specified by the 'nameserver' entry/ies in resolv.conf
  8. Determine the list of nameservers to try updating the A record:
    • If the -n option was given, use the space-separated list of addresses as the nameserver list; otherwise
    • Query the system nameserver for the SOA record associated with the hostname being registered. This yields the name of the 'primary nameserver' which holds the master copy of the domain. If the query is successful, set the list of nameservers to try to just the primary nameserver, and remember the authoritative domain as returned in the SOA record; otherwise
    • Set the list of nameservers to the list of Active Directory controllers discovered by One Identity Authentication Services; otherwise
    • Set the list of nameservers to the 'nameserver' entries in resolv.conf.
  9. Determine the authoritative domain name. This is either:
    • Specified by an -a option; or
    • Discovered through the prior SOA request; or
    • Set to the domain resulting from removing the first component of the hostname being registered. For example, if the hostname is unix.example.com, the authoritative domain name will be example.com.
  10. Check the authoritative domain name is not a single name (like "com"), unless option 'UpdateTopLevelDomainZones' is set.
  11. For each nameserver in the list of nameservers, try the following steps:
    1. Try connecting to the nameserver.
    2. Try an unsecure update of the A record. If that succeeds, then we are done.
    3. Try a secure update of the A record by computing a GSS TSIG (GSSAPI signature). If that succeeds then we are done.
    4. If we failed to update against the primary nameserver from the SOA query, then make an NS query to find all the slave nameservers for the domain. If that succeeds, restart this loop using the slaves as the list of nameservers.
  12. If the RegisterReverseLookup option permits it, repeat from step 8, but for the PTR record. In this case the hostname being registered is now the in-addr.arpa domain name for the IP address, and instead of registering an A record, we register a PTR record. For example: if the IP address 1.2.3.4, then the hostname to register a PTR record will be 4.3.2.1.in-addr.arpa.
Clone this wiki locally