In a recent blog post, “What is Multi-CDN?”, we discussed why an organization would be interested in a multi-CDN strategy and the benefits and downsides of doing so.

While some CDN providers do offer integrations with others for multi-CDN scenarios, using a separate, independent, and neutral DNS provider makes a lot of sense in terms of control, reliability, and performance.

CDN providers typically provide regional DNS CNAMEs for the efficient routing of traffic, and combining these with Directional DNS services provides a powerful way of steering requests and content.

In this article, we will demonstrate an example of a UltraDNS multi-CDN configuration, where content from 2 (commonly 3 or more are used) CDN providers can be controlled at the DNS query/answer level.

Multi-CDN scope and considerations.

In this example, a Vercara UltraDNS customer has chosen 2 global CDN providers and wants to serve resources from both simultaneously. However, if one CDN provider fails in a region, UltraDNS will only provide answers from the one still in service until normal service resumes.

The following section goes into detail about the considerations and configuration needed on UltraDNS to achieve a multi-CDN topology at the DNS level using advanced services.

Some organizations delivering global content to customers will want to use DNS to control the steering of traffic to the most appropriate regional resources using multiple CDN providers. This can be achieved with UltraDNS Advanced Services such as Directional DNS and Traffic Controller. This document describes how to do this based on the following example:

For our example configuration, the world is divided into 5 regions, each serviced by dual CDN providers. In this case, we call them “cdnx.net” and “cdny.com”. The CDN FQDN names are for illustrative purposes only; real-world ones can be easily substituted, and the “world” can be divided up into different regions as required. The domain being resolved is “example.biz” and UltraDNS is authoritative for it as a Second Level Domain (SLD) provider.

For the configuration outlined in the diagram, 5x Directional DNS records and 10x Traffic Controller records would be needed. This could be doubled if the customer also runs a pre-production environment. Reading the diagram from left to right, the following takes place:

1. Global client queries – A client makes a query for, e.g., “www.example.biz,” and if noncached, the query will be forwarded from the Internet DNS root servers to UltraDNS for processing.
2. Directional DNS regions – The query will be inspected for its source IP to see which region of the world the request came from and forwarded to the appropriate Traffic Controller CDN pool.
3. Traffic Controller CDN pools – Based on the configuration of the Traffic Controller pool (load balancing and monitoring) and status of the CDN resources specified, UltraDNS will return the optimal answer to the client.

The configuration can be achieved for the required domain as follows:

1. Create the Traffic Controller (TC) pairs.
2. Create the Directional DNS (DD) regions.
3. Point the desired resource record (RR) to the DD configuration (A, AAAA, Apex, etc.).

In the UltraDNS portal, we will create a dummy domain called “example.biz” and build the multi-region and multi-CDN configuration from there.

Step 1: Create the Traffic Controller (TC) pairs.

1. Select “Add Pool” in the “A Records” section:
2. Choose a CNAME Record Type with TC Pool Type and enter the details for the first region, “North America”: Note: Notice the first CDN is being added here with the name “example-biz-r1.cdnx.net”. The “r1” emphasized denotes “Region 1” The second CDN for “Region 1” will be added next.

3. Once step 2 is saved, the first TC region “North America” configuration can be continued:
4. Select “Add Record” and enter the details for the second CDN: Note: Notice the second CDN is being added here with the name “example-biz-r1.cdny.com”. The “r1” emphasized again denotes “Region 1”.

5. Save and repeat step 4 above, this time choosing the “All Fail” checkbox:
   Note: For the “All Fail” record, the example domain used is “oob.backsoon.net”. This is a free TC record and should point to a real destination that notifies users in the event of both CDNs becoming unavailable. For that reason, the page should not be hosted on either of the CDNs but with an alternative provider.

6. The “Records List” in the configuration should now look as follows:  Note: Weight and Priority can be used here to control how the resources respond to queries, but in this example, the CDNs are active/active with equal priority.

Step 2: Setup probes for the Traffic Controller (TC) pairs.

7. Next, select “Probe Definitions” and “Add Probe”:  Choose a Probe Type (HTTP selected in this example), at least 2 Probing Regions, and a Probe Interval.Now click Add to define the HTTP Probe specifics:In this example, the probe will be configured to poll the Vercara website using HTTP version 1.1. and the GET method to look for some text on a page. In this case, “Together with our partners” from the Vercara website Partners page.
   Scroll further down the Edit Probe page and enter “Together with our partners” (without the quotes) into the Search String boxes:
8. Note: These settings are for demonstration purposes only. Probing with HTTP should be configured to reflect the actual real-world assets. HTTP is recommended for webservers for obvious reasons, i.e., the port will be open and available for HTTP requests, whereas ICMP (PING) may not be.Configured in this way, if the probes cannot find the specified search string, there is likely to be some sort of error or outage, an alert will be generated, and the resource will not be returned to client DNS queries until service resumes.Also, combining with “Run Time” and “Connect Time” values it is possible to determine potential performance or network issues that may indicate a need not to provide DNS answers from this resource until values return to within the specified parameters.In the portal, a failed resource in any configured pool is highlighted with a critical status icon:A full list of “Probe Types” and how they can be used is as follows:

