X-RT-Original-Encoding: utf-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary In-Reply-To: MIME-Version: 1.0 References: X-Mailer: MIME-tools 5.508 (Entity 5.508) Message-ID: Content-Disposition: inline X-RT-Interface: Web RT-Send-CC: Content-Length: 1588 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).