DNSSEC explained

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.

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

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

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 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 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 find 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. In other regions, large ISPs have decided to turn on DNSSEC validation on their DNS resolvers in recent years, like Comcast in the US.

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.

Also contributing to DNSSEC deployment 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. "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?"

DNSSEC adoption wont explode like it 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.