• • HTTP – The HTTP probe verifies an HTTP service by making a request to a web server and checking the response codes received. It can also be used to search for a string or regular expression on a web page. The HTTP probe can also follow a redirect if required.
  • PING – The PING probe verifies the target server IP address is available using ICMP. Packet loss and round-trip time values can be specified to determine if the resource should be considered available or not.
  • FTP – The FTP probe can be used to make a connection to an FTP server and path with suitable credentials. Connect time, run time and search strings can all be used to determine if the server should be considered available.
  • TCP – The TCP probe can be used to connect to the specific IP address and port of a server, with connect time values being used as a gauge of availability.
  • SMTP Availability – The SMTP probe uses port 25 (or other) availability to determine if the service is available using connect time values as a gauge of availability.
  • SMTP Send Mail – The SMTP Send Mail probe will send a test email using “Mail From”, “Mail To” and “Message” values while measuring connect and run time values as a gauge of availability.
  • DNS – The DNS probe will query for a specified resource record and compare run time and response values to gauge availability.

Note: Multiple probe types can be configured for the same resource or pool of resources. For example, it is possible to ping a server and look for a string of text on its web page at the same time if required.

“Scheduled Events” can be configured to allow for host maintenance etc. and “Notifications” can be configured to send email notifications when a configured event is triggered such a resource becoming unavailable for some reason.

8. Repeat steps 1 to 7 for each of the remaining 4 regions – South America, Oceania, Asia and Europe. Name the TC Pools and TC CDN Records as follows:

“southamerica”, “example-biz-r2.cdnx.net”, “example-biz-r2.cdny.com”

“oceania”, “example-biz-r3.cdnx.net”, “example-biz-r3.cdny.com”

“asia”, “example-biz-r4.cdnx.net”, “example-biz-r4.cdny.com”

“europe”, “example-biz-r5.cdnx.net”, “example-biz-r5.cdny.com”

Note: The 8 Ultra probe regions may not fit neatly with defined regions, so the best fit must be used, and most importantly, use at least 2 probes (up to a maximum of 4 from a total of 8) per region. This allows for any issues with the probing network itself. The 8 regions available from the probe network are as follows:

• • North America East (New York, Washington D.C., Atlanta, Miami, Toronto)
  • North America West (Seattle, San Jose, Los Angeles, Phoenix, Vancouver)
  • North America Central (Chicago, Denver, Dallas)
  • Europe East (Amsterdam, Frankfurt, London, Paris)
  • Europe West (Dublin, Madrid, Stockholm)
  • South America (Sao Paulo, Columbia, Miami)
  • Asia (Tokyo, Taipei, Singapore, Hong Kong, Sydney)
  • China (Beijing, Hong Kong) Note: Reliable results only within China.

9. Once all the TC pairs are configured, the resulting Pools in the “A Records” section should look as follows:

Note: Consider reducing the TTL if a faster failover is required.

Step 3: Setup regions to steer DNS client queries.

10. The next step is to create a Directional DNS (DD) pool and point it to the regional Traffic Controller (TC) pools previously created.Select “Add Pool” in the “A Records” section, and this time, choose the “Directional (DIR)” Pool Type:
    Note: The hostname in this example is “www,” but it can be any host required. It points to “northamerica.example.biz,” but any of the previously created TC pairs could be chosen first. This will allow the DD pool to be created and assign the “All Non-Configured” group to the TC pair “northamerica.example.biz”.Doing this means that once the world has been divided and grouped as required, any regions not already selected will remain in the “All Non-Configured” group to ensure that queries are still served by one of the TC pairs.It’s also possible for a “No Response” Directional Pool Record to be created for any areas of the world where providing DNS query answers is not required.

11. Once Step 10 is saved, the Directional Pool configuration can continue and should look as follows:
12. Click Add, then choose “Record Type” CNAME and enter “southamerica.example.biz”:
13. Click “Add Group,” and in the next dialogue box, enter “south america” for “Group Name” and select “South America” from the “Available Regions” drop-down list. Use the pink arrow to move the region from the left into the “Selected Regions” area on the right: Note: Multiple region choices can be selected and it is also possible to drill down geographically into Countries, States and Provinces depending on the granularity required.

14. Repeat steps 12 and 13 for the remaining regions “oceania”, “asia” and “europe”. The Pool Records section should now look as follows: Note: Every other unselected region, including North America, will now point to the “northamerica.example.biz” TC Pool.Also, the “Ignore ECS” checkbox should be ticked to prevent location information received from client queries conflicting with the Directional DNS configuration. Some privacy implications also exist with use of ECS, so its use in general should be fully understood.

15. Click “Save Changes’ to commit the Directional Pool configuration.
16. Return to the domain “A Records” section:

Step 4: Test the configuration.

17. To test this, based on the configuration, if a query is made from a client in Europe, a load-balanced answer from a Region 5 (r5) resource should be returned:Or, in this example:
    And so on for each region as configured, with the WAN IP source location of the test query determining the response. A VPN could be used to test from different regions if required, or other useful tools such as GlobalPing, where you can test from multiple sources around the world simultaneously by simply adding the IP address of a nameserver from your UltraDNS account.In this example, we are using the IP address belonging to nameserver “edns1.ultradns.com” to resolve “www.example.biz” from 30 nodes around the globe. Results can be used to validate the configuration or help to tune as needed.For more information on UltraDNS, visit our resources page.