It’s a question we often hear: “Isn’t DNSSEC the same as encrypted DNS?” 

Not really. While DNSSEC protects networks against man-in-the-middle attacks, it does so through public key cryptography, which is different from encryption. In other words, DNSSEC provides a form of authentication, but not a form of confidentiality. 

How is public key cryptography different from encryption? 

DNSSEC uses public key cryptography to digitally “sign,” or authenticate, DNS queries. When DNSSEC is enabled on a zone record, the receiving device can compare the information it receives with the original information sent by the authoritative server. This is enabled by a digital signature that uses public keys to authenticate data.  

In DNSSEC, the authentication keys are protected through cryptography, but the data itself is not protected. It’s still possible to intercept and read DNSSEC-protected traffic. If the data is manipulated somewhere along the data pathway and sent on to its destination, the receiving server will be able to tell that something is amiss because the public keys will not match. 

Encryption, on the other hand, uses cryptography to encode the data itself. Encryption ensures confidentiality by changing what an attacker would see if they intercept a query somewhere along the data pathway. It makes that data unintelligible unless the attacker can decipher the signal using an encryption key. Since that key isn’t publicly shared, encryption protects data from manipulation. 

Why doesn’t DNSSEC use encryption? 

DNS is one of the older protocols on the Internet. When it was created, the Internet was a much smaller place where pretty much everyone knew each other. Security was an afterthought. 

By the time Internet security became a concern, DNS was so widely used that any significant change would have brought the entire system to a screeching halt. Rather than try to develop a fully encrypted protocol to replace DNS, it was decided to bolt on an authentication mechanism to the existing system.  

DNSSEC was a compromise. It made the authentication of queries and data possible, increasing security of the protocol. But it did so without changing the underlying system, so the Internet could continue growing without the need to re-engineer anything. Deployment of DNSSEC was made optional so organizations could transition if and when they wanted. 

Why use DNSSEC if it isn’t encrypted? 

DNS cache poisoning (also known as DNS spoofing) is a big reason to deploy DNSSEC. In a DNS spoofing attack, an unauthenticated answer is substituted for the legitimate response to a DNS query. That answer then gets stuck in the cache, continuing to return the wrong answer and directing users to malicious sites until the “time to live” expires.  

DNSSEC protects against these kinds of attacks by authenticating DNS responses, ensuring that only correct answers are returned. Encryption may protect the underlying data in a DNS connection, but it wouldn’t protect against a DNS spoofing attack. 

Do people use DNSSEC if it isn’t encrypted? 

Unfortunately, only around 20% of Internet traffic is validated through DNSSEC. While that’s a significant increase from just a few years ago, it’s still a far cry from where it should be. A combination of usability issues, lack of information and sheer laziness accounts for that significant gap. 

NS1 strongly encourages all its customers to deploy DNSSEC, and promotes its use through a simple deployment process. Unlike other providers, NS1 even supports DNSSEC as a secondary provider or redundant DNS option through our Dedicated DNS offering.