Univention Bugzilla – Bug 50361
Changing the dns/backend from samba4 to ldap, entries beneath _msdcs are not resolved anymore
Last modified: 2024-01-26 19:16:30 CET
Caused by further problems in the customers environment, the customer changed the dns/backend from samba4 to ldap. After restarting the bind9 service and nscd the entrys beneath _msdcs were not resolved anymore. Dig with samba4: dig @127.0.0.1 _msdcs.$(dnsdomainname) -t any ------------------------ ; <<>> DiG 9.10.3-P4-Univention <<>> @127.0.0.1 _msdcs.schein.ig -t any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17383 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_msdcs.schein.ig. IN ANY ;; ANSWER SECTION: _msdcs.schein.ig. 3600 IN SOA master.schein.ig. hostmaster.schein.ig. 132 900 600 86400 3600 _msdcs.schein.ig. 900 IN NS member.schein.ig. _msdcs.schein.ig. 900 IN NS master.schein.ig. _msdcs.schein.ig. 900 IN NS slave.schein.ig. _msdcs.schein.ig. 900 IN NS backup.schein.ig. ;; ADDITIONAL SECTION: master.schein.ig. 900 IN A 10.200.43.180 backup.schein.ig. 900 IN A 10.200.43.181 slave.schein.ig. 900 IN A 10.200.43.182 member.schein.ig. 900 IN A 10.200.43.183 ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 14 14:15:53 CEST 2019 ;; MSG SIZE rcvd: 239 ------------------------------ With ladp backend dig @127.0.0.1 _msdcs.$(dnsdomainname) -t any ------------------------------ ; <<>> DiG 9.10.3-P4-Univention <<>> @127.0.0.1 _msdcs.schein.ig -t any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31014 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_msdcs.schein.ig. IN ANY ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 14 14:11:19 CEST 2019 ;; MSG SIZE rcvd: 45 ---------------------------------- so everything beneath _msdcs is not found anymore dig @127.0.0.1 gc._msdcs.$(dnsdomainname) ; <<>> DiG 9.10.3-P4-Univention <<>> @127.0.0.1 gc._msdcs.schein.ig ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61200 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gc._msdcs.schein.ig. IN A ;; ANSWER SECTION: gc._msdcs.schein.ig. 900 IN A 10.200.43.180 gc._msdcs.schein.ig. 900 IN A 10.200.43.183 gc._msdcs.schein.ig. 900 IN A 10.200.43.182 gc._msdcs.schein.ig. 900 IN A 10.200.43.181 ;; AUTHORITY SECTION: _msdcs.schein.ig. 900 IN NS backup.schein.ig. _msdcs.schein.ig. 900 IN NS slave.schein.ig. _msdcs.schein.ig. 900 IN NS member.schein.ig. _msdcs.schein.ig. 900 IN NS master.schein.ig. ;; ADDITIONAL SECTION: master.schein.ig. 900 IN A 10.200.43.180 backup.schein.ig. 900 IN A 10.200.43.181 slave.schein.ig. 900 IN A 10.200.43.182 member.schein.ig. 900 IN A 10.200.43.183 ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 14 14:18:49 CEST 2019 ;; MSG SIZE rcvd: 259 -------------------------------------- versus ldap backend -------------------------------------- dig @127.0.0.1 gc._msdcs.$(dnsdomainname) ; <<>> DiG 9.10.3-P4-Univention <<>> @127.0.0.1 gc._msdcs.schein.ig ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3354 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gc._msdcs.schein.ig. IN A ;; Query time: 21 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 14 14:20:03 CEST 2019 ;; MSG SIZE rcvd: 48 --------------------------------------- and --------------------------------------- dig @127.0.0.1 -p 7777 gc._msdcs.$(dnsdomainname) ; <<>> DiG 9.10.3-P4-Univention <<>> @127.0.0.1 -p 7777 gc._msdcs.schein.ig ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61648 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gc._msdcs.schein.ig. IN A ;; Query time: 7 msec ;; SERVER: 127.0.0.1#7777(127.0.0.1) ;; WHEN: Mon Oct 14 14:20:59 CEST 2019 ;; MSG SIZE rcvd: 48 ------------------------------------------- univention-ldapsearch -LLL -b zoneName=schein.ig,cn=dns,dc=schein,dc=ig -s sub '(relativeDomainName=_ldap._tcp)' dn: relativeDomainName=_ldap._tcp,zoneName=schein.ig,cn=dns,dc=schein,dc=ig objectClass: dNSZone objectClass: top objectClass: univentionObject univentionObjectType: dns/srv_record dNSTTL: 10800 relativeDomainName: _ldap._tcp zoneName: schein.ig sRVRecord: 0 100 389 master.schein.ig. sRVRecord: 0 100 389 backup.schein.ig. sRVRecord: 0 100 389 slave.schein.ig. sRVRecord: 0 100 389 member.schein.ig. ----------------------- The issue gets solved, if the entry univention-ldapsearch relativeDomainName=_msdcs # extended LDIF # # LDAPv3 # base <dc=schein,dc=ig> (default) with scope subtree # filter: relativeDomainName=_msdcs # requesting: ALL # # _msdcs, schein.ig, dns, schein.ig dn: relativeDomainName=_msdcs,zoneName=schein.ig,cn=dns,dc=schein,dc=ig nSRecord: master.schein.ig. objectClass: dNSZone objectClass: top objectClass: univentionObject univentionObjectType: dns/ns_record dNSTTL: 79200 relativeDomainName: _msdcs zoneName: schein.ig # search result search: 3 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------- is removed. udm dns/ns_record remove --dn relativeDomainName=_msdcs,zoneName=schein.ig,cn=dns,dc=schein,dc=ig It seemes, the ldap bind cannot deal with the subzone delegation. The entry might be synchronized from samba.
> dig @127.0.0.1 _msdcs.$(dnsdomainname) -t any _msdcs is not a zone in OpenLDAP (doesn't have an SOA), so this is expected to fail. > dig @127.0.0.1 gc._msdcs.$(dnsdomainname) Whe I switch dns/backend to ldap and restart bind, then I got root@master10:~# host gc._msdcs.$(dnsdomainname) Host gc._msdcs.ar41i1.qa not found: 2(SERVFAIL) It worked a couple of seconds later (after succefully checking the zone with host -al $(dnsdomainname) | grep gc._msdcs): root@master10:~# host gc._msdcs.$(dnsdomainname) gc._msdcs.ar41i1.qa has address 10.200.8.11 gc._msdcs.ar41i1.qa has address 10.200.8.10
> univention-ldapsearch relativeDomainName=_msdcs Should not find an object! Did you check that the situation doesn't have the same cause as Bug 43288? That could also explain some other issues with dns/backend=samba4.
Ok, I can reproduce this on two systems: * UCS 4.4-0 Master, univention-app install samba4 -> relativeDomainName=_msdcs pesent in OpenLDAP. * UCS 4.4-2 Master, updated from UCS 4.1 -> record not present, but when I resync_from_s4, then it is created. The source object DC=_msdcs,DC=${domainname},CN=MicrosoftDNS,DC=DomainDnsZones,${samba4_ldap_base} is the DNS glue record to link in the DC=_msdcs.${domainname} zone. With our currently layout of the zone in OpenLDAP, this glue record should not be synchronized to OpenLDAP, so the S4-Connector should ignore it.
(In reply to Arvid Requate from comment #3) > Ok, I can reproduce this on two systems: > > * UCS 4.4-0 Master, univention-app install samba4 -> > relativeDomainName=_msdcs pesent in OpenLDAP. > > * UCS 4.4-2 Master, updated from UCS 4.1 -> record not present, but when I > resync_from_s4, then it is created. > > The source object > DC=_msdcs,DC=${domainname},CN=MicrosoftDNS,DC=DomainDnsZones, > ${samba4_ldap_base} > is the DNS glue record to link in the DC=_msdcs.${domainname} zone. > > With our currently layout of the zone in OpenLDAP, this glue record should > not be synchronized to OpenLDAP, so the S4-Connector should ignore it. I have no test environment here. To ensure that I understand correctly: - we have situations where not all service records created by or at least in Samba 4 are synced to OpenLDAP - to have the same DNS behaviour regarding service entries for both backends, we need to sync the Object DC=_msdcs,DC=${domainname},CN=MicrosoftDNS,DC=DomainDnsZones,${samba4_ldap_base} correct?
Created attachment 10205 [details] Bug50361.patch There are two things to do: 1. Prevent this from happening: Add the _msdcs DNS glue record to the connector/s4/mapping/dns/ignorelist and restart the S4-Connector. Unfortunately, a bug in the S4-Connector currently causes the ignorelist for DNS records to only apply in the "sync to ucs" case. The attached patch fixes this and adds _msdcs to that UCR variable. 2. Fix stuff in case it happened: I would suggest to add an SDB article that explains how to remove the relativeDomainName=_msdcs object from OpenLDAP. Before doning this it's important to put that object onto the ignorelist and have the S4-Connector patched. This is important to avoid that the S4-Connector synchronizes the delete operation to Samba/AD, where the glue record is needed.
(In reply to Ingo Steuwer from comment #4) > (In reply to Arvid Requate from comment #3) > > Ok, I can reproduce this on two systems: > > > > * UCS 4.4-0 Master, univention-app install samba4 -> > > relativeDomainName=_msdcs pesent in OpenLDAP. > > > > * UCS 4.4-2 Master, updated from UCS 4.1 -> record not present, but when I > > resync_from_s4, then it is created. > > > > The source object > > DC=_msdcs,DC=${domainname},CN=MicrosoftDNS,DC=DomainDnsZones, > > ${samba4_ldap_base} > > is the DNS glue record to link in the DC=_msdcs.${domainname} zone. > > > > With our currently layout of the zone in OpenLDAP, this glue record should > > not be synchronized to OpenLDAP, so the S4-Connector should ignore it. > Answer is inline: > I have no test environment here. To ensure that I understand correctly: > > - we have situations where not all service records created by or at least in > Samba 4 are synced to OpenLDAP no, the _msdcs record is synchronized to the openLdap. This entry is kind of sub-zone-delegation. The dns with backend ldap cannot deal with this, so everything beneath this is not handled. The service records beneath exist. > - to have the same DNS behaviour regarding service entries for both > backends, we need to sync the Object > DC=_msdcs,DC=${domainname},CN=MicrosoftDNS,DC=DomainDnsZones, > ${samba4_ldap_base} > no, the entry must not be synced to openLDAP > correct? So, both not correct.
(In reply to Christina Scheinig from comment #0) > Caused by further problems in the customers environment, the customer > changed the dns/backend from samba4 to ldap. I wonder what the reason was to switch the backend. Maybe it is better to fix that than to try to re-implement the DNS of samba4?