Internet Performance Delivered right to your inbox

Is DNSSEC Adoption Worth it for Enterprises?

There’s a lot of hype around DNSSEC adoption, but is it necessary?

Years ago, when I was a young engineering student, I worked at a defense contractor working on intelligent munition systems. A few years before I started, there was a program that detected enemy targets and fired a warhead into them. It started with targeting enemy tanks, then morphed into an anti-helicopter platform before fizzling out.

I remember a tech speaking about the end of that program, when the project lost funding. Apparently the kit worked a dream. It was a robust platform that could track a helicopter in the sky and fired its payload with pinpoint accuracy. Still, it got the axe.

As the tech told it, the project went into a review with a bunch of generals to assess progress and recommend additional funding. Defensive projects that could help keep military bases safe were in high demand at the time, and we had expected to clear the audit. It came as a shock when the chairman’s recommendation was delivered, I cannot justify a project protecting the skies from helicopters, when I do not at this time have a problem with enemy helicopters.

As a young engineering student, I soaked this lesson in. It was possible to perform a task with complete efficiency and still fail to provide value. It is with this thought that I approach the topic of DNS Security Extensions (DNSSEC).

I am going on eight years working with Dyn, in which time I have personally worked with hundreds or maybe thousands of companies. I have worked with e-commerce websites, banks, politicians running for office, social media platforms, infrastructure providers, and more.

In this time, I have been asked many questions and heard many concerns — but something has recently started to strike me in its silence. I’ve never had someone actually complain of a DNS-based man-in-the-middle attack. Sure, I saw one once, from afar, in the BGP hijacking of Amazon’s Route 53 some months ago to rob a cryptocurrency bank. But that was so rare.

DNSSEC adoption is important for enterprises to think about, but it seems your chances of needing it are about the same as winning the lottery. Where are all the helicopters?

DNSSEC adoption: Necessity and complexity

Are DNS-based man-in-the-middle attacks some underreported and under-detected phenomena? Could be, but with the rate and intensity with which the Amazon hijack was shared in the tech community, if this was an even slightly regular problem, every risk-obsessed corporate security training would be explaining the need for DNSSEC validating stub resolvers. But they’re not. Where are all the helicopters?

DNSSEC adoption is never described as easy. Sure, there are mechanisms to offer it from most modern DNS vendors and through common code bases such as BIND. If you’re looking to do DNS like it’s 1995, you’re fine. But throw in some traffic steering and multi-vendor redundancy? That’ll complicate things significantly.

Not all vendors can sign on the fly, and you will have to cross sign DNSKEYs to ensure you don’t invalidate request answers signed by the second vendor. The running joke among many network operations center workers is that more websites go offline from misconfigured DNSSEC than from the attacks DNSSEC protects against. I’m inclined to believe them.

Effects on traffic and budget

While DNSSEC adoption decreases your risk of a hijack, it also increases other metrics that your business has a more tangible grasp on. For one, there is about a 300 ms delay when a recursive performs an initial validation. This will be cached, sure, but some poor soul will get stuck with the wait. For every recursive, every day.

You may also see an increase in traffic. This makes sense, given you now have more records to serve. More requests for new records that wouldn’t otherwise exist means more traffic overall. Using recommended signature lengths, you’re looking at a potential 4X increase in queries and 8X increase in traffic, according to some of the research at APNIC. This is not an enormous increase, yet it’s enough to make changes to package considerations with some DNS vendors.

This could mean an increase in cost, which is easy to justify when you are able to point to a clear and present threat. But where are all the helicopters?

How effective is DNSSEC adoption?

Sure, DNSSEC will ensure cyber-crooks have to jump impossible barriers to crack the code. But is the recursive that receives this answer checking? The statistics seem grim there, looking at about 14% of the recursive population — a number largely propped up by the respectable work of Google DNS and nations forwarding their entire recursive DNS operations to it.

What about if the hijack is between the user and the recursive? Are we all running DNSSEC validating stub resolvers on our local machines? Not likely. Ironically, this might be an even bigger issue than DNSSEC in authoritative DNS itself. That’s the stuff people are just starting to work on in earnest now. It is likely that this might be solved with DNS over TLS rather than a DNSSEC validating stub anyway.

As is often the case, it is easier to lobby to use mechanisms more commonly implemented in a new application, however flawed, than a perfect solution only understood by a small group of niche actors.

