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 nameservers. These networks use Anycast technology to make sure that all queries are answered by nameservers in the querying client’s region.
Since we know which nameserver is being queried, we can infer what region the user is located in.
Then the nameserver will answer the query with a record that has been preconfigured for that region.
Our own basic GeoDNS service, the Global Traffic Director, 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.
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.
Now we get to dig into the exciting stuff... GeoIP services like GeoProximity and Geo IP Filters!
GeoProximity uses eDNS subnet information to route users to the closest resource in your network.
Say you have a network of web servers, each hosting a copy of your website like a basic CDN service. Each time you get a new query, the GeoIP engine will figure out where the query is coming from and based on the location of the subnet it will return the IP address for the closest web server.
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.
Yes, that’s actually what its called but we called it RUM for short. RUM captures the entire journey from your users’ browsers and your resources. That means every hop, every ISP your users rely on. All of this data is combined to paint an accurate picture of the current state of the Internet.
If you think of RUM in terms of navigation, it’s just like using a crowd-sourced navigation app, like Waze. Waze captures the navigation experiences of all of its users and uses that data to show current traffic conditions like congestion, road closures, and accidents. It will even automatically update your route to bypass issues as they happen.
DNS providers like Constellix have something like Waze for updating your DNS configurations. We call it Traffic Steering. It uses RUM data to determine which upstream providers are the fastest for each network. Then automatically updates your routing configurations using GeoDNS rules to avoid network congestion and outages.