Content-Transfer-Encoding: binary Date: Mon, 11 Jun 2018 15:20:00 +0000 MIME-Version: 1.0 To: dhcp-public@isc.org Content-Disposition: inline Subject: Non-deterministic DDNS update results with multi-IA IPv6 address assignment [ISC-support #13029] # Message-ID: Content-Type: text/plain; charset="utf-8" X-RT-Interface: Web From: cathya@isc.org X-Mailer: MIME-tools 5.508 (Entity 5.508) X-RT-Original-Encoding: utf-8 Content-Length: 2405 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.