We had a security incident recently where we needed to rebuild the network. For the time being we are just putting things back the way they were until we have more time to come up with a better go forward plan.

We have many locations that do not have their own server infrastructure on site and use our main location for DNS. These remote sites are located in that same site per ADSaS. The VPN tunnels at these sites can only see our main location. We have other sites with Domain Controllers in them that the remote sites do not need to see.

When we go to a machine at set its DNS server and do lookups to our domain the query result is returning all our Domain Controllers in our organization. This includes servers it cannot see. After several passes of ipconfig /release and ipconfig /renew it finds the correct Domain Controllers and we can move forward.

I turned on DNS Client logging on these machines and I can results like this...

Query response for name ourdomain.net, type 1, interface index 0 and network index 0 returned 0 with results;;;;;;

and what happens is that the order of the results shifts after each release renew.

When I look at NS for our sites it looks correct. I am trying to keep the information lean as I do not know what would be useful to include and being too verbose will put off some people.

Why are the DNS clients being offered Domain Controllers IPs that exist outside their site? Those are all valid Domain Controllers but not for all PCs. Some of those are relative to their own sites.

  • I'm not understanding what it is you're asking. The DNS clients are asking their configured DNS servers for DNS servers? Do you mean that the DNS clients are asking their configured DNS servers for Domain Controllers? – joeqwerty Sep 12 '19 at 0:01
  • If you really do mean that the DNS clients are asking their configured DNS servers for DNS servers, can you explain the type of query you're seeing on the client? Do you see the DNS client ask the DNS server for NS records? – joeqwerty Sep 12 '19 at 0:02
  • @joeqwerty This was hard to write... I am trying to add machines to your domain and it fails. When I ping the FQDN of the domain it is reaching out to DNS servers that the host was not configured for. Flushing the dns several times will make it so the ping eventually succeeds. This is not normal behavior for me. That log above shows that I am looking for all A records of the domains FQDN and the order offers the wrong one. I would have figured the DNS server I statically assigned would have been the the primary – Matt Sep 12 '19 at 12:20
  • 1
    Your phrase "When I ping the FQDN of the domain..." points me in this direction: Assuming AD-integrated DNS, when you ask DNS to resolve the FQDN of your domain to an IP address (whether indirectly when pinging, or explicitly with nslookup, AD-integrated DNS will give you the IP addresses of all domain controllers, regardless of site. If you run nslookup yourdomain.local over and over, you'll see that the response is a list of the IP addresses of all of your domain controllers, in rotating order. It will also tell you which DNS server answered. Does this help explain what you are seeing? – Doug Deden Sep 12 '19 at 12:48
  • 1
    As has been pointed out, you're conflating Domain Controllers and DNS Servers in the title and in parts of your question. I've submitted an edit to your question. – Semicolon Sep 12 '19 at 18:30

This is how DNS works. DNS is not site aware - specifically not AD Site aware.

Now, if so configured, the DNS servers can be made to be subnet aware using netmask ordering. If memory serves this option is enabled by default. Also by default netmask ordering is based upon a Class C (/24) subnet. However, even with netmask ordering enabled, if none of the IP addresses for the A records exactly match the /24 subnet, of the requesting client, all valid A records will be returned. You will also note (with round robin enabled) that these responses will rotate with each successive query (independent of the requesting DNS client).

It should be noted that netmask ordering doesn't actually take into account the subnet mask of the client, it simply checks the first three octets of the requester's IP and if it matches wwith the first three octects of any of the responses, those responses will be returned at the top of the list.

The command to change the netmask sensivity from the default (/24) to another subnet is as follows (example details setting a /16 subnet mask):

dnscmd /config /LocalNetPriorityNetMask 0x0000FFFF


What I believe you're trying to accomplish can be done by using DNS Policies; these require DNS to be running on Windows Server 2016 or newer. You can define client subnets and then by creating a DNS Server Query Resolution Policy, you can dictate which A records will be used when queries originate from the specified subnets.

  • How did organizations do this before dns policies.... Our environment is not an anomaly. I am sure there are other orgs that work as a hub and spoke network. – Matt Sep 12 '19 at 19:41
  • Generally, netmask ordering is sufficient - I would say. In nearly every environment I've been in, each site was a 10.X.X.X/16, so with net mask ordering configured on the DCs to adhere to the /16 block, its never been an issue. Really, unless for some reason you have DCs in 10.10.x.x/24 and your clients in 10.11.x.x/24, you shouldn't have an issue out of the gate. – Semicolon Sep 12 '19 at 20:03
  • Moreover, once the client is actually joined to the domain and learns its AD site, it will make use of site-specific Service Locator Records (SRV) to find the "nearest" Domain Controllers for authentication, GPO processing, etc. – Semicolon Sep 12 '19 at 20:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.