This all tends to ignore the defense-in-depth practices that cybersecurity has come to preach. If someone does impersonate your domain, surely you should have traffic encrypted with HTTPS and an extended validation SSL certificate, right? With any modern browser, there will be a big red warning that this is not valid. Could the attacker get a dodgy certificate authority (CA) for a domain-validated cert? Yes, there is increased pressure from browser providers, but things like Google’s Certificate Transparency project increased use of certificate authority authorization (CAA) records by the CAs, including the mandated support by their own industry forum. It’s also a good idea to utilize key pinning to lock users for a regularly used domain to a safe key.

Who is DNSSEC for?

All of this might make me seem negative about the value of DNSSEC adoption and defeatist toward its challenges. I don’t mean to be. What I do wish to illustrate is that DNSSEC isn’t free for an enterprise and should be assessed like any other design component, even if it is offered for free by your DNS vendor or platform. DNSSEC adoption reduces certain types of risk and creates complications for others.

The biggest issue from a design standpoint is that performing DNSSEC on zones that use advanced DNS features such as traffic steering and DNS-based failover is challenging at scale. This is because you either need to have multiple signed copies kept at the ready (the precompile method), or you need to dynamically sign the zone at each variation of the zone often at the edge (sign on the fly).

Neither is impossible, just challenging. Even if you are using a rare provider that does perform this function today, it will be difficult to repeat it for a second vendor, cross-sign the signatures, and have these in sync for diversity. Do you have a wide vendor selection? Not by a long shot. This is something the DNS community is starting to address, but it is still very much a working draft, not a standard nor adopted widely.

This leads to the biggest trade-off I can see in DNS. If you decide to sign your zone, you will limit  your options for traffic steering in DNS and/or your vendor selection. If you decide to use traffic steering, you will limit your ability to sign your zone (completely, anyway; you could split out for partial signing with management zone) and/or limit your options of vendors and vendor redundancy.

DNSSEC pros and cons

So who should sign their zone? Anyone that works in an industry that is legally mandated to use DNSSEC doesn’t have an option, such as those in government. But for the organizations that have a choice, it should really be assessed what the highest risk is, and what the impact of that risk will be.

If you are operating in a situation with a single data center and don’t see that changing in the future, or are using anycast IPs for data center failover such that you don’t need DNS-based traffic steering, then go ahead with DNSSEC adoption. The primary will sign the zone, and the secondary DNS provider will receive the records just like any other. There’s really nothing crazy here.

Don’t have two DNS providers yet? You really should think seriously about that. It won’t even be terribly hard with this configuration.

Top-level domains (TLDs) are also obvious places for DNSSEC to exist, and it is great to see so many being signed. I could even see a scenario in the future with cyberattacks impersonating TLDs of an enemy nation to gain or deny access to systems. Because there is no real need for traffic steering with TLD zones, it is easy to operate DNSSEC across many vendors in secondary relationships. Oracle Dyn supports this, and we would love to chat more about it at ICANN 63 in Barcelona if any of you are in attendance.

If you are operating with traffic steering, then I this is probably more critical to your daily availability operation than DNSSEC will be. It is worth the challenges to have a fully redundant solution. Adding DNSSEC to this mix? At this time, there are only a few providers that could tackle something like this. And that means you will not have a choice as to their terms. My sysadmin hat says this is great, but my CIO hat has fears.

It also must depend on the visibility and specific risk of your particular organization. Financial and political orgs are more likely to be the target of an attack generally, so that could contribute to the relative frequency of an attempted hijack. On the other hand, attackers could also attempt to DDoS your DNS or your own systems, so we’re right back where we started. If DNSSEC prevents you from adding diversity, you are likely opening yourself up to more frequent and impactful risks, which should be weighed against enablement.

Finally, if you are deploying DNSSEC, multi-DNS, and traffic steering, my hat is off to you. Someone has to be the early adopter, and it’s not to say that the risks out there don’t exist or won’t increase in frequency in the future. You are what pushes the whole industry and market forward. It can’t it be easy, and it’s likely very lonely at the top. If nobody has said it lately, you are appreciated.

Share Now

Matt Torrisi
Whois: Matt Torrisi

Matt Torrisi is a Senior Solutions Engineer at Oracle Dyn Global Business Unit, a pioneer in managed DNS and a leader in cloud-based infrastructure that connects users with digital content and experiences across a global internet.

To current Dyn Customers and visitors considering our Dynamic DNS product: Oracle acquired Dyn and its subsidiaries in November 2016. After June 29th, 2020, visitors to will be redirected here where you can still access your current Dyn service and purchase or start a trial of Dynamic DNS. Support for your service will continue to be available at its current site here. Sincerely, Oracle Dyn