Tracking Multi-CDN Performance Issues to DNS

a multi-cdn service that combines multiple cdn providers into a single network is a common and effective way to speed up your web applications for users anywhere in the world. this strategy can also boost failover support in case one of the cdns you’re using goes down.

but even a multi-cdn service is not immune from performance issues. intermittent performance drops can and do happen even with this architecture. the likely culprit is a familiar but often ignored one—dns.

first, let’s break down what typically happens in a multi-cdn setup:

• when we access any domain (ex: tiqcdn.com), the browser checks its local cache for the dns records.
• if it does not have the information, a query is typically sent to the isp’s dns
• which in turn reaches out to the root server if the information is not already in the cache.
• typically, the root server would redirect the request to a gtld server (.com in this case) if the info is not cached or if it has expired (depends on the ttl) and the gtld server would return the name server info of the queried domain as shown below:

now let’s take a look at scenario 2 where the multi-cdn provider is redirecting the request to a different cdn – highwinds

the dns resolver again has to go through the process of resolving this host. however, in this case we noticed that the name servers of highwinds failed to respond:

at catchpoint, we have the option of failing a test at this point when all the available name servers fail to respond. in the real world, reattempts are made to the server if it fails the first time, so the users may not see a failure, but the performance will be hit badly.

to summarize, a multi-cdn service can make your web applications faster and more reliable but is still not failsafe. monitoring your application alone is simply not enough; dns monitoring remains crucial.