1

I have Microsoft AD Domain with multiple geographical sites. All sites are interconnected by VPN. All sites have 2 Domain Controllers running Windows Server 2012 R2.

I was reviewing the automated _ldap and _kerberos SRV records for each site in the DNS manager, and many (most?) of the entries make little sense.

A few sites had entries only for DCs that were off-site.

Many sites had one entry for the primary on-site DC (which is good), but instead of having the secondary on-site DC as another entry, it had an off-site DC as an equally weighted entry.

Many sites with off-site DCs had seemingly random off-site DCs. In most cases they were the most geographically distant DCs, which generally means higher pings and less bandwidth.

Just to be clear, the appropriate DCs are mapped correctly to their corresponding geographic sites within the Domain Sites and Services manager.

It seems to me that I would be much better off managing these entries myself. Ideally I would setup the SRV entries for each site like this:

Primary On-site DC - weight 0
Secondary On-site DC - weight 0
Primary Off-site DC, geographically close - weight 1
Secondary Off-site DC, geographically close - weight 1
Primary Off-site DC, geographically far - weight 2
Secondary Off-site DC, geographically far - weight 2

So in order to do this, I'd need to change all those SRV records to static, and then manage everything myself manually.

Aside from the tedious nature of this task, and the possibility for introducing human error into these essential records, is there a good reason I should not be revising these SRV entries manually?

Alternatively, is there a way to have more intelligently created automatic SRV records?

Tangentially related question: When messing around with creating static SRV records, I've noticed a strange behavior. Normally, automatically created DNS records get a time stamp, whereas records I create manually get a <static> label. Often, though, a record I create just gets a blank label (i.e. null). But if I check the advanced properties of the record, it does not have the Delete this record when it becomes stale option checked, so it seems it is static?

Daniel
  • 1,614
  • 9
  • 29
  • 47
  • If you haven't done so already, I would double check in "Active Directory Sites and Services" admin tool that each DC is listed in the correct site before manually editing any of the DNS records. And check that replication is actually working with the `repadmin` command. Also keep in mind that some of the areas in an AD replicated DNS domain are supposed to be different at different DNS servers such as in the _ldap._tcp._sitename.dc._msdcs.ADdomain records. – BeowulfNode42 Sep 18 '18 at 23:42
  • I specified that Sites and Services is configured correctly in my original post. I also have no unexpected errors when doing a `repadmin /SyncAll AdeP` command – Daniel Sep 18 '18 at 23:55
  • I was going to post an answer, but TBH I'm too tired today. A couple of things; 1. Make sure you have your subnets in ADS&S and make sure they're associated with the correct sites. 2. Make sure your sites and site links are correct and that the DC's are in the correct sites. 3. Read these links to learn about Automatic Site Coverage, which is probably why you're seeing what you're seeing. Once you've reviewed and corrected (if needed) your subnets, sites and site links then delete the site specific SRV records and restart the Netlogon service on each DC to recreate them. – joeqwerty Sep 19 '18 at 00:35
  • - https://blogs.technet.microsoft.com/askds/2011/04/29/sites-sites-everywhere - https://blogs.msmvps.com/acefekay/2010/01/03/the-dc-locator-process-the-logon-process-controlling-which-dc-responds-in-an-ad-site-and-srv-records – joeqwerty Sep 19 '18 at 00:35
  • 1. Subnets are in S&S; 2. Sites are correct, DCs are in correct sites, site to site links are correct; 3. ok. All of this has been correct since initial install. Years now. – Daniel Sep 19 '18 at 11:31
  • Hmm, maybe "Site Cost" is key... – Daniel Sep 19 '18 at 11:56
  • I still don't see how the weights in the `SRV` records make sense given the `Site Cost`s I have defined. The lowest `Site Cost` I have is "100". Shouldn't an on-site DC have, essentially, a `Site Cost` of 0? So why would the automated `SRV` records populate with an On-Site DC of `weight` "0" and an Off-Site DC *also* of `weight` "0"? It seems to me that `Site Cost` in `Inter-Site Transports` should correspond to the `weight` in the `SRV` records - but it doesn't. – Daniel Sep 19 '18 at 12:13
  • So, just giving this a shot... after I've updated the `Site Cost` how can I force the DNS `SRV` records to auto-update again? – Daniel Sep 19 '18 at 14:49
  • You can delete the site specific SRV records and stop/start the Netlogon service on each DC to force each DC to re-register it's site specific SRV records. – joeqwerty Sep 19 '18 at 16:17
  • `is there a good reason I should not be revising these SRV entries manually?`. Yes. A more orthodox/less convoluted approach would be to determine why the records are not registering/registering in the wrong site. The only time I have ever seen these records adjusted was to assign a preference for a domain controller or to reduce load on a domain controller, and that isn't accomplished by editing the records, they are registry values. – Greg Askew Sep 24 '18 at 15:03
  • I manually deleted all site related `SRV` records, restarted `Net Logon` services across all DCs on my domain, and now the `SRV` records have repopulated and seem a lot cleaner. However, one thing I noticed is that the `Site Cost`s that I setup in `Inter-Site Transports` seem to have no effect on `SRV` records. I would have expected that `SRV` records would get added to each site in order of cost, but only the `SRV` records for the servers actually in the same site get added. Then I wonder about the purpose of `SIte Cost` - the `Weight` and `Priority` options for `SRV` records seem wasted. – Daniel Oct 05 '18 at 00:54

1 Answers1

1

There are many records for different services and different types of clients. Some of those records ARE site specific, and will be used by clients that ARE site aware. Example: _ldap._tcp.SiteName._sites.DnsDomainName.

Some of them are NOT site specific and will be used by clients that are NOT site aware. Example: _ldap._tcp.dc._msdcs.DnsDomainName.

There is also a record for the PDC FSMO holder that begins with _ldap but as there is only one PDC, every client in every site can only use the PDC if that service is required. Example: _ldap._tcp.pdc._msdcs.DnsDomainName.

Clayton
  • 4,523
  • 17
  • 24
  • Yes, but please manage this through Sites and Services - don't manage the SRV records manually. – TheFiddlerWins Sep 24 '18 at 17:15
  • Agreed, was not suggesting that. Just trying to clarify that some records are site specific and some are not. – Clayton Sep 24 '18 at 20:23
  • I only messed with the records that were specifically listed within the site-related folders on DNS. there are 5 such locations: `Forward Lookup Zones` -> `_msdcs.domain.com` -> **1.** ( `dc` -> `sites` ) & **2.** (`gc` -> `sites` ) AND `Forward Lookup Zones` -> `domain.com` -> **3.** ( `_sites` ) & **4.** ( `DomainDnsZones` -> `sites` ) & **5.** ( `ForestDnsZones` -> `sites` ) – Daniel Oct 05 '18 at 00:51