Teridion uses the power of advanced DNS (domain name system) features to make the internet faster for users and SaaS providers alike. It does this by determining application specific SLAs (service level agreements) based on parameters like throughput and latency and redirecting traffic via optimum paths. Let’s say a SaaS provider, Acme Corp, has a brand new service they would like to deploy to be consumed by users around the world. Typically, they would deploy this service on multiple servers in a data center front-ended by a load balancer with a DNS name. All users would hit that DNS name, for example, app.acme.com and would hit the load balancer IP address based on typical internet routing.
We know that there are factors where we may want certain traffic going over specific routes. For example, for app.acme.com, we may want to send uploads and downloads via a path with bigger bandwidth, and we may want the API calls between a client and server to be sent over links with lower latency. Internet routing is oblivious to such application needs and routes traffic on an equal opportunity basis. This is where Teridion can intercept app.acme.com traffic and make intelligent decisions based on specific application demands.
For Acme Corp, all they would need to do is make a simple CNAME change to their DNS name to point to the teridion domain (for example, app.acme.com CNAME app-acme.teridions.net). This change allows Teridion to intercept the app traffic and make better routing decisions based on application, throughput, latency etc. User traffic immediately starts getting routed to the new CNAME and takes a few minutes for the change to fully propagate. No other change, hardware or software is required from Acme Corp side. They get up to 20x faster performance without additional spending on more bandwidth or losing any visibility.
The (not so) secret sauce is how Teridion utilizes DNS and APIs to automate this on the backend.
Teridion uses multiple DNS service providers for our backend operations, one of them being NS1. Within NS1, we start with the top level domain for the app, which in this case would be app.acme.com and create our CNAME as mentioned before app-acme.teridions.net. Let’s assume that Acme Corp has multiple regions this app is deployed in to serve various geographies of users. For example, say in the US, Acme has a West coast data center in California and an East coast data center in North Carolina. For Teridion, we also want to make sure we route the users from the west side of the country to California Acme data center and users from the east side of the country to the North Carolina Acme data center. Within NS1, we can create sub-regions called app-west-acme.teridions.net and app-east-acme.teridions.net to serve the west vs east coast users respectively.
Fig. 1: End User location based on GeoIP
NS1 utilizes GeoIP as one of the methods to pin-point where the end users are located based on their source IP address. Teridion also supports EDNS0 to ensure further accuracy of the location of end users, however, works just as well without EDNS0 extensions. Once the user location is identified, within each sub-region names are A records to the TCR IP addresses. By default, all TCRs are deployed as an HA pair (or more in some cases depending upon SLA requirements). Hence each sub-region name entries may contain two or more IP addresses. It starts to look like an inverted tree structure as shown below.
Fig. 2: Teridion DNS Tree Diagram
Based on the end user location, Teridion redirects the traffic to the primary TCR. For example, for users in the west side of US, when they access app.acme.com, they get routed via the app-acme.teridions.net CNAME to the sub region app-west-acme.teridions.net eventually hitting the primary TCR IP address 126.96.36.199 (best suited TCR for their location).
Teridion also sets up TCRs for optimal performance to the Acme data center locations. Once the traffic hits the TCR IP, it gets routed over the most optimum route to a TCR closest to the destination, where it gets routed out to the app load balancer IP address. Teridion uses targets in the TCR either via an IP address or a domain to route the traffic out of the TCR to the Acme data center. The entire flow looks something like this.
Fig. 3: Teridion DNS Routing Flow Diagram
Using DNS features like GeoIP, Regions and sub-regions, Teridion ensures that the app.acme.com traffic is always routed via the most optimum path depending upon specific application requirements.