What is DNSSEC?

The Domain Name System Security Extensions (DNSSEC) is a set of specifications that extend the Domain Name System (DNS) protocol by adding cryptographic authentication for responses received from authoritative DNS servers. Its goal is to defend against attack techniques such as DNS spoofing and hijacking attacks that direct computers to rogue websites and servers.

Although DNSSEC has already been deployed for many generic and country-level top-level domains (TLDs), adoption at the individual domain level and end-user level has lagged.

What is the Domain Name System?

The DNS protocol acts like a phone book for the internet. It allows computers to convert human-readable host names into the numerical IP addresses they need to communicate. The core networking protocols that allow the internet to work use IP addresses, not host names, but humans can’t easily remember a large number of unique IP addresses.

The Domain Name System has a hierarchical structure with 13 server clusters at the top that manage what is known as the DNS root zone. There are authoritative DNS servers for each TLD such as .com or .net, for country-code TLDs like .us or .ca, for particular domain names like google.com, and there can also be dedicated DNS servers to handle subdomains such as cloud.google.com.

Every time a client — a computer or device — makes a DNS query, this hierarchy is traversed from the top until the authoritative DNS server for the queried host name is identified and then that server responds with the IP address it has on record. To improve the speed and performance of this search, responses are usually cached for a period of time in servers along the path.

Most devices will not query the root zone themselves but will query a local server that acts as a DNS forwarder, which in turn might query another DNS resolver higher up in the chain and so on, until a cached answer is identified. For example, home routers typically act as DNS resolvers and forwarders for computers on the local network. For queries that don’t have a cached record, routers will typically forward requests to DNS resolvers operated by the customer’s ISP and so on. Any server in the DNS chain can be a weak link from which attackers can serve back rogue responses, if compromised.

There are malware programs that change the DNS settings on victim computers to use DNS servers operated by attackers, in which case users of those infected computers will be affected. Other attacks have altered the DNS settings on home routers — this is known as router pharming — affecting all users of the networks served by those devices. And there can be attacks that compromise an entire ISP’s DNS resolvers, in which case all the ISP’s customers who relied on those servers could be affected.

Why is DNSSEC important?

In 2008, security researcher Dan Kaminsky discovered a fundamental flaw in the DNS protocol that impacted the most widely used DNS server software. The flaw allowed attackers to poison the cache of DNS servers used by telecommunications providers and large organizations and force them to serve rogue responses to DNS queries, potentially sending users to spoofed websites or rogue email servers.

That flaw was patched in what was the largest coordinated IT industry response to a security vulnerability up to that time, but the threat of DNS hijacking attacks remained. Because DNS traffic was neither authenticated nor encrypted, any attacker taking control of a DNS server in a user’s DNS resolution path could serve malicious responses and redirect them to a malicious server — this is known as a man-in-the-middle attack scenario.

DNSSEC was designed to address those risks and provide assurance through cryptographic digital signatures that records delivered in a DNS response came from the authoritative server for the queried domain name and haven’t been altered en route.

Like Transport Layer Security (TLS) and other secure communication protocols, DNSSEC relies on public key cryptography. Each authoritative name server has a key pair made up of a private and a public key that are cryptographically linked. The private key signs records – actually, sets of records in a zone — and the signature is published as a DNS record. The public key can be used to validate the signature and is also stored in a DNS record.

How do resolvers ensure the signature and the public key came from the authoritative name server and not a man-in-the-middle attacker? They go higher up in the hierarchy chain to the parent zone of the zone whose signature they want to validate. For example, the .com zone is the parent for the google.com zone and the . (root) zone is the parent for the .com zone.

Another private and public-private key pair that DNS servers use is known as the key-signing-key (KSK). The private KSK key is used to sign the public key from the first pair that was used to sign records. The public part of the KSK is given to the parent zone, which publishes it as part of its own records for the child zone and is used to authenticate that information presented in the child zone is valid.

To summarize, a DNS resolver uses a nameserver’s public key to check that the records it provides were signed with its corresponding private key. It then makes sure that the public key presented by the server is legitimate by looking at another record that contains a signature of that key and uses a record from the parent zone — called a DS record — to validate it. This establishes a chain of trust between parent and child zones.

If you go higher and higher in the chain, who validates the topmost key pair that’s used to sign the Internet’s root DNS zone? The root key pair is generated in a hardware security module kept in a secure location and is rotated periodically in a public and highly audited ceremony involving trusted community representatives from around the world. There is also a key recovery process in the event of a major catastrophe where several individuals known as Recovery Key Share Holders need to come together in the same place and use cryptographic tokens in their possession to reconstruct the key.

What doesn’t DNSSEC fix?

DNSSEC doesn’t solve all problems with DNS security. First, to achieve its top potential it would have to be supported and enforced everywhere, on all DNS zones, on all domains and on all DNS resolvers. We’re far from that perfect world and gaps remain where attackers can insert themselves in the chain.

For example, an often-heard criticism of DNSSEC is the lack of protection for the so-called “last mile.” Because DNSSEC validation is done by resolvers, what protects the integrity of DNS responses between the resolver and users of that resolver. For example, if the DNSSEC-aware resolver is a home router, attackers could still compromise the home router and compromise the “last mile” and this does happen quite often in the real world.

Many home routers, especially older models, might not support DNSSEC or might not have it enabled. Maybe they forward queries to a DNS resolver that is DNSSEC-aware, like one run by an ISP. That’s better than nothing, but the unsecured “last mile” exposure is now even bigger.

