+++ This bug was initially created as a clone of Bug #50385 +++ I saw two cases, one in-house and one customer where an Administrator created a host record named @ in some forward_zone, triggering a chain of actions that finally led to a full DNS blackout for that forward_zone. Here is how: The Admin opens the DNS module in UMC, clicks on the zone and add a host record with name @. The attached screenshot shows the result in the UMC DNS treeview: It lokks as if the zone has been duplicated as a child of itself. In named/bind9 terms, the Admin has just written a second resource record named @ into his zone file. The UMC should not allow this. Since UMC/UDM currenlty allow this, the Admin is now in a very dangerous situation: With a high probability, the Admin right-clicks the unwanted object and deletes it. If Samba/AD is installed in the domain, then the S4-Connector interprets this as the removal of an SOA record and removes the SOA record of that zone in Samba/AD. That's silent and nobody notices until the nameserver services (bind9) gets restarted at some point in the future and the nameserver doesn't recognize the zone as valid any longer and the customer experiences severe DNS issues for the entire domain.
The S4-Connector should not mistake a host_record removal for an SOA-record removal.
Testing again with the errata update for Bug #50385 installed shows this in connector-s4.log when creating a dns/host_record named '\@': root@primary20:~# udm dns/host_record create --superordinate zoneName=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net --set name='@' --set a=127.0.0.1 Object created: relativeDomainName=\\@,zoneName=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net ## connector-s4.log: 05.04.2024 11:51:15.239 LDAP (PROCESS): sync AD > UCS: [ dc] [ modify] 'cn=primary20,cn=dc,cn=computers,dc=ucs50domain,dc=net' 05.04.2024 11:52:16.984 LDAP (PROCESS): sync UCS > AD: [ dns] [ add] 'DC=\\\\@,DC=ucs50domain.net,CN=MicrosoftDNS,DC=DomainDnsZones,DC=ucs50domain,DC=net' 05.04.2024 11:52:17.088 LDAP (PROCESS): sync UCS > AD: [ dns] [ modify] 'dc=@,dc=ucs50domain.net,cn=microsoftdns,dc=domaindnszones,DC=ucs50domain,DC=net' 05.04.2024 11:52:18.136 LDAP (PROCESS): sync AD > UCS: [ dns] [ modify] 'relativedomainname=\\5c@,zonename=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net' 05.04.2024 11:52:18.144 LDAP (PROCESS): sync AD > UCS: [ dns] [ modify] 'zonename=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net' 05.04.2024 11:52:18.174 LDAP (PROCESS): sync AD > UCS: [ dns] [ add] 'relativeDomainName=@._msdcs,zoneName=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net' The last line looks fishy and that object is actually not created (which is good, but..) ## removing the record via udm: root@primary20:~# udm dns/host_record delete --dn 'relativeDomainName=\\@,zoneName=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net' Object removed: relativeDomainName=\\@,zoneName=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net 05.04.2024 11:55:19.106 MAIN (------ ): DEBUG_INIT 05.04.24 11:55:19.106 DEBUG_INIT 05.04.24 11:55:19.125 DEBUG_EXIT 05.04.2024 11:55:30.812 LDAP (PROCESS): sync AD > UCS: [ dc] [ modify] 'cn=backup21,cn=dc,cn=computers,dc=ucs50domain,dc=net' 05.04.2024 11:56:07.243 LDAP (PROCESS): sync UCS > AD: [ dns] [ delete] 'dc=\\\\@,dc=ucs50domain.net,cn=microsoftdns,dc=domaindnszones,DC=ucs50domain,DC=net' 05.04.2024 11:56:07.258 LDAP (PROCESS): sync UCS > AD: [ dns] [ modify] 'dc=@,dc=ucs50domain.net,cn=microsoftdns,dc=domaindnszones,DC=ucs50domain,DC=net' 05.04.2024 11:56:08.284 LDAP (PROCESS): sync AD > UCS: [ dns] [ delete] 'relativeDomainName=\\\\@\nDEL:88b7e1bd-97c5-4604-9ecb-72bc8d223226,zonename=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net' 05.04.2024 11:56:08.291 LDAP (PROCESS): sync AD > UCS: [ dns] [ modify] 'zonename=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net' 05.04.2024 11:56:08.301 LDAP (PROCESS): sync AD > UCS: [ dns] [ add] 'relativeDomainName=@._msdcs,zoneName=ucs50domain.net,cn=dns,dc=ucs50domain,dc=net' At least that doesn't seem to tear down the zone now. Nice.