What is DNSSEC and Should You Use It? – Blog

The “phonebook” of the Internet (DNS) isn’t secure. But there is a solution (DNSSEC) that adds security to it, has been around for years, and is available on over 90% of ICANN’s top-level domains (TLDs).
Given the importance of DNS and security, you’d expect adoption of DNSSEC to be overwhelming, right? Well, it hasn’t been. In 2021, DNSSEC validation remains under 50% globally. There are even people who argue against DNSSEC.
So, should you be using DNSSEC? Well… like most things in tech, it depends. To help make an informed decision, here I’ll cover what DNSSEC is, how it works, and the case for and against it.
You’ll get the most out of this article if you’re already comfortable with the basics of Domain Name System (DNS). If you’re not, check out All You Need to Know About DNS first then head back here. If you’re already up to speed with DNS, let’s jump into DNSSEC…
DNSSEC is a set of extensions that add security to DNS in a backwards compatible way.
As the “phonebook of the Internet” DNS is a fundamental part of how the Internet works. It’s also an older protocol that wasn’t designed with much security. As a result, there are plenty of ways DNS can be compromised.
To address some of the security challenges with DNS, engineers from the Internet Engineering Task Force (IETF) created DNSSEC. With DNSSEC, cryptographic signatures are used to validate the authenticity and integrity of DNS records.
To understand why those cryptographically signed DNS responses DNSSEC provides matter, let’s walk through how things work without it.
Suppose you want to access a website (example.com) from your PC. Normally, that process works something like this:
In most cases, that all works great. But, what if an attacker compromises one of the name servers or poisons your DNS cache? With traditional DNS alone, you wouldn’t know. Instead of the legitimate website you wanted, you are directed to the attacker’s server.
What is DNSSEC? There are a variety of different types of and names for these attacks (e.g. DNS spoofing, DNS cache poisoning, Kaminsky attack, and DNS hijacking), but they all exploit the fact there is no way to verify DNS responses are legitimate.
So, how does DNSSEC help? With DNSSEC, the resolver will use cryptographic signatures to validate the response instead of “blindly” trusting it. If the validation fails — as it would in our example — the user isn’t sent to the malicious site.

Before we move on, it’s important to call out what DNSSEC does NOT do. In the example above, we see that DNSSEC validates the authenticity and integrity of DNS responses. That’s important because it prevents man-in-the-middle (MITM) attacks.
However, it does NOT add any privacy. DNS traffic is not encrypted and DNSSEC does NOT add encryption to it. If you’re looking to solve the problem of encrypting DNS traffic DNSSEC alone won’t help (don’t worry, we’ll take a look at some DNS privacy protocols below).
Ok, so we know DNSSEC is supposed to solve problems like DNS spoofing by validating signatures… but how does that work? To understand that, we need to understand DNS zones and DNSSEC’s chain of trust.
Going back to DNS basics, we know everything traces back to the root domain. Then, we have TLDs such as .com, .net, and .org. Underneath the TLDs, we have domains like example.com or mediatemple.net. Each of these distinct namespaces is a DNS zone.
How Does DNSSEC Work?
Just as each of those zones publishes DNS data that help with lookups, they can publish DNSSEC data that is cryptographically signed using public/private key pairs. DNS resolvers that support DNSSEC can then use the data to validate DNS requests.
But, how do we know that the data can be trusted? By checking with the higher-level “parent” zone. With DNSSEC, a parent zone cryptographically vouches for its “child” zones.
For example, to validate example.com’s records, we look at the corresponding data in the .com zone. Then, to validate .com’s records, we look at the corresponding data in the root zone.
But now that we’re at the root zone, how do we validate its records? Well, we assume we can trust the root zone. The root zone is overseen by the Internet Corporation for Assigned Names and Numbers (ICANN) and its keys are signed in a verifiable way during special publicly broadcasted ceremonies. Given the precautions and processes around the root key signing, “everyone” assumes they can trust those keys.
Building out from that trusted signature, all the child zones can be trusted. As a result, we now have a chain of trust where a resolver that supports DNSSEC can validate the IP address records it receives are legitimate.
To facilitate the authentication and validation of DNS responses, DNSSEC uses several resource records (RRs). They are:
On the client-side, to use DNSSEC for name resolution, you need a resolver that supports it. There are plenty of DNS resolvers today that do, so this isn’t too difficult.
If you want your domain to support DNSSEC, the specific process will vary depending on your registrar and DNS hosting provider. Your registrar will need to support DS records and get yours signed by your TLD. Your DNS hosting provider will need to sign and publish your DNSKEY record.
If you’re researching DNS security, there’s a good chance you have come across terms like DANE, DoT, and DoH. While all these items are related to DNS security, they aren’t all the same. Here’s a quick overview of each and how they relate to DNSSEC.
There are plenty of smart people and organizations that pride themselves on security making arguments for DNSSEC. For example, CloudFlare has been a big proponent of DNSSEC for years.
Given what DNSSEC does, it’s pretty easy to understand the arguments for it. They boil down to:
Despite the benefits and smart people arguing in favor of it, DNSSEC is far from the norm. It may even be losing steam. For example, the US Government once mandated DNSSEC for .gov sites (in memo M-08-23), but they have since rescinded that mandate.
There are nuanced technical arguments against DNSSEC, but I won’t go too far down that rabbit hole here. Instead, let’s look at one of the more practical arguments against it. That is: even if you assume DNSSEC does what it says, the complexity isn’t worth it.
The DNSSEC validation process adds more points of failure and complexity to DNS. As a result, it’s not unheard of for a site to be unavailable due to a DNSSEC issue. For example, an expired DNSSEC key caused issues with Spiceworks and a number of other sites that use Imperva/Incapsula earlier this year. Given the risk of bringing down your site with a misconfiguration, some feel DNSSEC isn’t worth the effort. Additionally, there is some (although often negligible) performance impact with DNSSEC.
The answer to this question comes down to your risk tolerance and how well you can manage DNSSEC. If you can deploy and manage it without too many problems (which is the case for many), it’s worth it. If you don’t value the additional security enough to justify the increased complexity, it’s not.
For the past 24 years, Media Temple dedicated itself to serving the needs of the digital creative community.
Today’s internet represents a huge, enormous network, literally connecting billions of various computers, servers, phones, and even teapots into a single system.
According to statistics from DataProt, about 122.3 billion email spam messages are sent daily.
In the simplest terms, a domain name is your web address, but you can also think of it as the main entrance to your online space.