DNSSEC also does not provide confidentiality and privacy because the DNS protocol itself is not encrypted. Digital signatures are provided to verify the integrity of records, but the records themselves are still transmitted in plaintext. A man-in-the-middle attacker, an ISP, or a government agency in a country that has internet surveillance laws can see in real time what domains, and therefore websites, a user is accessing by simply looking at their DNS queries.

ISPs from different countries have also been forced through court or government-issued orders to block access to certain websites that were considered illegal, such as Bittorrent trackers, and this was done via DNS.

DNSSEC was not designed to address these problems, and other protocols such as DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) can be used to encrypt DNS traffic between end users and DNS resolvers that they trust. Public DNS resolvers such as Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, Quad9’s 9.9.9.9 and others support both DNSSEC and DoT or DoH (often both) and are increasingly preferred by users instead of the DNS servers of their local ISPs which for commercial or legal reasons might interfere with or collect DNS traffic data.

DNSSEC deployment and adoption

APNIC, the Internet registry administering IP addresses for the Asia-Pacific region, has a project for monitoring DNSSEC validation across the world. According to the latest statistics, the global rate of DNSSEC validation is around 34%, but validation rates vary significantly by country and region. The US has a DNSSEC validation rate of 38%, Canada only 26%, Western Europe 63%, Eastern Europe 37%, Africa 38% and Asia around 31%. In some individual countries, however, DNSSEC validation is at over 80% or 90%.

When you look deeper into the data, you discover that in parts of Asia for example, the dominant ISPs chose to just forward DNS queries to Google’s Public DNS resolver instead of running their own local DNS servers, Dan York, leader of the Internet Society’s Open Standards Everywhere project, tells CSO. In other regions, large ISPs have decided to turn on DNSSEC validation on their DNS resolvers in recent years, for example Comcast in the US, he says.

Why isn’t everyone using DNSSEC?

DNSSEC deployment has many layers. It started with the generation of the first root key pair in 2010, but then the key pair was updated in a rollover process that took several years to plan and execute and was finalized in October 2018. The public part of the key pair had to be shared with ISPs, enterprise network administrators, DNS resolver operators, DNS resolver software developers, system integrators, and hardware and software distributors, which was a lengthy process.

The TLDs and ccTLD operators also had to generate and deploy their own keys and processes to enable DNSSEC for their respective DNS zones. Then there’s the issue of individual domain owners choosing to sign their own records.

“Deployment is moving on,” York says. “I think there was a pause between 2015 and 2018, while we waited around for the changing of the root key, where people running the DNS infrastructure kind of wanted to wait and see how the root key rollover would go. It completed in 2018 and all things are good, the lights are green, and now we’re seeing in the charts how DNSSEC deployment is going up.”

There are challenges, especially in the enterprise space, according to York, when it comes to signing their domains and rotating keys. In cases where the domain registrar is also the DNS provider and maintains the authoritative servers for a domain, they can do the signing automatically and transmit the signature records to the TLD to establish the chain of trust, so the process is fairly seamless. But enterprises tend to run their own DNS servers or use content delivery networks or DNS providers that are not also registrars, in which case they need to handle this process themselves.

“When you sign a domain, you have to give this little record — it’s called a DS record — to the TLD registry — .org, .com, .bank, etc. It’s part of this chain of trust that verifies your domain is signed,” York says. “The challenge with many enterprises is that they want to go and sign their own records .., but then they have to make sure that when their signing key gets changed, it gets communicated to the TLD. Usually they only have to do that once a year, but this is one part that some enterprises find a little clunky.”

There have been incidents in the past where websites became unavailable because of DNSSEC misconfigurations or expired records — the NASA and former HBO Now websites are two examples. By comparison, the TLS/SSL industry and Certificate Authorities have managed to automate some of the processes that involve certificate and key rotations.

“It’s something enterprises have to think about a bit,” York says. “There’s some work under way. There are some standards that allow people to do this. They just have to understand that these things exist.”

Also contributing to DNSSEC deployment, according to York, is the increased adoption of DANE (DNS-based Authentication of Named Entities). This is a protocol that relies on DNSSEC records to bind TLS certificates to domain names, essentially telling clients exactly which TLS certificate they should accept for a particular server. This is meant to prevent TLS interception where proxies sitting between a user and a server can terminate the TLS connection and serve it back to the user with a different certificate. It also makes it possible to use and trust certificates that are announced by a domain via DNS and cryptographically signed with DNSSEC even if they haven’t been issued by a publicly trusted Certificate Authority (CA).

“This hasn’t taken off in the browser space, largely because extra checks are involved and browsers are focused on performance and speed, but where it has come into play is with secure email,” York says. “There’s a growing number of people using DANE, which is then signed by DNSSEC, as a way to do secure encrypted email from email server to email server. That’s an interesting aspect and it’s something enterprises can look at: Is this a way they can make their email more secure, through providing these kinds of records for their email servers?”

York thinks we won’t see DNSSEC adoption explode like we did with TLS and especially HTTPS after Google and other large tech companies put their power behind it and made it default and mandatory for different services and applications. It’s more likely that it will be slower growth, as more ISPs begin to understand the value of using it to check things and it gets added and turned on in more and more tools, devices and applications. Over the past four years, between 2020 and 2024, DNSSEC validation increased by only 8% at the global level and still remains under 35%.