X-Mailer: MIME-tools 5.508 (Entity 5.508) Content-Disposition: inline MIME-Version: 1.0 References: Message-ID: X-RT-Interface: Web Content-Transfer-Encoding: binary Content-Type: text/plain; charset="utf-8" In-Reply-To: X-RT-Original-Encoding: utf-8 RT-Send-CC: Content-Length: 2825 > With libdns of BIND 9.11, it now becomes more non-deterministic. > Sometimes the first update wins, sometimes an update of some other > IA_NA wins. This seems to because of a subtle difference in libdns's > dns_client_startupdate() between 9.10.2 and 9.11.3. Previously the > update message was sent out in the same task event as the task for > committing the lease. In 9.11.3-S1, it's run on a separate task event, > and it's more likely that the multiple DDNS request messages reach > 'named' almost at the same timing (and determining the "winner" is > more susceptible to the task scheduling). The relevant change(s) are these: In BIND 9.9.10, 9.10.5, 9.11.1, 9.12.0: 4543. [bug] dns_client_startupdate now delays sending the update request until isc_app_ctxrun has been called. [RT #43976] This change was then updated by this fix in BIND 9.9.11, 9.10.6, 9.11.2, 9.12.0 4629. [bug] dns_client_startupdate could not be called with a running client. [RT #45277] (Note that change 4629 is needed for successful integration BIND's libdns with DHCP from a version of BIND that has change 4543). As pointed out by the submitter, using newer BIND libs with the two changes above means that a series of DDNS updates submitted when assigning multiple IPv6 addresses (each in a different IA_NA are unlikely to be sent to the DNS server in the same sequence in which they were submitted to the asynchronous DDNS handler Prior to the change, the outcome would still have been unpredictable because DDNS travels over UDP, so the arrival sequence of updates is not guaranteed to be the same as the sending sequence, but the updates were, nevertheless, most likely to be arriving, ordered as they had been sent. A (near) predictable ordering or updates is no longer occurring when linking with the new BIND libdns, irrespective of which version of DHCP is passing the updates over to dns_client_startupdate(). ---- It is technically challenging to address this problem from the DHCP perspective because of the handoff between DHCP and the BIND libs that handle the actual mechanics of sending DDNS updates. One could argue that the 'right' solution would be for DHCP DDNS to create multiple IPv6 records for the same hostname (which would require the update to assemble the full RRset and add them in a single DDNS transaction.) We consider this proposed 'right' solution to be very much a new feature. IF it is wanted, then a very strong business case would need to be made for it to be added to ISC DHCP (as opposed to Kea DHCP). ---- Therefore the recommended fix for this situation would be to have DHCP process the first (or last) IA_NA for DDNS and discard all other potential DDNS updates. Also needed is an update to the documentation to explain the limitations of the DDNS response to this scenario.