If you’ve read some of my previous blogs and want to move ahead with using the Domain Name System (DNS) as an integral element of your DevOps approach, then the selection of an appropriate DNS partner is a key decision. There are many providers out there that offer a wide range of solutions.
Hosting partners or Internet Service Providers will often offer a DNS service as part of their offering. It is important to remember that you do not need to host your DNS with them; while there are advantages to centralizing management in one area, there are also some advantages to maintaining an independent DNS provision. Most importantly is that it gives you freedom to move to different providers in future or to spread systems across multiple providers. However, regardless of the independence of the provider, it is crucial that the provider you choose has the level of expertise in the DNS arena to provide the level of support necessary for a mission-critical platform. For many providers, DNS is an add-on service that is not given the importance it deserves.
It is also essential that when evaluating potential partners or evaluating whether to use your existing cloud provider, the following important capabilities are considered:
- Dynamic Control
Using DNS in the dynamic, often-changing manner that is necessary will require reduction of Time To Live (TTL) values to much lower values (typically less than 30 seconds). This means you are more dependent on your DNS provider, and therefore the performance of your DNS provider becomes even more important.
DNS performance needs to be validated against a number of use cases, as discussed below.
Regardless of your TTL settings, it is important that your DNS provider offer a low-latency network, as all users have to resolve your DNS records before they can access any of your content. However, this becomes more important the more often users are having to re-resolve your records; with a TTL set at below 30 seconds, users will be resolving the DNS multiple times per visit.
If the latency of your DNS is too high, this will block delivery of any content, which would be noticeable to users. As it is the first request, there is no way to code around or hide this delay.
Many sites use domain sharding, that is, serving content from multiple subdomains in order to improve performance. In this case, the overhead of DNS is multiplied as each subdomain will need to be resolved, though well-constructed pages can mitigate this by ensuring DNS requests are executed concurrently or asynchronously.
When evaluating the latency of DNS resolution, remember to consider the latency that all your users experience regardless of location.
If you have a worldwide user base, then ensure that your DNS records are geographically distributed and are being resolved by servers as geographically close as possible.
High capacity and resilience
Decreasing TTL values means that you will be asking your DNS provider to do a lot more resolutions than previously and are relying on that provider to always be available to serve updated details.
Ensure that your provider has sufficient capacity to be able to handle this increased amount of traffic without affecting the speed of resolution.
Also, ensure that the provider has sufficient fault tolerance built into their networks to be able to cope with failure within their systems or networking issues within the wider internet that may make elements of their DNS network unavailable.
Speed of propagation
Remember, when relying on DNS for making dynamic changes, the time taken for updates to take effect is:
Time taken to update + time taken to propagate + TTL
When choosing a DNS provider, make sure that any updates that you make are not only updated quickly, but are also propagated through the rest of the distributed authoritative servers as quickly as possible.
When validating this, ensure that you consider the speed of propagation to all areas where you have a user base.
Any DNS provider you use in this model must offer dynamic control of your DNS records.
Many traditional services only accepted DNS changes via email or telephone requests, with these requests being manually implemented at some point after the request was received. Obviously this is not viable for the sort of reactive change that is needed. Even a web interface allowing direct updates is not suitable.
All changes need to be able to be implemented with no manual intervention.
It is essential that the DNS provider you choose has a comprehensive API that allows changes to be made regularly and instantly without any need for human interaction.
This enables you to integrate DNS management into your automated and scripted deployment and update methodology.