Sites and services and queries for SRV records ...
Alexey A Nikitin
nikitin at amazon.com
Wed Sep 18 20:33:42 UTC 2019
On Wednesday, 18 September 2019 12:22:44 PDT Richard Sharpe via samba-technical wrote:
> Hi folks,
> I thought, perhaps naively, that if an organization is using sites and
> services, and you do a query for SRV records from Site A for
> _ldap._tcp.<realm> that the Windows DNS servers would return the SRV
> records ordered with those for Site A first.
> Is there more that you have to do to ensure that? What I am seeing
> looks like standard random round-robin order.
The behavior of SRV RRs is specified in https://tools.ietf.org/html/rfc2782
To summarize the related to your question info:
The order for the servers in SRV RRs is not guaranteed, instead the clients should attempt to query those servers in the order that depends on the weight and priority of the corresponding SRV RRs. In case of MS AD DS, for example, order of the SRV RRs may depend on the order in which DCs came online and registered themselves with DNS. The weight and priority ideally should depend on the domain topology, and IIRC there is a way to have each DNS server in the domain return the same server with different weight/priority, or even limit the domain-global SRV RR set to just the site-specific SRV RRs. But in a simple multi-site setup with all links between the sites equivalent and all DNS servers providing the same SRV RR sets whether client will first pick a DC in it's local site is up to the dumb luck. What client then should do is described in the DC Location mechanism specification (see [MS-ADTS], [MS-NRPC], ash [MS-DISO] - some of these are deprecated, but empirically still hold true), though to simplify it sends the NetLogon ping to the first server it picks, and then reads the response to figure out which site the client is in and whether that server is from the client's site or some other site; if the first server is not the closest to the client then client should make another SRV RR query, this time using the closest to the client site it obtained with the first NetLogon ping response.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the samba-technical