Debian Buster, Samba 4.10.6 ( and lower )
Related bugzilla report: 13945
When you add a NS record as shown below.
samba-tool dns add <Your-AD-DNS-Server-IP-or-hostname> samdom.example.com @ NS newdc.sambdom.example.com
This is all correct in the zones.
But if i add a new NS records with windows DNS tool, i get the extra "tld" in the reverse zone. which is unaccessable and make looking in the zone fail.
Untill you refresh in "zones for for reverse lookup"
steps to reproduce.
Open DNS tool, goto the reverse zone, right klik, get properties.
Goto Nameserver tab, and add an other DC.
check the reverse zone.
The same happens in the forward zone, but that gives an extra "tld/domain/tld/domain" in the forward zone.
Adding these with samba tool results in a correct zone with correct NS servers in it. ( reverse and forward zones are affected )
I also noticed, if you added the second NS with the DNS tools and you remove it with samba-tool and readded it with samba tool, the "tld" is not removed.
you must remove the extra ns record first with windows DNS tool again before you re-add it with samba-tool.
then is correct in the DNS again.
Servers running since 4.1.x upgrade all the way to 4.10.6 now.
I've done some extra testing.
One of my oldest zones, a forward zone, also contained an extra part "tld"
my setup is as followed.
primaryZone internal.domain.tld , the AD-DCs are the autoritive servers,
with an extra zone domain.tld
These were created in 2015.
This year (running samba 4.10.x), i added the extra NS record which resulted in the "tld" part in the zone.
Today i removed the complete zone with samba-tool and re-added it again with samba-tool incl. the seconds NS records, this all looks correct.
Now i removed the second NS record and re-added it with the windows tool.
resulting in an extra "internal" folder in the "domain.tld" zone.
removing it again and re-adding the second NS with samba-tool also removed the "internal" part from "domain.tld"
This was done with a Windows 7 pc and AD DNS tool.
while typing this, i noticed the close of :
13969 dnsProperty fails to decode values from older Windows versions
A related bug?