Bug 9332 - dlz_bind does not use the correct logic for locating dns zones
Summary: dlz_bind does not use the correct logic for locating dns zones
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.13.4
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Amitay Isaacs
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-29 05:11 UTC by Matthieu Patou
Modified: 2021-02-02 14:49 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthieu Patou 2012-10-29 05:11:38 UTC 
dlz_bind search in 
  "CN=MicrosoftDNS,DC=DomainDnsZones"  + defaultNC
  "CN=MicrosoftDNS,DC=ForestDnsZones" + defaultNC
  "CN=MicrosoftDNS,CN=System" + defaultNC

Tests with Windows 2003 have demonstrated that this version of Windows keeps records by default in the CN=MicrosoftDNS so zones should be searched there first.
Also as the name imply the ForestDNSZone must be based on the rootNamingContext not the default one. When Samba will support multi domain forest this will make a difference (on a single domain defaultNC == rootNC).

Internal dns_server does a cross-ncs search for all dnsZone object.

This wrong as if there is more than 1 domain and the DC is a GC then it will have (partial)replica of DomainDNS zone for other domain. Also tests against windows have shown that cross-ncs search didn't search into application partitions:

./bin/ldbsearch -H ldap://172.16.100.244 -Uadministrator%totoTATA123 --cross-ncs '(objectclass=dnszone)' dn 
# record 1
dn: DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=w2k3,DC=home,DC=matws,DC=net

# returned 1 records
# 1 entries
# 0 referrals
Comment 1 Matthieu Patou 2012-10-29 05:33:23 UTC 
Windows DC "understand" that a zone has been migrated to DomainDNS/ForestDNS if there is no more dnsZone object in the CN=MicrosoftDNS,CN=System,<defaultNC>.
Comment 2 Amitay Isaacs 2012-11-09 12:49:10 UTC 
I think we can add the code to first check under CN=System for the zones and if it does not find any zones there, then use the DNS partitions and also fix the DN for forest DNS partition.

I'll have to replicate the same logic in DNS RPC server.
Comment 3 Kai Blin 2013-05-25 10:30:44 UTC 
Split out the internal DNS bug so we can push unrelated patches separately.
Comment 4 Remsnet (dead mail address) 2014-11-21 10:14:34 UTC 
Just tested this query on  ads results on sernet samba 4.1.3 :


# ldbsearch -H ldap://samba4-ad2 -UAdministrator --cross-ncs '(objectclass=dnszone)' dn
Password for [ADS\Administrator]:
# record 1
dn: DC=ads.sample.dom,CN=MicrosoftDNS,DC=DomainDnsZones,DC=ads,DC=sample,DC=dom

# record 2
dn: DC=RootDNSServers,CN=MicrosoftDNS,DC=DomainDnsZones,DC=ads,DC=sample,DC=dom

# record 3
dn: DC=_msdcs.ads.sample.dom,CN=MicrosoftDNS,DC=ForestDnsZones,DC=ads,DC=sample,DC=dom

# record 4
dn: DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=ads,DC=sample,DC=dom

# returned 4 records
# 4 entries
# 0 referrals

Question : Any Known way to Fix  at least the "record 2" and "record 4" ?

looks like the root cause of Multi-Server DNS Homed AD renundancy issue..