Score:0

Creating DNS A Record for 3 domain controllers

pl flag

I have setup a new domain on our network consisting of 2 domain controllers, dc1, dc2. I can see the A records for the 2 controllers. But I need to do load balancing so that I can refer to the 2 dcs in single entry.

I have created two A records with same name for the different IPs, dc.domain.com. Is this the standards procedure?

joeqwerty avatar
cv flag
**But I need to do load balancing so that I can refer to the 2 dcs in single entry** - Can you tell us why you want/need to do "load balancing" and what you mean by that statement?
pl flag
Thanks. I have an application with about 10,000 users which authenticates against the Active Directory.
Score:2
za flag

Active directory already has a form of a DNS load balancing. You just look into wrong place.

A record just says which controller has which IP address. Where clients go for each domain service (LDAP, Kerberos, Global Catalog LDAP, et cetera) is configured with SRV records. And if you didn't do anything fancy, you will have SRV records in your domain already point to each domain controller for each service.

Here is the typical structure of the Active Directory domain DNS zone:

example.com.                               3600 IN SOA      dc1.example.com. admin.example.com 66593 900 600 86400 3600
example.com.                               3600 IN NS       dc1.example.com.
example.com.                               3600 IN NS       dc2.example.com.
example.com.                               600  IN A        192.168.3.1
example.com.                               600  IN A        192.168.4.1
_gc._tcp.example.com.                      600  IN SRV      0 100 3268 dc2.example.com.
_gc._tcp.example.com.                      600  IN SRV      0 100 3268 dc1.example.com.
_kerberos._tcp.example.com.                600  IN SRV      0 100 88 dc2.example.com.
_kerberos._tcp.example.com.                600  IN SRV      0 100 88 dc1.example.com.
_kpasswd._tcp.example.com.                 600  IN SRV      0 100 464 dc2.example.com.
_kpasswd._tcp.example.com.                 600  IN SRV      0 100 464 dc1.example.com.
_ldap._tcp.example.com.                    600  IN SRV      0 100 389 dc2.example.com.
_ldap._tcp.example.com.                    600  IN SRV      0 100 389 dc1.example.com.
_kerberos._udp.example.com.                600  IN SRV      0 100 88 dc2.example.com.
_kerberos._udp.example.com.                600  IN SRV      0 100 88 dc1.example.com.
_kpasswd._udp.example.com.                 600  IN SRV      0 100 464 dc2.example.com.
_kpasswd._udp.example.com.                 600  IN SRV      0 100 464 dc1.example.com.
DomainDnsZones.example.com.                600  IN A        192.168.3.1
DomainDnsZones.example.com.                600  IN A        192.168.4.1
_ldap._tcp.DomainDnsZones.example.com.     600  IN SRV      0 100 389 dc2.example.com.
_ldap._tcp.DomainDnsZones.example.com.     600  IN SRV      0 100 389 dc1.example.com.
ForestDnsZones.example.com.                600  IN A        192.168.3.1
ForestDnsZones.example.com.                600  IN A        192.168.4.1
_ldap._tcp.ForestDnsZones.example.com.     600  IN SRV      0 100 389 dc2.example.com.
_ldap._tcp.ForestDnsZones.example.com.     600  IN SRV      0 100 389 dc1.example.com.
dc1.example.com.                          3600  IN A        192.168.3.1
dc2.example.com.                          3600  IN A        192.168.4.1
_msdcs.example.com.                        3600 IN NS       dc1.example.com.
_gc._tcp.Default-First-Site-Name._sites.example.com. 600 IN SRV 0 100 3268 dc1.example.com.
_kerberos._tcp.Default-First-Site-Name._sites.example.com. 600 IN SRV 0 100 88 dc1.example.com.
_ldap._tcp.Default-First-Site-Name._sites.example.com. 600 IN SRV 0 100 389 dc1.example.com.
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.example.com. 600 IN SRV 0 100 389 dc1.example.com.
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.example.com. 600 IN SRV 0 100 389 dc1.example.com.
_gc._tcp.alter-site._sites.example.com. 600 IN SRV 0 100 3268 dc2.example.com.
_kerberos._tcp.alter-site._sites.example.com. 600 IN SRV 0 100 88 dc2.example.com.
_ldap._tcp.alter-site._sites.example.com. 600 IN SRV 0 100 389 dc2.example.com.
_ldap._tcp.alter-site._sites.DomainDnsZones.example.com. 600 IN SRV 0 100 389 dc2.example.com.
_ldap._tcp.alter-site._sites.ForestDnsZones.example.com. 600 IN SRV 0 100 389 dc2.example.com.

If you create sites, you'll get additional records for them. That supposed to make some computer to preferably ask their local domain controller than the remote. Here dc2 belongs to site alter-site and so any computer who is in that site will ask it first. If you leave everything default, both controllers will be in the default site Default-First-Site-Name.

You can alter the load distribution between controllers by altering those SRV records. See "100"'s? These are weights. If you set 67 for one DC and 33 for another, the first one will get 2/3 of requests and another will have 1/3. "0"'s in front of each SRV record are priorities; if you have larger priority servers accessible the lower priority will not be queiried at all. Please look for SRV record description for details; there are plenty explanations in the Internet, including this site.

There are few records which are "not symmetric". For example, SOA record has a particular DNS server name in it. But those are rarely used in this case and this doesn't constitute any bottlenecks.

Also important note about SYSVOL. When clients login, after checking passwords (which involves the Kerberos service), they ask the domain for group policies, and they do this using the domain name, not a particular DC name, like this: \\example.com\SYSVOL (and not, for example, \\dc1.example.com\SYSVOL). You can see a domain apex has several A records, one for each domain controller (4th and 5th lines of the example). The client will use randomly selected A record to connect, so each DC will have roughly the same share.

Score:0
cn flag

You can do load balancing by simply using the domain name. There is usually an A record for each domain controller in the same as parent record.

Note: this is not high availability and should not be considered such.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.