Get your DNS right

Working with IT infrastructure in geographically dispersed companies can be challenging sometimes. Getting DNS right is often one of them, especially with most the Internet services trying to overcome network limitations such as latency with local endpoints for their services (hey, that's us!).

When you point all your users to the same external DNS, even though they do not use the same outbound Internet connection, you might end up routing Internet-bound traffic incorrectly. That's because of Geo DNS. A common variant of the theme is the case where a company uses DNS forwarding to an external DNS (Google Public DNS 8.8.8.8, for instance).

So, what is the problem?

I am an Exchange guy, so if that is not you case, please bear with me that I'll get you to the point quickly. I just need Exchange Online as an example:

Let's pick My Perfect Vacation, an imaginary company based in Seychelles with operations in Africa and South America, as an example. This company configured their DNS servers to forward all the DNS queries to a local Internet Service Provider. Local to their headquarters anyway...

Now a user is trying to open its mailbox from a computer in the São Paulo Office. But the latency hurts so bad and nobody tells him why. I will do just that:

For the good people in Seychelles, the closest Exchange Online endpoint resides in Europe. At least it did the last time I checked. The thing is that intercontinental dedicated network connections can be expensive, so the company decided not to use it for general Internet access, which was a smart move. However, all the computers use local Domain Controllers for name resolution and, ultimately, the queries leave the company network from an IP address in Seychelles. What the Geo DNS does is return the CNAME for the one of the Exchange Online endpoints in Europe: outlook-emeacenter4.office365.com.

So, the connection made by the user based in Brazil end up in the European endpoint instead of the one in South America. That how it looks like in nslookup:

What if the DNS in São Paulo resolved Internet names locally? It would look like this:

That way, the connection from São Paulo to Exchange Online must go through the Internet to Europe. Dealing with all sorts of things we can't imagine are in the way but they are.

The proposed solution

Instead of routing all the DNS queries through the DNS server in Seychelles, they change the configuration, so DNS queries in São Paulo directs the users in São Paulo to one of the Exchange Online Endpoint in South America, outlook-latam3.office365.com. Done!

It is important to say that this would not affect only geographically dispersed companies. It can affect you too if you are routing your DNS queries through the wrong DNS server.