Rethink your DNS strategy with multi-DNS

DNS is the cornerstone of how the Internet operates.

DNS is a critical backbone of the Internet. It is critical to protect the DNS infrastructure to ensure the reliability of the application and also to ensure that trust of your user base stays intact. With that, it is also important to not just protect the integrity of the DNS service but also ensure that it is highly available and is able to function seamlessly in an event of a DNS attack against your provider or a faulty software code push on the DNS name servers or a botched infrastructure upgrade which might impact the DNS. The underlying message here is that; mistakes happen, things can go wrong and hence it is of paramount importance to plan for contingencies to ensure that your business operations remain uninterrupted.

Let me start by saying that having a DNS provider in the cloud comes with many advantages. You are able to leverage the massive scale that these providers bring to the table, which not just ensures high availability but are also highly performant as it reduces the DNS lookup times by the serving the name resolution from a server that is closer to the end user. With Route53, as an example; you are also able to rely on AWS to provide ‘security of the cloud’ while you remain responsible for the security ‘in the cloud.’ You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.

Having a multi-provider DNS architecture is a must-have to make your architecture more resilient against single-provider failures. A multi-DNS architecture is one where you publish authoritative name servers from two or more DNS providers. I would like to discuss three architecture designs that you may want to consider when you (re)consider your DNS strategy and see what works best for you.

1. Hidden Primary

This is one of the most common setups that I have seen, usually in architectures where your primary DNS resides in your on-premise infrastructure. It is not published as a name server for DNS queries and it is the secondary which is authoritative to the outside world. The secondary will receive the zone files and the updates with a zone transfer and will essentially function like a primary to the outside world. This architecture helps you mask the Origin IP space and achieve security through obscurity. That said, this architecture is not fully resilient if your secondary DNS provider has a compelling event.

2. Primary/Secondary

With this design, the authoritative name servers for the domain would be a mix of DNS servers from both the providers. Both the providers will act as authoritative source of DNS queries for the domain and we would see a random split of traffic between them.

While both the providers will act as authoritative DNS providers, we will have to choose one as primary and the other as secondary. This is an important distinction since the DNS admin will update the records in the primary NS directly, and the secondary will receive those updates by zone transfer.

Such a set-up is easy to manage since there is a single source of truth, but with one important caveat. What happen if the primary provider is down? Some of the DNS providers do allow you to make manual updates to the secondary, but it is not always feasible to do so.

3. Primary/Primary

With this architecture, both the DNS providers not only act as authoritative DNS source for the domain, but are also configured as primary. The set-up is largely similar to #01 and #02 with the major difference being in how the DNS updates are pushed to both the DNS providers. In this scenario, you do not pass zone information from one provider to another. It is the responsibility of the DNS admin to push updates to the zone files of both the providers independently. This could potentially be automated using the APIs of these DNS providers.

This design helps us achieve the redundancy that we were after to serve the DNS queries from two providers independent of each other. That said, there are some design constraints with this approach that you may have to consider.

Considerations when designing a multi-provider DNS architecture-

1. With this set up, you might reduce the capabilities to the common set of the features supported by both the DNS providers and you are likely to use valuable traffic routing and security capabilities.
2. While it is understood that DNSSEC adds that extra layer of security to your DNS lookups by signing the DNS records to protect you from DNS hijacking and phishing, there are limitations on how you can deploy this in a multi-provider set up. Some providers do not support DNSSEC and most of them who do, only support DNSSEC in a Primary/Secondary approach. To be able to support a Primary/Primary DNSSEC mode, you would need to share the same Private Key across multiple DNS providers which is frowned upon by the Security Teams. So, if security is important to you or if you are bound by compliance to support DNSSEC, the Primary/Primary set up isn’t for you.
3. DNS offerings have matured over the years as the DNS providers now offer advanced features such as latency-based routing, geo-routing, weighted-routing etc. These features are implemented using the metadata in the DNS records and the implementation would vary from one provider to another.