Hi there! In this article, you’re going to learn how you can use the DNS to manage your multi-cloud implementations. We’ll be using Constellix’s very own multi-cloud management solution, that we call Traffic Steering.

What is DNS Traffic Steering

Traffic Steering means that whenever a user makes a query for your website, your DNS provider will dynamically update your DNS records to point to the fastest provider, in real time! These updates are made based on data we’ve gathered from our Real-User Monitoring service.

That’s data that we’ve grabbed from actual users’ browsers. So whenever a traffic steering decision is made, it’s based on dozens, even hundreds, or thousands of users’ experiences.

All of this data allows us to paint a picture of the current state of the Internet that is so accurate, we can actually predict which cloud provider is fastest for each of your website visitors depending on their location and their network.

But this isn’t your typical Traffic Steering service... This is Constellix…The only Traffic Steering provider that combines Real-User monitoring with Health monitoring. As well as a proprietary Predictive Routing service… but we’ll talk more about that in just a minute.

Let’s start with the basics. Keep in mind there is a bit of a learning curve in order to get up and running with Traffic Steering.

If you can stick with me for the next few minutes, by the end I promise you’ll be a multi-cloud master!

In all of our explanations, we will talk about multi-CDN configurations. But you can use these same techniques for multiple DDoS protection vendors, as well as other cloud services.

A Primer on Multi-CDN Management

Single CDN Configuration

When a user wants to go to your site, they’ll enter your domain into their browser. That initiates a DNS lookup that will end at the authoritative DNS provider… that’s the company that hosts your DNS records, like Constellix.

Here we’ll find a CNAME record that points www.site.com to our CDN’s origin.

Easy, right? But this is no longer a viable solution... It’s actually considered a poor practice to use a single CDN service. Two reasons:

• CDN outages are inevitable. You need a backup plan for when that happens, and a single web server doesn’t cut it.
• Two, no single CDN vendor performs the best across the globe or even regionally.

Basic Multi CDN Config

So let’s throw another provider into the mix. The thing is, we need something that sits in front of our DNS records that decides which CDN should be used.

You could pop in a load balancer in front of your DNS records, but that adds an extra lookup. Plus hardware load balancers are expensive and require a lot of maintenance.

Instead, let’s use a different kind of DNS configuration, like a round-robin record configuration, or make things simpler with Record Pools. These pools will rotate through your list of CDN URL’s and spit out the next in line each time it is queried.

But what happens if one of your providers has an outage? Good news! Pools have built-in health monitoring and failover! As soon as we can’t reach a provider, it will be removed from that pool until it comes back online.

So now we’ve solved one problem, redundancy and outage prevention. But what about performance?

Optimize Your Multi-CDN with Smart DNS Traffic Optimization

Pools also have baked in regional latency monitoring, but we call it Internet Traffic Optimization, or ITO for short.

ITO uses our vast network of OVER 100 monitoring nodes to test the response times of each of your CDN providers. It sends those metrics to our DNS engine which will spit out the best provider in each region.

The problem is, ITO isn’t specific enough. It makes a sweeping generalization of who the best provider is for your region, not your actual location or the network you are on.

And where are these metrics coming from? Monitoring nodes, located in data centers… and your users are most likely not sitting in data centers.

So we came up with something better! Instead of using synthetic monitoring nodes, we power our ITO technology with Real User Monitoring metrics. We call this service: Traffic Steering.

Traffic Steering depends on real user monitoring, or RUM for short, to account for the “last mile” of user experience… that mile is made up of hundreds of networks your users are depending on to connect to the Internet.

How Traffic Steering Works

Let’s start with a basic DNS query for our website www.site.com, which is using our new Traffic Steering service. Before the record lookup happens, Constellix will first look at where the user is coming from.

