DNS lookup issue

Andrew Hamilton
Andrew Hamilton used Ask the Experts™
on
I have a domain that is spread out over 15 plus offices scattered around the globe.  All the offices have IPSec connectivity back into Corporate.  Each of the satellite offices has a domain controller onsite.   My problem is this.   When I do a nslookup from our corporate site to domain.com, or attempt to ping or resolve domain.com from corporate, I am getting routed to any of the other domain controllers and not specifically to the ones located on my site.    This is also happening on my other sites.   For example, in Australia, where I have a DC and DNS server, I get resolution to other offices when referencing the domain.    What I want is when I am in an office is for the system to resolve the domain to the local servers first and only pass  to another location should the local devices be unavailable.   We have setup this in sites and services and thought we had it, but DNS just isn't cooperating.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Dr. KlahnPrincipal Software Engineer

Commented:
Have you got

a) The network connection on each machine TCP/IP configured to point at the local DNS servers instead of generic servers or DHCP-obtained servers, or
b) The local DHCP servers providing DNS server addresses that point to the local DNS servers?


Connection DNS resolver configuration
Andrew HamiltonDirector of Global Infrastructure

Author

Commented:
Yes,  The local systems are referencing the local DNS servers in the IP set.  They are assigned via DHCP, but each site is using local DNS servers.
Dr. KlahnPrincipal Software Engineer

Commented:
Is there any difference in behavior if you manually set the DNS server IP addresses rather than rely on the DHCP supplied ones?
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Andrew HamiltonDirector of Global Infrastructure

Author

Commented:
To clarify,  

   the domain in question is my local AD domain, not an external domain.
Dariusz TykaICT Infrastructure Specialist Senior

Commented:
Are your sites properly configured via active directory sites and services? Proper subnets associated with proper sites? DCs placed properly in sites as well?
Distinguished Expert 2018

Commented:
DNS just does round Robin by default. But if you've configured sites and services, clients needing a DC will query for ALL DCs (since AD is also supposed to be fault tolerant) and choose the one closest to them based on sites/services info.  But Microsoft adheres to DNS standards by default, so from a pure DNS standpoint, things are working as designed.
Andrew HamiltonDirector of Global Infrastructure

Author

Commented:
All the sites are defined in sites and services with the related subnets
Distinguished Expert 2018
Commented:
Like I said, completely expected behavior.   Specifically, doing a normal "nslookup domain.com" is going to return a generic A record.  That A record only exists for clients that are NOT active directory aware.   AD aware clients (such as any windows client machine) will actually query SRV records, which will return everything the client needs to determine the DC with the least cost.

Perhaps this will help in understanding:

https://technet.microsoft.com/en-us/library/cc759550(v=ws.10).aspx

In short, this is working as expected.  Doing an nslookup for domain.com will not honor site affinity, nor should it.
DrDave242Principal Support Engineer
Commented:
This sounds like a netmask-ordering issue. As Cliff said, DNS isn't site-aware, but it is subnet-aware if netmask ordering is enabled (which it is by default). Netmask ordering works in concert with round robin to ensure that when multiple DNS records are returned in response to a query, records with addresses in the client's subnet will be returned at the top of the list, so that the client will attempt to access a local resource if one is available.

In the DNS console of one of your DNS servers, right-click the server's name and select Properties, then select the Advanced tab. Is the Enable netmask ordering box checked? If it isn't, check it.

Now, even if netmask ordering is enabled, it apparently defaults to a 24-bit subnet length in order to determine which records are in a client's subnet. That's great if you actually have a 24-bit subnet mask, but it can screw things up if you don't.

Fortunately, this behavior can be modified via the registry. Since I don't know what the subnet masks are in your environment, I can't tell you exactly what its value should be, but the relevant registry location is discussed here. Ignore the "2003" in the title of that article; it's still applicable.

More information on this can be found here.
Andrew HamiltonDirector of Global Infrastructure

Author

Commented:
@DrDave242

  In my specific case I have multiple subnets on my corporate site and only 2 DNS servers sitting in a /16 subnet separate from the Floor subnets.   I think this method could work, but how do you address the issue of workstations out of the subnet of the DNS servers?
DrDave242Principal Support Engineer
Commented:
The subnet of the DNS servers isn't as important as the subnets of the clients and the resources they're trying to access (except when the clients are querying for the DNS servers themselves, which will happen fairly often if DNS is on your DCs). If you have multiple subnet masks of different lengths, you may have to play around with different values to see which one gives you the best results. Nslookup will come in handy here, as it'll show you the order in which the records are returned to the client.

Also, the value isn't stored in the registry as I said above; it's modified with Dnscmd, as you probably already noticed. Apparently I need to read articles more carefully!
Distinguished Expert 2018
Commented:
I want to reiterate though that this usually isn't important.  If you have a LOB app that has multiple site-specific servers then yes, you may want to look into this (although I'd argue that there are USUALLY better ways.)  But if you goal here is to make sure clients reach the closest DC, they *don't* rely on DNS A records to do so.  So this becomes superfluous.  The client is able to determine its site with a single lightweight query, and form there the client is smart enough to construct site-specific SRV queries to find the right DC.  It does *NOT* use "domain.com" generic A record queries.  Since almost all of the deterministic logic is done client-side, fixing this is really an aesthetic choice. It won't improve performance, as performance is already optimized by the underlying architecture (assuming you've defined your sites well.)

-Cliff
DrDave242Principal Support Engineer

Commented:
No further response from asker.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial