S4 Experimental patch to make S4 site aware when joined as a member

ronnie sahlberg ronniesahlberg at gmail.com
Thu Jan 17 23:19:21 GMT 2008


Please find for review an experimental patch to add a new resolve
method to S4 which is used to resolve/locate domaincontrollers.

The new resolve method uses DNS and CLDAP to locate a DC that belongs
to the same site as where the S4 member server resides.
Using sites allows a member server to quickly and reliably find a good
DC that is near the member server, which is important for very large
domains
where you may have hundreds or thousands of DCs but where only very
few of them are local.


Using CLDAP from within resolve.a causes a circular dependency in the
buildsystem which had to be resolved by the very kludgy changes to
config.mk :-(

The patch adds a new parameter accessed by lp_dc_resolve_context()
which differs from lp_resolve_context() in that is also
offers the "dnssrv" resolve method.  A method you only want to use
when resolving a DC or other service, but not a normal server name.

It adds a new parameter "dc name resolv order" which is the same as
"name resolve order" except that it defaults to try the "dnssrv"
method first.

It adds a new database domaindb.tdb where the dns domain name of the
domain we are joined to is stored. (DNS/CLDAP dc location needs the
real dns domain name)
This database can also store the current site name where S4 currently
resides but this is not used yet.
This database can later be used to store site/server/subnet
information when S4 is a domain controller to make it site aware in
the future when used as a DC.

To activate "dnssrv" one needs to rejoin to the domain and specify a
new, third, argument to the join :
net join NBDOMAIN MEMBER DNS-DOMAIN-NAME

The process to locate a DC when dnssrv is used is :
1, first do a global search in DNS for all DCs  (_ldap._tcp)
2, try the DCs one by one using a CLDAP ping  until one of the DCs respond.
3, the response from the DC to the CLDAP ping contains the name of the
site that S4 currently resides in (The DC decides this based on the IP
address of S4)
4, now when S4 knows what site it belongs to it issues another, site
specific DNS search to find the DCs that belong to the same site as
S4.
5, Finally use CLDAP pings to all DCs in our site and check which ones
are available.

This means that normally it would only take
2 DNS lookups
1 CLDAP ping, possibly to a DC to the other side of the world
and
n CLDAP pings to the n DCs that are very close to us and belong to the
same site.
to reliably find a DC that is very close to us.


Example: 200 DCs for a domain.   4 are very close and in the same
site.   196 of them are on the other side of the planet and 200ms
away.



please review.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnssrv.txt.bz2
Type: application/x-bzip2
Size: 8251 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20080118/59f8d00a/dnssrv.txt.bin


More information about the samba-technical mailing list