Skip to main content Skip to search
Carl Levine
Posted by
Carl Levine on
October 24, 2016

Highlighting The Need For Redundancy

For many enterprises, DNS is deployed in a single-threaded fashion. There is no back up and if something goes wrong, it represents a single point of failure, often for the company’s entire digital estate. Given the state of the Internet, it’s becoming more common for enterprises to deploy redundant DNS to mitigate these risks as much as possible.

A Primer On Redundancy

Before I jump in on how to mitigate risk with redundant DNS, I want to debunk a common misconception. When people hear the term Secondary DNS, this is often confused with the notion of data center failover or disaster recovery. Secondary DNS is neither of these, but rather a means of ensuring end users aren’t left with that dreaded “Server Not Found” message, which occurs when their request for a DNS lookup is not answered.

In a traditional DNS setup, there are a set of name servers that the domain owner delegates at their registrar.

$ dig ns +short

These four addresses are selected at random when a query is made against the domain name While there is often a good deal of redundancy built into such setups, they can be vulnerable to targeted attacks. If all four of these servers in the delegation are under duress, visitors will have a very hard time getting a DNS response, and may not get one at all. Recent attacks have demonstrated this reality.

Redundant DNS – How Does It Work?

When adding a secondary DNS provider, the pool of available name servers is enlarged and spread across two different DNS networks.  

$ dig ns +short

With eight available servers in the delegation across two separate DNS networks, the risk of an attack causing a customer-impacting outage is reduced. If one network becomes overly latent, resolvers will try another server. While this process of timing out and retrying another option during an attack does add latency to a DNS transaction, crucially the end user will still be able to get to where they intended to go.

Adding a redundant DNS service to your existing primary is not as daunting as it may seem. Some of the largest enterprises in the world hedge their bets with this strategy, ensuring that their presence is secured across multiple providers. This is not unlike the recent trend towards diversifying an enterprise’s CDN or cloud footprint, which has been gaining traction throughout the industry.

Before you begin, it’s absolutely critical that your primary DNS provider allows zone transfers (AXFR). If this is not the case, you would be stuck having to manually push changes to your zones to both providers, which is a rather inconvenient and unfortunate way to go about achieving replication.

Working from left to right on this diagram, the user pushes a DNS change to their primary DNS provider. When this change is enacted in the primary DNS, the zone’s serial number increments. This means that the secondary zone file at the other provider is now behind the times and needs to be updated. An optional NOTIFY can be sent to the secondary, letting that system know that a new zone file is ready to be transferred in at specific polling intervals. The process of zone transfer, or AXFR, is initiated and the updated zone file is replicated in the secondary.

What About Advanced DNS Functionality?

While the design of AXFR suits the needs of basic DNS record types, just about every Managed DNS provider out there (NS1 included) has built their own way of leveraging DNS to do advanced traffic steering on top of the protocol. This advanced functionality extends beyond what’s covered in the the DNS RFCs and as a result, more advanced features and record types can’t be synchronized across providers using AXFR. Running dual primary servers solves this by allowing the DNS administrator to push changes to both providers, while leveraging each platform’s advanced feature functionality, albeit largely in a manual fashion. Where both primary servers are included in the delegation, traffic is split across both primaries.

Integrated Dual Primary Redundancy + Automation

This is where leveraging an API on both sides to manipulate the advanced features can provide a bit of relief in operating two separate DNS networks. Simple middleware can be written to translate intended changes to work across both networks, however, the intricacies and breadth of a specific vendor’s advanced features may result in inconsistent application performance from one to the other, and you’re stuck using the lowest common denominator in terms of the functionality each platform offers. If you’re used to using NS1’s Filter Chain, this means giving up useful and sometimes critical features like ASN and IP Prefix Fencing, Sticky Shuffle, and Pulsar.

Leveraging Tomorrow’s Application Delivery For Redundancy

In an ideal world you want two cutting edge DNS providers who can offer the exact same features and functionality along with complete API interoperability. NS1’s Dedicated DNS solution offers exactly this: the ability to leverage all of NS1’s technology including the Filter Chain™ and Pulsar across two logically and physically separate delivery providers. Instead of relying on another name server technology or provider to serve as secondary, Dedicated DNS allows for a separate DNS network to be deployed on your own infrastructure or in a hosted, anycasted environment that’s powered by the same core software that runs our Managed DNS network, and talks to the same API and UI. Everything is automatically kept in sync, and the solution is single tenant: the resources of the Dedicated DNS network are fully dedicated to you and you alone - two separate, yet completely integrated networks to serve your queries.

Stay tuned to NS1’s social media feeds for more information about an upcoming webinar on leveraging Dual Redundant DNS. As always, we are happy to talk shop about helping your company leverage a solution that keeps your online properties safe and reliable for your users.