• United States



CSO Senior Writer

DNSSEC explained: Why you might want to implement it on your domain

Jul 30, 202012 mins
EncryptionInternet SecuritySecurity

The Domain Name System Security Extensions provide cryptographic authentication to prevent redirection to rogue websites, but owners of many domains have yet to adopt it.

padlock / Domain Name System / DNS / ICANN / security
Credit: Alpesh Ambalal Patel / Getty Images

DNSSEC definition

The Domain Name System Security Extensions (DNSSEC) is a set of specifications that extend the DNS protocol by adding cryptographic authentication for responses received from authoritative DNS servers. Its goal is to defend against techniques that hackers use to direct computers to rogue websites and servers. While DNSSEC has already been deployed for many of the generic and country-level top-level domains (TLDs), adoption at the individual domain level and end-user level has lagged behind.

What is DNS spoofing and hijacking?

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 external 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. Since DNS traffic was not authenticated or 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 — a man-in-the-middle scenario.

DNS is like the Internet’s phone book. It allows computers to convert human-readable domain names into numerical Internet Protocol (IP) addresses that they need to communicate since core networking protocols use IP addresses, not host names.

The Domain Name System has a hierarchical structure with 13 server clusters at the top that manage what is known as the root zone, then servers for each top-level domain (TLD) like .com or .net or country-code TLDs like .us or .ca, then servers for each particular domain name like, then maybe separate servers handling particular subdomains like

Every time a client, such as a computer or device, makes a query, this hierarchy is traversed from the top until the authoritative DNS server for the queried host name is located and responds with the IP address. However, to improve the performance of DNS, responses can be 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 DNS server that acts as a resolver, which in turn might query another DNS resolver. For example, home routers typically act as a DNS resolver and the first hop in the DNS chain for all computers and devices on the local network. Routers also typically forward requests to DNS resolvers operated by the customer’s ISP.

Understanding how DNS works is important because any server in that chain can be a weak link and a point from where attackers can serve rogue responses. Some malware changes the DNS settings on computers to use DNS servers operated by attackers, in which case the users of the infected computers will be affected. Mass attacks have compromised the DNS settings on home routers — this is known as router pharming — affecting all users of the networks served by those routers. Other attacks compromise an ISP’s DNS resolvers, in which case all of the ISP’s customers who rely on those servers could be affected.


DNSSEC was designed to address those risks and provide cryptographic verification through digital signatures that can be used to validate that records delivered in a DNS response came from the authoritative DNS server serving 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 to each other. The private key is used to sign records – actually, sets of records in a zone — and the signature is itself 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 real 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 child zone whose signature they want to validate. For example, the .com zone is the parent for the 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 then given to the parent zone which publishes it as part of its own records for the child zone and is essentially used to authenticate that the information presented in the child zone is valid.

To summarize, a DNS resolver uses a name server’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 in the first place is legitimate by looking at another record that contains a signature of that key and compares it with 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 was 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 DNSSEC is not

DNSSEC looks and sounds great, but it 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 happens quite often.

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” has now been extended.

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 in plaintext. A man-in-the-middle attacker, an ISP, or a government in certain countries that practice internet surveillance can see what domains and therefore websites a user is accessing by looking at their DNS queries.

They can also use DNS to block certain websites. ISPs in certain countries have been forced through court or government-issued orders to block access to certain other websites considered illegal, such as Bittorrent trackers, and this has been done via DNS.

DNSSEC has not been 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 the DNS resolvers they trust. Public DNS resolvers such as Cloudflare’s, Google’s, Quad9’s and others support both DNSSEC and DoT or DoH (often both) and are increasingly preferred by users instead 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 26%, but validation rates vary significantly by country and region. The US has a DNSSEC validation rate of 30%, Canada only 17%, Western Europe 46%, Eastern Europe 26%, while Africa and Asia of around 24%. In some countries, however, DNSSEC validation is over 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.

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 internet service providers, 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 actually 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 some 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 pretty seamless. However, 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 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 underway. 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 a proxy sitting between a user and 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.