samba - Dec 2021 - DNS PTR update fails if IP is reused by another client

I have re-installed Windows 10 on one of my domain client machines, and it has
received the same IP address as before.   I renamed the machine and joined it to
the domain.  But I am now getting log messages like this:

 

Dec 11 09:42:32 rpi3-dc named[477172]: samba_dlz: disallowing update of
signer=LION\$\@MICROLYNX.ORG name=79.2.168.192.in-addr.arpa type=PTR
error=insufficient access rights

 

Searching the web for clues I found this web page:

 

https://forge.univention.org/bugzilla/show_bug.cgi?id=39806

 

which seems the same problem I am experiencing.   So could tombstone records be
causing this?   If so is there a workaround?

 

I have checked the permissions on the reverse zone and Authenticated Users has
rights to create child objects.    I added Domain Computers as well to make sure
(as I believe Domain Computers are members of Authenticate Users) but that did
not resolve the issue.

 

The DC is running samba version 4.15.2 on Debian Bullseye with bind_dlz dns
backend.  Bind9 is version 9.16.22-Debian

 

Thanks,

 

Roy

On Sat, 2021-12-11 at 11:47 +0000, spindles seven via samba
wrote:
> I have re-installed Windows 10 on one of my domain client machines,
> and it has received the same IP address as before.   I renamed the
> machine and joined it to the domain.  But I am now getting log
> messages like this:
> 
>  
> 
> Dec 11 09:42:32 rpi3-dc named[477172]: samba_dlz: disallowing update
> of signer=LION\$\@MICROLYNX.ORG name=79.2.168.192.in-addr.arpa
> type=PTR error=insufficient access rights
> 
>  
> 
> Searching the web for clues I found this web page:
> 
>  
> 
> https://forge.univention.org/bugzilla/show_bug.cgi?id=39806
> 
>  
> 
> which seems the same problem I am experiencing.   So could tombstone
> records be causing this?
I personally think the 'tombstone' is a bit of a red herring. If you
re-install a machine with the same name, ip etc, even if it looks like
the same machine to you, to Windows it is a different machine and that
new machine will not be able to alter any records for the old machine.
>    If so is there a workaround?
You could try deleting the old records and let your new machine create
new ones.

Rowland