Bug 50361 - Changing the dns/backend from samba4 to ldap, entries beneath _msdcs are not resolved anymore
Changing the dns/backend from samba4 to ldap, entries beneath _msdcs are not ...
Status: NEW
Product: UCS
Classification: Unclassified
Component: DNS
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on: 57002
Blocks:
  Show dependency treegraph
 
Reported: 2019-10-14 14:41 CEST by Christina Scheinig
Modified: 2024-01-26 19:16 CET (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.286
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2019100221000181, 2020042321000793
Bug group (optional):
Max CVSS v3 score:
requate: Patch_Available+


Attachments
Bug50361.patch (4.50 KB, patch)
2019-10-15 16:59 CEST, Arvid Requate
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2019-10-14 14:41:38 CEST
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.
Comment 1 Arvid Requate univentionstaff 2019-10-14 14:57:34 CEST
>  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
Comment 2 Arvid Requate univentionstaff 2019-10-14 15:01:11 CEST
> 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.
Comment 3 Arvid Requate univentionstaff 2019-10-15 08:03:39 CEST
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.
Comment 4 Ingo Steuwer univentionstaff 2019-10-15 11:18:42 CEST
(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?
Comment 5 Arvid Requate univentionstaff 2019-10-15 16:59:10 CEST
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.
Comment 6 Christina Scheinig univentionstaff 2019-10-16 15:23:36 CEST
(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.
Comment 7 Ingo Steuwer univentionstaff 2022-09-22 09:52:43 CEST
(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?