Univention Bugzilla – Bug 53945
AD-Connector traceback after AD-Takeover and bind9 can't resolve SRV records
Last modified: 2021-10-19 12:29:30 CEST
After an AD-Takeover a customer reported that the bind9 nameserver can't resolve SRV records and there is this traceback in the AD-Connector log: 15.10.2021 09:05:05.424 LDAP (INFO ): move dns from [dc=gc,dc=_msdcs.example.local,cn=microsoftdns,dc=forestdnszones,DC=example,DC=local] to [DC=gc._msdcs.example.local,dc=example.local,cn=microsoftdns,dc=domaindnszones,DC=example,DC=local] 15.10.2021 09:05:05.429 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1634021012.505577 15.10.2021 09:05:05.429 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/univention/s4connector/__init__.py", line 891, in __sync_file_from_ucs if ((old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, unicode(old_dn, 'utf8'), old, new)) or (not old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, old_dn, old, new))): File "/usr/lib/python2.7/dist-packages/univention/s4connector/s4/__init__.py", line 2330, in sync_from_ucs self.lo_s4.rename(unicode(old_dn), object['dn']) File "/usr/lib/python2.7/dist-packages/univention/uldap.py", line 846, in rename self.rename_ext_s(dn, newrdn, newsdn, serverctrls=serverctrls, response=response) File "/usr/lib/python2.7/dist-packages/univention/uldap.py", line 204, in _decorated return func(self, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/univention/uldap.py", line 868, in rename_ext_s rtype, rdata, rmsgid, resp_ctrls = self.lo.rename_s(dn, newrdn, newsuperior, serverctrls=serverctrls) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 449, in rename_s resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 514, in result3 resp_ctrl_classes=resp_ctrl_classes File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 521, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call result = func(*args,**kwargs) AFFECTS_MULTIPLE_DSAS: {'info': 'Cannot rename from dc=gc,dc=_msdcs.example.local,cn=microsoftdns,dc=forestdnszones,DC=example,DC=local in DC=ForestDnsZones,DC=example,DC=local to DC=gc._msdcs.example.local,DC=example.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=example,DC=local in DC=DomainDnsZones,DC=example,DC=local: Affects multiple DSAs', 'desc': 'Operation affects multiple DSAs'}
The cause of the bind9 issue was found in the /var/log/syslog: <timestamp> ucs01 named[7097]: samba_dlz: pre-W2k3 zone found <timestamp> ucs01 named[7097]: samba_dlz: Ignoring dnsZone _msdcs.example.local It turned out that there's still a DNS zone in the pre-2003 location in Samba/AD, which was basically empty, it comtained just the SOA record DC=@. After stopping bind9, removing the empty zone, and starting bind9 again the problem was fixed: root@ucs01:~# /etc/init.d/bind9 stop; ldbdel -H /var/lib/samba/private/sam.ldb DC=portal.my-example-domain.de,CN=MicrosoftDNS,CN=System,DC=example,DC=local --recursive [ ok ] Stopping bind9 (via systemctl): bind9.service. Deleted 2 records root@ucs01:~# /etc/init.d/bind9 start [ ok ] Starting bind9 (via systemctl): bind9.service. (Not sure about the exact DNS names in the logs, please check the ticket for the exact details). We should check if this a generic issue of if it was a special case of that specific AD domain data.