Bug #47763 for dhcp-public: Non-deterministic DDNS update results with multi-IA IPv6 address assignment [ISC-support #13029] #

As received by Support Team. I'm not sure - but this might be to do with asynchronous DDNS, introduced in 4.2.0? I haven't checked which 'older' version of ISC DHCP is in use. Since also we ship BIND with DHCP and have tested the specific version of BIND we shipped with the DHCP that is including it, there's also an element of "so don't do that" that might need to be said. The customer querying this writes to us: ----- When I tried to run an older version of the ISC-DHCP server with libdns of BIND 9.11.3-S1, I've noticed a subtle behavior change regarding DDNS update when assigning multiple IPv6 addresses (each in a different IA_NA) in a single DHCPv6 session. I suspect it's the same for DHCP-4.4.1 as it uses BIND 9.11 (I've not tested it myself), and you may want to look into it. Assume the DNS server to which dhcpd sends DDNS update is BIND 9 'named'. Previously (with an older BIND 9 library), in this scenario the DDNS update corresponding to the first IA_NA effectively always "won" and processed by 'named'; the other updates were ignored due to a prerequisite failure. 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). I see two possible issues here: 1. Some of the DDNS updates in this case fail in the first place (common for the new and old behavior). It would be more intuitive if all corresponding AAAA and PTR RRs are added if we assign multiple addresses. 2. Even if there's a reason for making only update request succeed, the more non-deterministic behavior in the current release regarding which one should succeed would be confusing. I don't know the intended behavior in this scenario, but I'd primarily expect all updates to succeed. If it's not intended by design or there's a reason why it's so difficult to implement, I'd at least like to make it more deterministic and (if not yet) should be documented.

---

> Which version of ISC DHCP were you trying to run with the libdns from > BIND 9.11.3-S1? 4.3.3-P1.

---

> 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.

---