Prevent Branch Office Domain Controllers from registering generic DNS Records and Netmask Ordering
In networks with several sites, like branch office sites and a headquartes site, by default domain controllers in each site will publish DNS SRV resource records for the site (site-specific) in which the domain controller resides and further in a generic (non-site-specific) portion in the DNS namespace.
In the figure below you will see marked in yellow the generic (non-site-specific) portion to publish DNS SRV resource records.
If now a client from a network (Subnet) can’t find a domain controller in its local site, it will query the generic (non-site-specific) portion of the DNS namespace to find another domain controller.
In that case the client may get returned a domain controller from another branch office instead one of the central site in the headquarters data center.
To prevent clients will get a domain controller from a different branch office site instead one of the central site, you can configure the following group policy and assign it to the OU where the branch office domain controllers are homed.
This policy will ensure that domain controllers assigned to it will not registering generic (non-site-specific) DNS SRV resource records.
Computer Configuration -> Policies -> Administrative Templates -> System -> Net Logon -> DC Locator DNS Records -> Specify DC Locator DNS records not registered by the DCs
LdapIpAddress Ldap Gc GcIPAddress Kdc Dc DcByGuid Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd GenericGc
The following tables contain mnemonics, types, and owner names of the domain controller locator DNS records that should not be registered by the satellite domain controllers and global catalogs to optimize the domain controller location.
Which network (Subnet) belongs to which site you can configure through Active Directory Sites and Services console.
DNS Netmask Ordering
Another point regarding the above site specific DNS SRV resource records, are multiple DNS A-Records with round robin and netmask ordering enabled on the DNS servers.
Both, round robin and netmask ordering are working together. If you had services in your network which are available redundant under multiple IP addresses, DNS will respond to a request with a list of potential IP addresses corresponding to several servers that host this identical service.
With each DNS response, the IP address sequence in the list is permuted. Traditionally, IP clients initially attempt connections with the first address returned from a DNS query, so that on different connection attempts, clients would receive service from different providers, thus distributing the overall load among servers.
In case also netmask ordering is enabled, the responded list from the DNS server with IP addresses will be re-ordered and listed first IPs that are in the same subnet as the requested client is.
The netmask ordering feature is used to return addresses for type A DNS queries to prioritize local resources to the client.
The initial release of Windows 2000 Server can’t natively use the netmask ordering feature and the round robin feature at the same time. If the netmask ordering feature is turned on, the answers are always provided to the clients in the same order. In Windows Server 2003, this behavior changed to permit the use of both the subnet-based netmask ordering feature and the round robin feature. The use of both the netmask ordering feature and the round robin feature provides proximity awareness and load-balancing.
In many current network environments, it’s uncommon to have a subnet mask that is native to the actual address. Therefore, netmask-ordering that is based on the native class of an IP address is unreliable in predicting whether a network is local. Windows Server 2003 bases proximity on Class C regardless of the native address class.
For example, a company is assigned a 126.45.x.x subnet. It’s unlikely that an 8-bit subnet mask will be used to define this subnet in their internal network. Additionally, the company owns only part of the class A subnet. Because this range will likely be divided into class B or smaller networks, netmask ordering may not return results that are close to the client. This is true if the network configuration is different from the network configuration that is implied by the native class of address. Because Windows Server 2003 bases proximity on Class C, close resources are more discoverable.
So Windows Server 2003 and later by default uses a Class C netmask for netmask ordering. You can change this behavior with the Dnscmd command as follows.
Dnscmd /Config /LocalNetPriorityNetMask 0x000000FF
0x000000FF is the default Class C netmask.
To dermine the actual setting you can use
dnscmd /info /LocalNetPriorityNetMask
For example we have a service myservice.braintesting.de in a Class C 255.255.255.0 (/24) Subnet which had 4 published A-Records in the DNS namespace, the Subnet is located in Site A:
- 192.168.195.101 -> myservice.braintesting.de
- 192.168.195.102-> myservice.braintesting.de
- 192.168.195.103-> myservice.braintesting.de
- 192.168.195.104-> myservice.braintesting.de
The DNS Server in Site A is in the 192.168.195.0/24 Subnet.
Further we have in Site A also the following Subnets:
The network also have a Site B with the following Subnet:
The service is also in this Site B and Subnet available under the following IP address:
- 192.168.250.100 -> myservice.braintesting.de
In order that the DNS Server in Site A can respond with an IP address, that is located in the same site as the requested client is, we need to configure the LocalNetPriorityNetMask.
The default Class C netmask wouldn’t work if the client is not in the same Class C Subnet 192.168.195.0/24 as the DNS Server itself.
If the client for example is in the Subnet 192.168.196.0/24, so is this is not the same subnet as the DNS server and service itslef is and therefore from the perspective of the DNS Server, the client is not in the same site and will return all published A-Records randomly to the client unordered.
In that case it could be that the client will get the IP from the Site B with 192.168.250.100 listed first and therefore will access the service in Site B.
To solve this problem we have to change the LocalNetPriorityNetMask from Class C to a Classless Inter-Domain Routing (CIDR) netmask that will include all above 4 subnets from Site A.
The LocalNetPriorityNetMask from the DNS server should include the IP range from 192.168.195.0 -> 192.168.198.255 which is /21 or 255.255.248.0.
To configure a /21 LocalNetPriorityNetMask we need to execute the following command on the DNS server.
Dnscmd /Config /LocalNetPriorityNetMask 0x000007FF
From now on a client in the Subnet 192.168.196.0/24 is from the perspective of the DNS Server also in the same Subnet and therefore same site and will return a ordered list of IP Addresses and first IP addresss from the same site.
How to optimize the location of a domain controller or global catalog that resides outside of a client’s site
Description of the netmask ordering feature and the round robin feature in Windows Server 2003 DNS
Service record (SRV record)
Classless Inter-Domain Routing (CIDR