Hey y’all, Mark here again. When visiting a customer PFEs tend to get a bunch of questions that have been “saved up” over time. One of my frequent customers always has a massive list for me when I get there. If they are reading this, they know who they are. Many of these questions are the types where it isn’t causing a production issue where they’d call in for support to determine root cause but just little annoyances they’d like to get figured out. If you have those feel free to use the contact us button, it might turn into a blog post. This is a perfect example.

 

 

clip_image002

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 4th time would be identical to the 2nd 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.

clip_image003

 

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

Mark “your mockingjay in this crazy tech world” Morowczynski