How ‘netmask ordering’ feature in Windows AD DNS affects the resultant queries

The netmask ordering feature is used to return addresses for type A DNS queries to prioritize local resources to the client. For example, if the following conditions are true, the results of a query for a name are returned to the client based on Internet protocol (IP) address proximity:

• You have eight type A records for the same DNS name.
• Each of your eight type A records has a separate address.

In the initial release of Microsoft Windows 2000 Server, this proximity is calculated based on the native class of address that is assigned to the client. If the client is assigned a native class A address, the responses that are sent to the client are prioritized by entries that match the client class A network membership. This is also true of native class B and native class C addresses. 

The round robin feature is used to randomize the results of a similar type of query to provide basic load-balancing functionality. In the earlier example, eight type A records with the same name and different IP addresses cause a different answer to be prioritized to the top with each query. Because a new IP address is prioritized to the top with each query, clients are not repeatedly routed to the same server.

This can be helpful if your subnets are perfectly configured in a multi site environment, but unfortunately it is not like that most of the times. It could make that a user located in London is using a domain controller in Hong Kong to authenticate or to resolve names. DNS resolution definitely affects your AD implementation! I've seen  enterprises where users are affected by this Windows 'feature', when they are connected to their corporate network or by VPN.

A "fix" is explained in the following article, very well explained, however, it is not applicable to all the cases, especially when diverse subnets exist in the same location, and that don't match with the subnet assigned to the DNS servers / Domain Controllers. It will work, again, if you design (or reorganize) your company's subnets. A workaround is to create additional A records and Cnames to allow DNS resolution of your clients to closest DNS / AD nodes... Every case is be different, but it can be done!

All clients are in the Chicago site. If the user did a DNS look up from Client01 (172.10.1.100) on the domain name Contoso.com the following DCs were returned in order

DC01-172.10.1.1

DC02-172.10.1.2

DC04-172.30.20.1

DC03-172.20.10.1

DC05-192.168.5.1

If they would run the same query a second time from the same machine the list would tend to look like this.

DC02-172.10.1.2

DC01-172.10.1.1

DC04-172.30.20.1

DC03-172.20.10.1

DC05-192.168.5.1

If they would run it a third time, it would be identical to the first time. The 4^th time would be identical to the 2^nd time. The DCs in their AD site would always be returned as number 1 and 2 in the list. This is what the desired and expected behavior was. However, if Client02 (172.10.8.1) or Client03 (172.10.9.1) did a DNS look up the list would frequently look like those above, but sometimes it would look something like this

DC03-172.20.10.1

DC04-172.30.20.1

DC05-192.168.5.1

DC01-172.10.1.1

DC02-172.10.1.2

The customer first suspected it to be a DHCP vs Static IP issue as that appeared on the surface to be the only real difference between them. The clients were getting different records returned in a round robin fashion but ONLY in their site when using a static address but when it was DHCP it would round robin through all the different records. The devil they say is in the details.

There is a setting on the DNS server on the advanced tab called Netmask Ordering. The purpose of netmask ordering is to try and prioritize local resources for clients. For example if an A record exists in 2 places, 1 on the same subnet as the client and 1 on a different subnet, return the A record on the same subnet client. It assumes since the subnets match, the resource must be closer to the client so return that address.

So what is the problem here? Netmask ordering was enabled on both DC01 and DC02. Why are the DHCP clients behaving differently? Turns out Netmask ordering by DEFAULT matches to Class C addresses (255.255.255.0) I’ve highlighted in red to show the Class C octet for the environment.

DCs

DC01- 172.10.1.1

DC02- 172.10.1.2

DC03-172.20.10.1

DC04-172.30.20.1

DC05-192.168.5.1

Clients

Client01-172.10.1.100

Client02- 172.10.8.1

Client03-172.10.9.1

Since Cilent01 Class C octet matched DC01 and DC02 Class C octet those were always being returned in a round robin fashion. However Client02 and Client03 did not match any Class C octet for any DC so all results were returned in a round robin fashion since none were considered to be close for that client.

For this environment we wanted to actually match on the Class B octet, 172.10.x.x. In order to do this we ran the following DNS command, Dnscmd /Config /LocalNetPriorityNetMask 0x0000FFFF.

DCs

DC01- 172.10.1.1

DC02- 172.10.1.2

DC03-172.20.10.1

DC04-172.30.20.1

DC05-192.168.5.1

Clients

Client01-172.10.1.100

Client02- 172.10.8.1

Client03-172.10.9.1

Now all DHCP clients in the Chicago site behaved like the statically defined client since the Class B octet (255.255.0.0) matched the octet for the DCs. DC01 and DC02 are being returned in a round robin fashion as expected.

For more info around this read http://support.microsoft.com/kb/842197

Ref: http://blogs.technet.com/b/askpfeplat/archive/2013/02/18/how-netmask-ordering-feature-in-dns-affects-the-resultant-queries.aspx