We have several offices across the globe, but our datacenters are primarily housed in two central locations (North America and Europe). There is a relatively high latency between various offices, so we try to host services in the closest location to the user (i.e. Canadian employees use Exchange services in the US, not Europe.)

This setup works well for the most part. When using services like Active Directory, Exchange or DFS, clients rely on existing site information in AD to fine the closest location.

Now, we have a request to have a common DNS name to access certain web services that are hosted both NA and Europe. Previously, we have used seperate DNS names (na-service.domain.local or eu-service.domain.local) but that becomes cumbersome for our end users.

All of our internal DNS is currently hosted on Windows 2003 and 2008 servers with Microsoft DNS. Is there any way to configure Microsoft DNS services to only respond to requests with a "local" IP address? I know that configuring multiple A records will result in a round robin style response, which is not ideal. We could also use Primary zones at each location and only enter the local IP address, but we have hundreds of other DNS entries that would need to be manually replicated to each server.

If this can't be done with MS DNS, are there other low cost alternatives? I know F5 Networks has products that can handle this, but that's at a fairly high expense.


You might have some luck with the "Subnet Prioritization" functionality in the Microsoft DNS server. Whether or not it will help you will depend on how your subnets are addressed and how your geographically "local" servers are addressed. This feature is enabled by default in Windows Server 2003 and 2008.

I'd recommend reading up on that feature. Have a look at http://technet.microsoft.com/en-us/library/dd197495(WS.10).aspx under the "Subnet prioritization" heading.

The "view" functionality in BIND would probably do what you want, too, but then you're talking about deploying a parallel DNS infrastructure and a lot of configuration.

If you have control of the web-based application you could do something off-the-wall like embed some Javascript to "detect" the user's location and redirect them on the client side. It's a bit bush-league, but it might do what you need.

  • Interesting, that is the first I have heard of this concept. Unforunately, it will not work for us as clients are rarely in the same subnet as the servers (although they may be in the larger classless subnet used to simplify routing). – Doug Luxem Jun 1 '09 at 20:08
  • In case you didn't read thru the examples: The servers and clients don't need to be in the same subnet. An exact match on the client subnet w/ the server isn't done-- rather the server does an ordering of the results based on the closest match of the client's IP address to the results. In a typical VLSM environment, the IP addresses that are geographically close to you should, hopefully, be close, bitwise, to your own IP address. – Evan Anderson Jun 1 '09 at 20:33
  • In that case, it should cover about 90% of our clients (some subnets are completely unrelated to geographic location). Thanks for he information. – Doug Luxem Jun 2 '09 at 15:45

I've had this question asked a couple of times here at work, although it never got to implementation, so this is pure theory on my part.

The best solution (hack?) I could come up with would be to have a common dns sub domain that isn't replicated. Then just put the local servers in that setup. So you would have something like this:

NA DNS Servers
web01.service.domain.local ->

EU DNS Servers
web01.service.domain.local ->

So the clients connecting to web01.service.domain.local would pickup the service's local IP off thier default dns servers. You can have them replicate inside the EU and NA but don't have the zone replicate between the EU and NA.


As a previous answer states, BIND's Views look like what you want. It allows a name server to present different configurations of the same name server to groups of clients which you define.

The groups can be defined via individual IP addresses or prefixes (like Hopefully, your EU and American hosts can be distinguished this way.

Nice side benefit: your two servers can be (almost) identically configured, BIND-wise, and thus can act as each other's failover.

A good way to think of Views is that it is a DNS server's version of virtualization. Sort of.

BIND can be obtained at www.isc.org for free.


Does the solution have to be done through DNS? If not, this sounds like a perfect candidate for IP Anycast. See this question for more detail, but in a nutshell, it is a network architecture that allows you to advertise the same IP address from multiple locations, with clients routing to the 'closest' (from a network cost perspective) instance of the IP. This way, you can simply have a global VIP (Virtual IP) for your DNS records to point to.


Besides BIND Views, the new version of Windows Server (Which is in a technical preview currently) also has a feature called DNS Policies which looks very promising for achieving what you are looking for.


I had the same issue. if domain is domain.local and I wanted webmail.domain.local to respond differently according to sites, I created a new zone webmail.domain.local (non AD integrated) and added a wildcard entry to the local ip address of the webmail server.

This domain isn't replicated anywhere but I went with master/slave configurations on each sites for redundancy.

Although this becomes a mess to manage if you need maintain frequently on a lot of sites.


New features in Windows Server 2016 DNS allows you to define policies to handle this type of scenario. More information can be found here.

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.