Link to home
Start Free TrialLog in
Avatar of convergint
convergintFlag for United States of America

asked on

Preferred domain name resolution through multiple subnets and locations

This our scenario simplified:

Multiple physical office locations, each has their own DC and subnet.  Each location connected with a VPN router.
Location A - 192.168.1.x, DC and DNS server is 192.168.1.2
Location B - 192.168.2.x DC and DNS server is 192.168.2.2
Location C - 192.168.3.x DC and DNS server is 192.168.3.2

In location C, we have additional subnets on our switch for VLANs 10.10.1.x and 10.10.2.x, these subnets do not have servers, they are for wireless clients, etc.  These route fine through the switch and to other locations.

In our DNS forward lookup zone we have setup the following for our domain EXAMPLE.COM:
Host (A) 192.168.1.2
Host (A) 192.168.2.2
Host (A) 192.168.3.2

The problem we have is that when you are on the subnet 10.10.1.x and try and ping EXAMPLE.COM, it might resolve the host in location A, B or C randomly.  If I do a flushdns on the client, I'll get a different server, but it is still random if I ever get Location C's server.  If I'm in the main subnet 192.168.3.x, I will always get the 192.168.3.2 server when I ping EXAMPLE.COM.

I need to figure out how to give priority to the server in location C when you are on the 10.10.x.x subnets and need to resolve EXAMPLE.COM.
ASKER CERTIFIED SOLUTION
Avatar of sfossupport
sfossupport
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of convergint

ASKER

I had never heard of the netmask ordering until now so it's a step in the right direction.  From what I've researched, it lets you change the default Class C prioritization to a different class.  However in our case I'm not entirely sure how it would work as our 10.10.x.x subnet is completely different from the 192.168.x.x subnet.

Admittedly I am terrible at figuring out subnets but I don't understand how you could have a netmask to direct the 10.10.1.x subnet to the 192.168.3.x subnet.
Also, in DHCP, make only that server for that location the DNS server (prefered for every nic). Don't put any others except on the servers themselves.
Yup, each subnet location only has the local DNS server in DHCP.  I would have assumed that if I specified Location C's DNS server that the DNS would be somehow smart enough to know to prefer the same subnet to resolve multiple host records, regardless of what subnet the originator's request is.
Nope, but you are smart enough to configure DHCP scope options to only go to the internal DNS server, and then the internal can be configured with forwarders to outside servers. Zone transfers between sites for all the DNS records.
Avatar of DrDave242
Do you have your sites and their associated subnets configured correctly in AD Sites and Services?

Be aware that simply pinging the domain name is not an accurate way to determine what DC will be returned by the domain controller location process on a client or member server; there's a lot more to it than that.  As long as you've got sites and subnets configured correctly, a client looking for a DC should always find a local one first.  Notice that I said should and not will.  :)
Yes all our sites are properly associated with the subnets.  The problem is not clients finding a DC, it is the resolution of the domain name.  It is an issue for us as we are using DFS and it is setup with the domain name as the path.

Not my first choice but unfortunately it is done by our HQ IT team and they don't have multiple VLANs with different IP subnets at their other locations.

I'm thinking that the only way I will be able to resolve this is to setup each VLAN at Location C on the NIC on the DNS server at Location C, and have a DNS Host record for each VLAN.
Are wireless clients at location C hitting the wrong DFS targets, then?  Since DFS is site-aware, it uses some of the same mechanisms as DC location.  Someone hasn't been screwing with the target priorities, have they?

You may want to try setting the "Exclude targets outside of the client's site" option in your ordering method settings, but notice that the target priority settings can override that.
Yes, that is exactly our problem we are experiencing.  Not all our sites are linked through VPN so sometimes, the clients will never be able to resolve the DFS share.

The referrals are fine but since a client is trying to resolve EXAMPLE.COM\LOCATION C\SHARE it may hit a server that is not local or not accessible.
DFS is site aware because of its use of netbios broadcasts. Use DFS over DNS and make sure it's configured to do so.

http://support.microsoft.com/kb/244380
Yes DFS is using fully qualified DNS names.  Like I mentioned before, the problem we have is that DFS uses EXAMPLE.COM to resolve the file shares.  If you are on a VLAN in one location you might resolve the non local DC server to resolve the DFS share.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial