Comparing Latency-Based DNS Routing Services
Comparing Latency-Based DNS Routing Services
These two types of latency-based DNS routing will ensure that your user can be quickly switched to the fastest server available.
Join the DZone community and get the full member experience.Join For Free
SignalFx is the only real-time cloud monitoring platform for infrastructure, microservices, and applications. The platform collects metrics and traces across every component in your cloud environment, replacing traditional point tools with a single integrated solution that works across the stack.
There has been a lot of buzz in the managed DNS world about new routing policies that combine GeoDNS with monitoring services—commonly referred to as “latency-based” or performance routing. Unfortunately, there hasn’t been much literature that compares or really digs into the differences between the available services.
In this article, we are going to try to establish the key differentiators between latency-based routing services, how to use them, and popular use cases they can solve.
Before we get started, let’s go over some basics so that we have a common language.
GeoDNS: Routing policies that direct users to different origins/endpoints based on their location.
Origin or Endpoint: Could be a server or system that is identifiable by an IP address or hostname.
Monitoring: The process of gathering performance data from endpoints using a network of monitoring nodes.
Latency: The time it takes to respond to a request. Measured in milliseconds (ms).
Until recently, this kind of DNS management was only used by large enterprises that had the staff and resources to create their own algorithms and hardware to do it. Now, cloud-based managed DNS providers have opened the floodgates and made DNS performance routing accessible and affordable for all.
GeoDNS alone has made huge strides over the past few years, beginning with regional traffic segmentation and over time becoming more granular with city or IP routing policies. Constellix currently offers the most granular routing services called IP Filters which allow users to segment traffic based on the location (city or coordinates), IP address, protocol, or ASN of end-users.
But GeoDNS can only do so much. The problem is, the internet is constantly shifting and DNS records need to be able to adapt to the changes.
The first strides were made by integrating health checks into record configurations. DNS Made Easy was actually the first company to offer a DNS failover service that automatically updates records when an origin is detected as down.
Failover is great for staying online, but it does nothing for performance. This necessitates real-time monitoring and integrations that dynamically update routing policies based on the response times of endpoints.
Slowly but surely, more providers are offering these kinds of services, opening the doors for wildly advanced routing techniques. The one that has us most excited uses regional routing policies combined with health monitoring.
The result is users are routed to the closest and fastest responding server every time they make a query. You can use this routing policy to create your own CDN or manage a multi-CDN configuration.
How It Works
We’ll show you how to setup latency-based routing with two different types of performance routing service. In both examples, we will use six origins located in: London, Amsterdam, Paris, New York, Miami, and Ashburn.
#1. Regional Latency
A few providers have introduced regional latency-based routing services. Route53, for one, allows you to create regional records (instead of one global record), each with one origin. Users are routed to the fastest responding regional origin, based on historical monitoring data (more on that in a second). That means users (regardless of location) will be sent to the origin with the lowest latency.
In this example, we only need to create two regional records: US East and Europe. Since only one origin can be used per region, you’ll have to pick your strongest one.
Now you can attribute a health check to each origin. If an origin is detected as unavailable it will be removed from that record until it is available again.
Each time your domain is queried, the monitoring nodes will detect the location of the end-user and use historical data to route the user to the origin with the fastest connection.
The problem is, latency is calculated using data gathered over an undefined time period—meaning it could be days or weeks of old data. Internet conditions can change drastically in a matter of minutes, and what was fast to many users a few minutes ago could potentially disrupt your service.
This may be enough for you if the provider’s network matches up with the rules you want to create. Or, if you only require one origin per region. But for those who don’t, you will need a provider that offers more advanced GeoDNS.
#2 GeoDNS + Latency Monitoring
The other kind of service you can use combines advanced GeoDNS rules with latency monitoring. In this example, we’ll use Constellix’s ITO record pools as our service.
First, you need to create two record pools (groups of origins), one for each region. London, Amsterdam, and Paris in a Europe record pool; and New York, Miami, and Ashburn in a US East pool. Ideally, you want to have two or more origins in each pool for redundancy and better accuracy.
Now you can create health checks for every origin. Then go back to your pools and integrate the monitoring checks. Origin statuses are checked as often as every two seconds (depending on how many monitoring nodes you have chosen) and update record pools as often as every 30 seconds.
If a check comes back as down, that endpoint is removed from the record. Checks also measure the response times of endpoints from multiple locations. This data is used to dynamically update the record pool to return only the fastest endpoint(s). In Constellix, you can choose to return just one or multiple origins in a record pool.
Last but not least, you will apply your pools to records. Each pool will need to be applied to a region-specific record. So we will create two records with the same name in each region with the appropriate pool applied.
Now, if a user queries your domain from somewhere in Europe they will be automatically routed to the fastest responding (and available) origin.
Let me know if you’ve used any other kinds of regional/latency-based routing services and how they compare with the ones we talked about here. Would love to hear your thoughts in the comments.
Opinions expressed by DZone contributors are their own.