Bug #47757 for dhcp-public: DHCP-4.4 is using TCP instead of UDP for DNS dynamic updates (DDNS) [ISC-support #13028]

As reported to ISC Support: In the following code of dhcp3/common/dns.c:ddns_modify_fwd() /* send the message, cleanup and return the result */ result = ddns_update(dhcp_gbl_ctx.dnsclient, dns_rdataclass_in, zname, &prereqlist, &updatelist, zlist, tsec_key, DNS_CLIENTRESOPT_ALLOWRUN, dhcp_gbl_ctx.task, ddns_interlude, (void *)ddns_cb, &ddns_cb->transaction); I suspect 'DNS_CLIENTRESOPT_ALLOWRUN' should actually be 0. ddns_update() is essentially a wrapper for dns_client_startupdate(), and according to its documentation contained in the tar ball of BIND-9.11.2-P1, the options should be named 'DNS_CLIENTUPDOPT_xxx'. Besides, ALLOWRUN flags seem to only matter for the 'synchronous' mode (e.g. dns_client_update()) so it shouldn't make much sense anyway. Previously, such as in DHCP-4.3.3, it didn't have any real effect since it used older versions of BIND 9 libdns that doesn't recognized any options in dns_client_startupdate(). But it now uses BIND 9.11.2, which has a couple of options for dns_client_startupdate(), and the value of DNS_CLIENTRESOPT_ALLOWRUN is actually the same as DNS_CLIENTUPDOPT_TCP. So it would now change the behavior. Note: this is just an observation from code inspection I happen to notice when I tried to run an older ISC-DHCP with newer BIND 9 library. But it looks like the self-contained DHCP-4.3.3 has the same issue.

---

Summary: Since it's release DHCP 4.4.1 has been using TCP transport instead of UDP when sending DDNS updates. This was unintentional and due to a long-standing error in the options being passed to the BIND library procedure dns_client_startupdate() that was only exposed by linking DHCP with a newer version of BIND. Until BIND 9.11, the incorrectly coded option was ignored because it did not map to an active option in the older versions of dns_client_startupdate(). The DNS updates were performed as expected, and all system tests passed. From BIND 9.11, when calling dns_client_startupdate(). the incorrect option now maps to a request to use TCP instead of UDP for the underlying socket protocol (DNS_CLIENTUPDOPT_TCP). As you would anticipate, in a properly-configured network environment that permits the DNS protocol to use TCP as well as UDP transport, the DNS updates completed as they had been doing when they used UDP, and all system tests passed. We will not be fixing the now-exposed defect until the next maintenance release of DHCP 4.4, so until then, a source code patch will be provided here for download by anyone who needs to revert the behaviour. ---- Note that it is not expected that this change from using UDP to using TCP will negatively impact the vast majority of production environments. The most likely (but still theoretical) side-effect of this change is a reduction in performance where there is a very high rate of DDNS updates - this being due to the overhead of needing to create and release TCP connections between DHCP and DNS server(s).

---