In this case, we are making the request from the United States which is in the region of North America East, over the AS number 64496 (remember that number, it'll come in handy later).

What is an AS (ASN) Number?

AS numbers, or ASN’s, are used to identify different networks. In this case, it represents the ISP (Internet Service Provider) we are using to connect to the Internet. Later on, Traffic Steering will use this information to decide which CDN provider is fastest for our network.

Okay, back to our record lookup. Here we have four records for www. Three of the records have filters applied. These filters are actually rules that must be met in order to use that record.

How do IP Filters Work?

Each filtered record is named for a region, country, and a CDN provider. For example, "NAE USA CDN1" means that the filter is for the region of North America East, in the United States, for CDN1.

Filtered records can only be accessed if the querying client is in that specific region, country, and is using one of the networks (ASN's) specified in the record.

Let’s open up a filter and see how this works. Here we have a country and a list of the ASN’s of the different networks that have been detected as being the fastest for that CDN provider in that country.

So when we make our request, Constellix will check if any of our filters contains both our country and ASN.

Then Constellix will return the corresponding CNAME record which points to that CDN provider’s URL.

In this example, our ASN of 64496 matches the NA East USA CDN1 filter. Now we have access to the corresponding CNAME record with the URL of CDN1.

Great job! You made it through your first Traffic Steering lookup!

Let’s see what happens when we finish the DNS lookup...

Now, our browser is going to load the website’s files. Since www.site.com is using Traffic Steering, it will have RUM installed on the website.  

That means there is a short script, called a beacon, that is embedded on our website. The beacon will fire whenever the page is loaded.

This beacon operates in the background and users won’t even know it’s there… but it’s actually doing something pretty cool.

On each page load, the beacon will attempt to load a pixel from all of the CDN providers that you can use in our Traffic Steering solution.

Then… We take the response times and push them to our RUM engine, where we decide which provider is the fastest for that user’s network.

In this example, CDN3 is the fastest so Constellix will immediately update the IP filter for North America East USA for CDN3 to include the ASN of our network.

Okay, but just a minute ago our ASN was supposedly faster with CDN1. What happened?

Traffic Steering Updates

Well… The Internet is volatile and traffic conditions can change in the blink of an eye. So what may have been fast a few hours ago, may not hold true now.

Constellix stays on top of traffic fluctuation by constantly updating these filters as CDN performance changes for each ASN.

In this case, Constellix will remove AS64496 from the North America East USA filter for CDN1 and add AS64496 to the North America East USA CDN3 filter where it is currently the fastest.

What happens when you don't have enough RUM data?

Traffic Steering works best when you have more RUM metrics… That means more website visitors from different countries using different networks. The more people who trigger the RUM beacon, the more networks we will be able to add to your Traffic Steering filters.

But what if a user’s ASN doesn’t match ANY of our existing filters? It would be easy to just have them use the World/Default record (the one that didn't have a filter applied), but the default relies on our synthetic monitoring.

Remember, we talked about synthetic monitoring earlier when we showed you how ITO works. It’s nowhere near as accurate as RUM.

Smart CDN Routing

So instead, Constellix will make correlations from the existing RUM data to predict which CDN will be fastest for that user’s network based on what country the query originates from.

Let’s see how it works.

Here, we have a user in Germany making a query over the AS65100 network.

Unfortunately, no one using her ASN in Germany has triggered our RUM beacon so we don’t have any data yet.

But we do have her country. So what Constellix will do is look at the existing data from Germany for each CDN provider and figure out which one was consistently the fastest.

In this case, CDN2 saw the strongest speeds in Germany so Constellix will infer that CDN2 will also be the fastest CDN for AS65100 and will return CDN2’s URL.

But what happens if CDN2 is down? Keep in mind that we don’t have any existing RUM data for AS65100 and now predictive routing won’t work because the best CDN for Germany is down.

In this case, we will have to use the default record. That’s that fourth record we saw back in our first example that didn’t have a filter applied.

But this record isn’t your typical DNS record. It uses ITO, our latency monitoring service, to determine which CDN provider is the fastest according to our network of synthetic monitoring nodes.

Right now, CDN2 is both healthy and responds faster than any of our other CDN providers in Europe, so Constellix will return the URL for CDN2.

Multi-Cloud Takeaways

Do you feel like a multi-cloud master, now?

You should! By now you have a greater understanding of the different multi-CDN strategies using the Domain Name System. And you learned how Constellix’s Traffic Steering solution answers queries.

You also got a sneak peek of how Constellix uses predictive routing techniques to anticipate traffic conditions. And you've seen how synthetic monitoring can be used to augment RUM when your providers have outages.

Now go forth and deploy your multi-cloud with confidence.