samba - Jun 2020 - several dns issues after switching fsmo roles to samba-dc

Hello,

I've  finally  decided to switch all FSMO roles from Windows 2008 R2 DC
(vm-dc1)
to  one of the two Samba 4.12.3 DCs (vm-dc3). Here are several issues I've
faced
after that:

1.  After  connecting DNS Manager to the all DCs, I've found that the SOA
record
for my domain and msdcs zones still point to the former PDC - vm-dc1.
Is that OK?

2. So, I've changed the SOA manually on the new PDC (vm-dc3) to point to the
new
PDC. This change has been successfully propagated to another Samba DC (vm-dc4),
but the Windows DC still displays itself in the SOA record.
Is that OK?

3. I see the errors in the System log on the former DC (vm-dc1), like:
The dynamic registration of the DNS record
'_ldap._tcp.DomainDnsZones.domain.com. 600 IN SRV 0 100 389
vm-dc1.domain.com.' failed on the following DNS server:

DNS server IP address: 172.26.1.83 
Returned Response Code (RCODE): 0 
Returned Status Code: 9016  
...
ADDITIONAL DATA
Error Value: DNS signature failed to verify.

(172.26.1.83 is the new PDC - vm-dc3)

However, samba logs do not show any errors regarding the RR registration:
https://paste.ee/p/WiJsM

Nevertheless, I see this RR in all DCs with "static" in the timestamp
field.

Why does this error happen?

4. Running dcdiag shows some errors. Not sure if they're major though, b/c
things seem to be working well.
https://www.dropbox.com/t/EpQLVEkyTihLZOqD

Thanks in advance for any feedback!

-- 
Best regards,
Alex

On 01/06/2020 14:40, Alex via samba wrote:
> 1.  After  connecting DNS Manager to the all DCs, I've found that the
SOA record
> for my domain and msdcs zones still point to the former PDC - vm-dc1.
> Is that OK?
Probably, all DC's are authoritative for the domain:

adminuser at dc4:~$ dig soa samdom.example.com

; <<>> DiG 9.10.3-P4-Debian <<>> soa samdom.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46015
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;samdom.example.com.??? ??? IN??? SOA

;; ANSWER SECTION:
samdom.example.com.??? 3600??? IN??? SOA dc4.samdom.example.com. 
hostmaster.samdom.example.com. 235204 900 600 86400 3600

;; AUTHORITY SECTION:
samdom.example.com.??? 900??? IN??? NS??? dc01.samdom.example.com.
samdom.example.com.??? 900??? IN??? NS??? dc4.samdom.example.com.

;; Query time: 0 msec
;; SERVER: 192.168.0.6#53(192.168.0.6)
;; WHEN: Mon Jun 01 15:02:32 BST 2020
;; MSG SIZE? rcvd: 131

root at dc01:~# dig soa samdom.example.com

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> soa
samdom.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56470
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d5970b1b8e8920aa39d839fd5ed50a36c796a503168db04a (good)
;; QUESTION SECTION:
;samdom.example.com.??? ??? IN??? SOA

;; ANSWER SECTION:
samdom.example.com.??? 3600??? IN??? SOA dc01.samdom.example.com. 
hostmaster.samdom.example.com. 235204 900 600 86400 3600

;; AUTHORITY SECTION:
samdom.example.com.??? 900??? IN??? NS??? dc01.samdom.example.com.
samdom.example.com.??? 900??? IN??? NS??? dc4.samdom.example.com.

;; ADDITIONAL SECTION:
dc4.samdom.example.com.??? 900??? IN??? A??? 192.168.0.6
dc01.samdom.example.com. 900??? IN??? A??? 192.168.0.8

;; Query time: 6 msec
;; SERVER: 192.168.0.8#53(192.168.0.8)
;; WHEN: Mon Jun 01 15:01:26 BST 2020
;; MSG SIZE? rcvd: 191
>
> 2. So, I've changed the SOA manually on the new PDC (vm-dc3) to point
to the new
> PDC. This change has been successfully propagated to another Samba DC
(vm-dc4),
> but the Windows DC still displays itself in the SOA record.
> Is that OK?
You shouldn't have to create the record, it should be created by the 
samba_dnsupdate script, this is supposed to run at startup and regular 
intervals thereafter.
> 3. I see the errors in the System log on the former DC (vm-dc1), like:
> The dynamic registration of the DNS record
'_ldap._tcp.DomainDnsZones.domain.com. 600 IN SRV 0 100 389
vm-dc1.domain.com.' failed on the following DNS server:
>
> DNS server IP address: 172.26.1.83
> Returned Response Code (RCODE): 0
> Returned Status Code: 9016
> ...
> ADDITIONAL DATA
> Error Value: DNS signature failed to verify.
>
> (172.26.1.83 is the new PDC - vm-dc3)
Interesting, if it is in a log on a windows PC, then it is likely that 
it is the windows DC trying to update the record, which it shouldn't and 
will fail if vm-dc3 already has updated it.

Rowland

Hello Rowland,
>> 3. I see the errors in the System log on the former DC (vm-dc1), like:
>> The dynamic registration of the DNS record
'_ldap._tcp.DomainDnsZones.domain.com. 600 IN SRV 0 100 389
vm-dc1.domain.com.' failed on the following DNS server:
>>
>> DNS server IP address: 172.26.1.83
>> Returned Response Code (RCODE): 0
>> Returned Status Code: 9016
>> ...
>> ADDITIONAL DATA
>> Error Value: DNS signature failed to verify.
>>
>> (172.26.1.83 is the new PDC - vm-dc3)
> Interesting, if it is in a log on a windows PC, then it is likely that 
> it is the windows DC trying to update the record, which it shouldn't
and
> will fail if vm-dc3 already has updated it.
Indeed,  the  Windows  DC tried to update the record.. The other day, I've
found
that  the  record is just missing (expired?). So, I've started to dig in and
was
able to resolve the issue in this way:
1. I could reproduce the issue by restarting NETLOGON service on the Windows DC.
Also the following commands failed with "Connection Status = 1311 0x51f
ERROR_NO_LOGON_SERVERS":
nltest.exe /dsregdn
nltest /query
2. After some googling, I've found the fixing command:
nltest /sc_reset:domain.com

After   that,  all  vm-dc1  records  were  registered  in  the  AD  w/o  issues
using "nltest.exe /dsregdn" command.
Unfortunately, it's failing again after restarting NETLOGON service.

-- 
Best regards,
Alex