Facebooktwittergoogle_pluspinterestlinkedinmailFacebooktwittergoogle_pluspinterestlinkedinmail

The U.S. recently suffered a massive cyber attack that shut down big-name brands, disrupting e-commerce, email retrieval, remote work and more. The fact that an attack of this scale was possible speaks to the fact that DNS is deployed in a single-threaded fashion for many enterprises. No back-up exists, creating a single point of failure that leaves the organization’s entire online presence at risk.

During the attack, enterprises and their customers watched the internet slow to a crawl – if they could even sign on. This is an example of how the democratization of technology makes everyone equally vulnerable. 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.

What is Redundant DNS?

It’s important to debunk a common misconception before discussing how to mitigate risk with redundant DNS. When people hear the term Secondary DNS, this is often confused with the notion of data center failover or disaster recovery – that the second set of name servers are a back-up of sorts. 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.

There is a set of name servers that the domain owner delegates at their registrar in a traditional DNS set-up:

$ dig example.com ns +short

ns1.primarydnsserver.net.ns2.primarydnsserver.net.ns3.primarydnsserver.net.ns4.primarydnsserver.net.

When a query is made against the domain name example.com, these four addresses are selected at random. 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.

Creating Redundancy

The pool of available name servers is enlarged and spread across two different DNS networks when adding a secondary DNS provider.

$ dig example.com ns +shortns1.primarydnsserver.net.ns2.primarydnsserver.net.ns3.primarydnsserver.net.ns4.primarydnsserver.net.ns1.secondaryforthewin.com.ns2.secondaryforthewin.com.ns3.secondaryforthewin.com.ns4.secondaryforthewin.com.

The risk of an attack causing a customer-impacting outage is reduced when there are eight available servers in the delegation across two separate DNS networks. 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, what is crucial is that the end user will still be able to get to where they intended to go.

It’s not as daunting as it may seem to add a redundant DNS service to your existing primary. 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.

Make sure that your primary DNS provider allows zone transfers (AXFR) before you begin – it’s absolutely critical. 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.

As the graphic demonstrates, a 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.

Steering the Traffic

Though how AXFR is designed is well suited to the needs of basic DNS record types, just about every managed DNS provider out there has built its 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 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.

Relief for Duality

A respite is possible in operating two separate DNS networks by leveraging an API on both sides to manipulate the advanced features. 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.

Lowering Risk

The internet has changed dramatically in scope and infrastructure since DNS was created. To avoid the dreaded “Server Not Found” dilemma today’s enterprises need to build redundancy into their DNS – two providers that offer the same feature sets and functions. API interoperability is a must as well. Using a managed DNS service lets enterprise focus on their mandate and leave the detail work to experts, providing extras like advanced traffic routing features that benefit end users with reduced latency. A redundant DNS system protects against DNS failure and loss of revenue, productivity and reputation.

About the author:

carl-j-levineCarl J. Levine is the Senior Technical Evangelist for NS1. He is a marketer, technologist, and startup enthusiast all rolled up into one dynamic team leader. Levine has over a decade of experience with startups, networking protocols and Internet infrastructure, combined with the unique ability to iterate use cases, bring understanding to those seeking to explore complicated technical concepts and increase revenue across diverse sales channels. He is an advocate for world-class customer experience and an active participant in New Hampshire High Tech Council’s Entrepreneur Forum.

Facebooktwittergoogle_pluspinterestlinkedinmailFacebooktwittergoogle_pluspinterestlinkedinmail
Subscribe To Our Newsletter Today and Receive the Latest Content From Our Team!

Subscribe To Our Newsletter Today and Receive the Latest Content From Our Team!

You have Successfully Subscribed!