GeoDNS Services Explained

‍Modern applications and websites depend on networks made up of multiple web and application servers. This creates redundancy for critical resources and improves load times, since resources are closer to end-users. That means, metaphorically, there are now multiple phone numbers for an FQDN --thus, breaking the phonebook analogy. Instead of a phonebook, we think that the DNS is more like the Yellow Pages, since there can be multiple locations (or servers) for a business.

Say we want to find the address for our favorite pet store, Onyx’s Pet Supply. We would look it up in the Yellow Pages. The Yellow Pages acts like a nameserver and associates a business with an address - or multiple addresses. In this case, Onyx’s Pet Supply is a retail chain, so we will see multiple addresses.

But now we are stuck with a choice, which location do we go to? Do we go to the closest one? How do we know if it's closer? Do we go to the one that will take the least amount of travel time? How do we measure that?

We need some kind of logic that sits in front of these addresses that can help us decide which one is "best" for us. We call this logic GeoDNS.

GeoDNS, in its most primitive form, is like calling 411 and asking the operator where the closest Onyx’s Pet Store is. The first thing the operator will do is ask you where you are located. Or they might be able to see your area code and assume that you are calling from Washington DC. Or maybe all 411 calls are directed to the closest operator, which is likely in your immediate region. Regardless of how it is obtained, your location is the first thing the operator will need.Once your location is established, the operator will respond with a list of all of the locations of Onyx’s Pet Stores in the Washington DC area.

GeoDNS uses something akin to this… When a user makes a query for a domain that is using GeoDNS services, the authoritative provider will first look at where the user is located.How is that possible? Anycast.DNS services are built on globally distributed networks of name servers. These networks use Anycast technology to make sure that all queries are answered by name servers in the querying client’s region.Since we know which name server is being queried, we can infer what region the user is located in.Then the name server will answer the query with a record that has been preconfigured for that region.

By this point, you have an idea of how Anycast networks operate and how nameservers can infer where querying clients are located. Unfortunately, this kind of primitive GeoDNS doesn’t scale to the modern complexities of the Internet. .Let’s continue our operator analogy.

Basically, what we have is a list of pet stores that we can pick from randomly and attempt to visit.This might be all you need if you live in a small town, but as we scale up in size and population, things get more complex. The list of stores become far too general for the scope of queries we are trying to resolve. Someone making the same request from the other side of town is going to get the same list you got.

This poses a few problems: the list of pet stores doesn’t account for how close each store is to our current location; we also don’t know if any of these stores are open; or if there’s a road closure along the way.

These same obstacles arose as the Internet became more complex. Regional responses assume that everyone in a large area should be directed to the same server. Let’s look at a quick example.

Our own basic GeoDNS service, the Global Traffic Directo splits up the globe into five regions, one of which is North America East. Each region has its own dedicated nameserver sets which host region-specific responses for each record.

Anytime a user in NAEast makes a query, they will be answered by a nameserver in NAEast with a record that was created specifically for NAEast. Simple, enough.

Now think of North America East. That’s everything from the Mississippi to the Atlantic Ocean. From Miami to the tip of Maine. That ’s hundreds of thousands of miles, millions of people that you’ve lumped into one group. It’s very unlikely that the response you chose for NAEast will actually deliver the best experience for all of your users.

Instead, let’s use this kind of GeoDNS service as a fallback. If we can’t detect their actual location (using more advanced GeoDNS) then we will rely on a regional response.

In the early 2010’s someone figured out that you can map IP addresses to countries and cities. DNS providers, like Constellix, started using databases with these mappings to infer where queries come from. There are a few DNS services that use these mappings, they are called “GeoIP services”.

While GeoIP is exceedingly more accurate than it’s predecessor, it does have a few fallbacks.

The location to IP mapping actually occurs when an IP block is delegated. Network operators regularly move IP's to different locations or networks around the world. When these moves happen, the GeoIP data for those IP's are inaccurate until they are updated.

‍We recommend that you use both GeoIP and regional traffic routing services (like GTD) simultaneously, to correct for outdated IP to location mappings.

Let’s go back to our navigation analogy. We left off with Basic GeoDNS, which acted like an operator. Advanced GeoDNS takes us decades into the future, giving us something like a basic GPS device. This GPS is able to detect our exact location, down to what city we are in and based on that data, it can return a list of local pet stores.

Okay, that’s great, but how do I know which store is closest to me?

At this level of granularity, we need to understand where our user data is coming from. So far, the closest we've gotten is mapping IP data to a location. But the IP’s we are using aren’t the IP addresses of user devices. They’re actually the IP addresses of resolving nameservers.

‍These nameservers are usually ISP’s (Internet Service Providers) or the company you purchase your Internet services from. The only way to get more granular resolution is to use something called the eDNS client subnet.

Resolving nameservers have the capability to pass information about users using eDNS client subnet. The subnet is a short suffix that is appended to the end of an IP address that indicates where a user is located. As of February 1st 2019, otherwise known as, all resolvers are required to be eDNS compliant and pass eDNS client subnets to the next resolver.

eDNS gives authoritative DNS providers clarity into where users are located, revealing that last mile between resolvers and users’ actual locations. Your DNS provider can use this information to make more accurate traffic routing decisions.

By this point, we’ve figured out how to leverage GeoDNS to accurately target our users and deliver location-specific responses. But none of what we’ve learned comes close to tackling the volatility of the Internet. For that, we need network monitoring.

Monitoring services use vast networks of nodes that constantly ping your resources to determine whether they are up or down. They can also detect how long it takes to reach a resource (response time) and the number of hops between a user and the resource.

‍You can inject this data into your DNS configurations for truly intelligent query routing that can react to changing network conditions.

‍Think of DNS monitoring like radio traffic updates. Every few minutes, a radio announcer will cut in with an update on current traffic conditions. You can use this information to alter your route and avoid road closures and heavy traffic.With a traditional GPS device, you have no concept of traffic conditions and if you live in a congested area like DC then you’re no better off than you were with a paper map.

Even with all the capabilities of GeoProximity, there are still outliers it can’t account for.

‍In that case, you need to be able to create custom routing rules that look for these anomalies and answer them with a unique response.

We call these rules “IP Filters”. These filters sit in front of your configurations and look for users that meet their requirements such as region, country, city, ISP, or IP address.

IP Filters are great for those edge cases where traditional rules actually hurt performance and you need to create an override. You can also use them to prevent certain localities from accessing your resources, like for copyright reasons or trade laws.