What is DNSSEC and Should You Use It?

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…  

What is 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.   

Understanding the problem DNS solves 

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:

1. You type example.com in your web browser. 
2. If an entry for example.com isn’t cached, your DNS resolver goes out and queries name servers on the Internet to find out example.com’s IP address.  
3. Your resolver gets back a response that 203.0.113.11 is example.com’s IP address. 
4. Your resolver tells your PC example.com is at 203.0.113.11. 
5. A webpage from the server at 203.0.113.11 loads in your web browser. 

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.  

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.   

Problems DNSSEC Does NOT Solve 

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). 

How Does DNSSEC Work? 

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.  

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.  

The DNSSEC DNS Record Types 

To facilitate the authentication and validation of DNS responses, DNSSEC uses several resource records (RRs). They are:  

• RRSIG– Resource record digital signature (RRSIG) records include a cryptographic signature and data such as the type of DNS records the signature applies to, cryptographic algorithms used, TTL values, and issue/expiration dates. An RRSIG can be validated using a DNSKEY. 
• DNSKEY– The DNSKEY is the public key that can be used to validate an RRSIG.  
• DS– A Delegation Signer (DS) record is used to transfer trust from a parent zone to a child zone. It contains a hashed DNSKEY and points to the next key in the DNSSEC chain of trust. 
• NSEC and NSEC3– Next secure (NSEC) records and next secure version 3 (NSEC3) records are DNSSEC’s way of proving a record does NOT exist.  
• CDS and CDNSKEY Child DS (CDS) Child DNSKEY (CDNSKEY) records are published by child zones to allow parent zones to update their records. Generally, these RRs are used for enabling/disabling DNSSEC or rolling over key-signing keys (KSKs).  

How Can You Implement DNSSEC? 

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.  

DNSSEC vs DANE vs DoT vs DoH 

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. 

• DANE- DNS-based Authentication of Named Entities (DANE) allows administrators to specify what certificate authorities (CAs) can create certificates for a domain. For DANE to work, DNSSEC must be enabled. 
• DoT- DNS over TLS (DoT) encrypts DNS traffic using Transport Layer Security (TLS) encryption. DoT is a method for solving the DNS privacy problem that DNSSEC does not.  
• DoH– DNS over HTTPS (DoH) aims to solve the same general problem DoT does, but goes about it differently. Like DoT, it can be viewed as complementary to DNSSEC. 

What are the Arguments for 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: 

• DNSSEC greatly reduces the threat of MITM-style attacks. 
• DNSSEC can enable functions like DANE that can further enhance security. 
• DNSSEC isn’t prohibitively difficult to implement and is backwards compatible with DNS. 

What are the Arguments Against DNSSEC? 

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.  

Final Thoughts: Should You Use DNSSEC or Not?  

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.