samba - Feb 2021 - Conflict entries in DNS with DHCP and dynamic DNS updates 

I have the same here with isc-dhcpd-4.4.1 on Debian/RapsberryOS.

I think it's is a bug in the ISC DHCP server when it runs in failover
pair mode:

Whenever a node asks for a lease and that node is already known to both
DHCP servers then both send a response (luckily the same response), and
as a consequence both DHCP servers send an update do DNS.

If a node with a still unknown MAC address asks for a lease the very
first time then only one of the two servers responds.

Do you see the same behaviour?

Regards,
Norbert

On 18.02.2021 19:16, Samba Fan via samba wrote:
> It is about DNS updates through the ISC DHCP server failover cluster in a
Samba 4 Active Directory environment. I have implemented this as described in
the Samba wiki
(https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records_with_BIND9).
>
> The failover works fine from the outside. However, the script (I use
version 0.9.2) is executed on both servers at the same time (event "on
commit"). This has the effect that a DNS record is created on both servers
at the same time, if it did not already exist. This creates "conflict
records" in both the forward and reverse zones, which the DNS then resolves
so that one of them appears as hostname\nCNF:UID or ip-address\nCNF:UID in the
forward zone or reverse zone, respectively.
>
> The name resolution in both directions works, because the correct entries
are in the DNS. However, the "useless" CNF entries remain. What can I
set or check? How can I prevent these CNF entries? I have not found an answer
yet.
>
> These are the operating systems and versions of the software packages
involved:
> Server operating system: Ubuntu 16.04.7 LTS
> Samba: Version 4.3.11-Ubuntu
> DNS: BIND 9.10.3-P4-Ubuntu
> DHCP: ISC DHCP Server version 4.3.3
> Operating system of DHCP clients: Windows 10 1909 (DHCP updates by clients
are disabled)
>
> Regards, Sambafan
> P
>

@Norbert: I can't confirm that. My observation states that a commit event is
executed on both DHCP nodes, even if only one of them executes or sends a
DHCP-OFFER. This observation is based on the log. I have not analyzed it with
wireshark.

I have to agree with Rowland that it is not a DynDNS update script problem.

 However, the execution of the commit on both peers must not be a bug, because
both peers must be aware of each other's leases and write them to the local
lease database.

If anyone has an idea how to determine whether the primary node or the secondary
node has been assigned responsibility for the lease and how to query that when
the on-commit event is executed, a possible solution would be in sight.

Currently, as a workaround, I use the query for a possible "CNF entry"
when executing the on-expiry event, and then delete that entry as well.

Thank you very much for this discussion!