Symptom:

RFC compliant dynamic DNS (not DDNS based on external updates like a HTTP channel) can be complicated to troubleshoot. Below is a simplified description of the dynamic update process with information of common issues in each step that can lead to a dynamic DNS update failure.

It is very important when troubleshooting dynamic updates on Unix BIND or MS DNS Servers to have DNS logging enabled, esp. to see the Update, Notify and Zonetransfer pakets in the logs.

Problem:

1. the DHCP Server sends the dynamic update including certain prerequisites to the IP Address which is resolved for the mname field in the SOA record for the dynamic zone.
   what can go wrong in this step:
   1. the mname field of the SOA record does not contain the correct hostname of the master dns server for the zone)
   2. the hostname in the mname field cannot be resolved to an IP Address or is resolved to the wrong IP address. This can happen if the local resolver configuration (resolv.conf) on the DHCP Server points to a different DNS structure then the one being updated
       
2. the master DNS Server for the reverse zone accepts the dynamic update, updates the zone in memory and writes the change to the Journal (jnl) file
   what can go wrong in this step:
   1. the prerequisites send by the DHCP Server for the update do not match, dynamic update is not accepted
   2. the DNS Server has no access rights on the file system to write or create a Journal file
       
3. the master DNS Server that has updated the zone will look into the NS records for this zone, will remove the NS records with its own hostname from the list (some BIND versions have a bug here which will result in an notify send to itself) and will resolve the hostnames in all remaining NS records to IP Addresses and then send a notify package to these IP Addresses
   what can go wrong in this step:
   1. notify is disabled in the DNS Servers configuration
   2. the NS records do not list the correct hostnames for the slave DNS Servers
   3.  the hostnames in the NS records do not resolve to correct IP Addresses
   4.  a Firewall stops the notify messages
       
4. each slave DNS Server will receive the notify packet. The slave DNS Server will check if its hosting the zone the notify is for, and if source ip address of the notify is the same ip address configured for the "masters" statement of the zone
   what can go wrong in this step:
   1. the slave DNS Server is not hosting the zone
   2. the source IP Address is different from the IP address listed in the "masters" statement of the zone configuration (NAT?)
       
5. the slave DNS Server will schedule a refresh cycle for the zone. It will lookup the SOA record on the master for the zone and will compare the serial number on the master with the serial number in its copy of the zone. If the serial number on the master is higher, it will initiate a IXFR (incremental zone transfer) from the DNS server configured in the "masters" statement of the zone
   what can go wrong in this step:
   1. the SOA records cannot be retrieved from the master
   2. the SOA record retrieved is not the SOA from the master
   3. the master does not permit zonetransfer to the slave DNS Server
   4.  the slave DNS server cannot create a zonefile or a journalfile for the IXFR changes received due to incorrect file system permissions
       

 

Solution

To troubleshoot this process, enable query logging, update logging, xfer in/out logging and notify logging on all DNS Servers that host the zone and verify that the flow of DNS packets described in steps 1-5 can be seen in the logs in the correct order.