#main-nav-header { display:none; }

How DNSSEC Works

The domain name system (DNS) is the phone book of the Internet: it tells computers where to send and retrieve information. Unfortunately, it also accepts any address given to it, no questions asked.

Email servers use DNS to route their messages, which means they’re vulnerable to security issues in the DNS infrastructure. In September 2014 researchers at CMU found email supposed to be sent through Yahoo!, Hotmail, and Gmail servers routing instead through rogue mail servers. Attackers were exploiting a decades-old vulnerability in the Domain Name System (DNS)—it doesn’t check for credentials before accepting an answer.

The solution is a protocol called DNSSEC; it adds a layer of trust on top of DNS by providing authentication. When a DNS resolver is looking for blog.cloudflare.com, the .com name servers help the resolver verify the records returned for cloudflare, and cloudflare helps verify the records returned for blog. The root DNS name servers help verify .com, and information published by the root is vetted by a thorough security procedure, including the Root Signing Ceremony.

Delegation Signer Records

DNSSEC introduces a delegation signer (DS) record to allow the transfer of trust from a parent zone to a child zone. A zone operator hashes the DNSKEY record containing the public KSK and gives it to the parent zone to publish as a DS record.

Every time a resolver is referred to a child zone, the parent zone also provides a DS record. This DS record is how resolvers know that the child zone is DNSSEC-enabled. To check the validity of the child zone’s public KSK, the resolver hashes it and compares it to the DS record from the parent. If they match, the resolver can assume that the public KSK hasn’t been tampered with, which means it can trust all of the records in the child zone. This is how a chain of trust is established in DNSSEC.

Note that any change in the KSK also requires a change in the parent zone’s DS record. Changing the DS record is a multi-step process that can end up breaking the zone if it’s performed incorrectly. First, the parent needs to add the new DS record, then they need to wait until the TTL for the original DS record to expire before removing it. This is why it’s much easier to swap out zone-signing keys than key-signing keys.

Explicit Denial of Existence

If you ask DNS for the IP address of a domain that doesn’t exist, it returns an empty answer—there’s no way to explicitly say, “sorry, the zone you requested doesn’t exist.” This is a problem if you want to authenticate the response, since there’s no message to sign. DNSSEC fixes this by adding the NSEC and NSEC3 record types. They both allow for an authenticated denial of existence.

NSEC works by returning the “next secure” record. For example, consider a name server that defines AAAA records for api, blog, and www. If you request a record for store, it would return an NSEC record containing www, meaning there’s no AAAA records between store and www when the records are sorted alphabetically. This effectively tells you that store doesn’t exist. And, since the NSEC record is signed, you can validate its corresponding RRSIG just like any RRset.

Unfortunately, this solution allows anybody to walk through the zone and gather every single record without knowing which ones they’re looking for. This can be a potential security threat if the zone administrator was counting on the contents of the zone being private. You can read more about this problem in DNSSEC: Complexities and Considerations, as well as Cloudflare’s unique solution in DNSSEC Done Right.

The Chain of Trust

Ok, so we have a way to establish trust within a zone and connect it to its parent zone, but how do we trust the DS record? Well, the DS record is signed just like any other RRset, which means it has a corresponding RRSIG in the parent. The whole validation process repeats until we get to the parent’s public KSK. To verify that, we need to go to that parent’s DS record, and on and on we go up the chain of trust.

However, when we finally get to the root DNS zone, we have a problem: there’s no parent DS record to validate against. This is where we get to see a very human side of the global Internet.

In the Root Signing Ceremony, several selected individuals from around the world come together and sign the root DNSKEY RRset in a very public and highly audited way. The ceremony produces an RRSIG record that can be used to verify the root name server’s public KSK and ZSK. Instead of trusting the public KSK because of the parent’s DS record, we assume that it’s valid because we trust the security procedures around accessing the private KSK.

The ability to establish trust between parent and child zones is an integral part of DNSSEC. If any part of the chain is broken, we can’t trust the records we’re requesting because a man-in-the-middle could alter the records and direct us to any IP address they want.

Summary

Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.

Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.

We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.

Trusted by millions of Internet properties

View case studies