Univention Bugzilla – Bug 43715
check_essential_samba4_dns_records should also fix essential records
Last modified: 2019-01-03 07:19:42 CET
In a situation where the whole dns zone '_msdcs.' had been removed, or even when just the related SOA record is missing (somehow!?), it's quite hard to fix this by hand. Because this task looks quite generic to me it might be very helpfull to let the script fix these _essential dns records_. [The manual way was to recover this record from the backups]
AFAIK in this case the DC=@ object of the _msdcs.$domainname DNS zone DC=@,DC=_msdcs.$domainname,CN=MicrosoftDNS,DC=DomainDnsZones,$samba4_ldap_base had two NS resource records (stored in the dnsRecord attributes), one of which was invalid for some reason. In daemon.log bind9 complained: ===================================================================== Mar 2 17:02:31 master named[31097]: zone _msdcs.dom.local/NONE: has no NS records Mar 2 17:02:31 master named[31097]: samba_dlz: Failed to configure zone '_msdcs.dom.local' ===================================================================== Unfortunately no details of the objects have been reported on the Ticket, which makes it really hard to come up with a suitable solution. Then, as a workaround the customer decided to create a separate _msdcs.dom.local zone in OpenLDAP via UMC. And only then, when that object was removed again from OpenLDAP, the S4-Connector deleted the DC=@ object above. But the zone container and other records have not been deleted. Restoring DNS resource records (objectClass: dnsNode, Attribute: dnsRecord) is what samba_dnsupdate should do. It doesn't deal with a removed SOA though. But the real questions are: 1. In what way was the NS record broken in a way that made bind9 reject it? 2. Why doesn't the S4-Connector have a special protection for the _msdcs zone? Once we have data required to answer question 1, we can start to understand the way how the customer got into this situation. And then we can see what we can to to a) avoid that and b) maybe fix it.
Sorry that's DC=@,DC=_msdcs.$domainname,CN=MicrosoftDNS,DC=ForestDnsZones,$samba4_ldap_base
Question 2 has already been split off as Bug 43722.
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.