DNS Security Extensions (DNSSEC)

The lack of security in DNS has been a well-known issue for decades, and one that the DNS community has been trying to solve since the late 1990s. These efforts resulted in the birth of the DNS Security Extensions (DNSSEC¹).

DNSSEC basics

Take a look at what DNSSEC does and doesn’t provide:

• DNSSEC provides answer validation through the magic of public key cryptography. Public key cryptographs use of a pair of keys, one being public and one being private, that allows a DNS server to validate that the answer to a query came from the sender it says it did (in other words, that the sender wasn’t spoofed) and that the message content wasn’t changed during transmission. Keys are used to “sign” zones, meaning to create a cryptographic representation of the data that can only be turned back with the other key. This process provides both message authentication and message integrity.
• DNSSEC is backward compatible: DNSSEC can be deployed side-by-side with traditional DNS. If a domain is not yet DNSSEC-enabled, a DNSSEC-aware name server falls back to using traditional DNS.
• DNSSEC doesn’t encrypt traffic: Although DNSSEC uses both public and private keys, they’re only used for authentication purposes. Someone eavesdropping on the wire can still see all the DNS messages in plaintext; it just becomes nearly impossible to spoof.

DNSSEC requires deployment on both recursive name servers and authoritative name servers: The recursive name servers ask for additional security information and perform validation checks, while authoritative name servers provide signed resource records in responses. Figure 3-3 shows a simplified explanation of a DNSSEC-aware recursive name server, also known as a validating resolver, checking the answer it received.

A DNSSEC conversation

Figure 3-3: Shows an example conversation between DNSSEC servers.

In each step, the validating resolver asks for additional security information, chasing up to the domain’s parent for more security information if necessary, until it has reached the root server. The root server’s public key is well known, and in most cases of DNSSEC deployment, the root key is the only key that is trusted by the validating resolver. This is different from how certificate authority operates, where the client (usually the web browser) trusts dozens or hundreds of keys.

This hierarchical layer of security is known as “chain of trust,” and if any part of the chain is broken, the validating resolver rejects the answer and the client receives a generic error message. This means DNSSEC is all-or-nothing: either client receives a perfect answer that passes every single security scrutiny, or no answer at all.

DNSSEC Compatibility

DNSSEC is designed with full backward compatibility in mind. There are three (3) possible answers² when a validating resolver performs validation on a response, below is a short description of each response:

• Secure: the answer passed every validation, this means DNSSEC was fully deployed for this domain and every step was configured correctly.
• Insecure: the zone has yet to deploy DNSSEC, and the validating resolver fell back to using the traditional “insecure” way of resolving this domain name.
• Bogus: the zone has deployed DNSSEC, but one of the checks has failed, indicating there might be a spoofing attempt.

As you can see, most of us are getting response #2 today, because the majority of the zones have yet to be signed; when you choose to deploy DNSSEC and have done so correctly, the rest of the world will start getting response #1 from your zone data. If someone attempts to spoof your DNS records after you have deployed DNSSEC, the validating resolvers of the world will detect that and return response #3 to the clients, preventing them from obtaining the spoofed answer.

DNSSEC benefits

DNS spoofing, also known as cache poisoning, is a type of computer security hacking in which corrupt data is introduced into the DNS resolver’s cache, causing the name server to return an incorrect result record. By itself, cache poisoning does not seem dangerous, but it is often the first step in a combination attack. It’s a very difficult attack to detect and to guard against, and the damage can be tremendous. When properly deployed, DNSSEC stops cache poisoning attacks because attackers can no longer impersonate authoritative name servers or spoof answers man-in-the-middle style, thus stopping the chain of attacks that follows.

In addition to stopping cache poisoning and other DNS-based attacks, DNSSEC also bolsters other features. Many organizations already publish anti-spam information such as SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) in DNS; many certificates authorities (CA) also require the use of CAA (Certificate Authority Authorization) record when issuing out new SSL/TLS certificates, as a second factor of authentication.

There are other security-related applications of DNS, as well: For example, you can publish the SSH fingerprint of SSH servers in DNS, so when a user logs in to a machine via SSH, she can verify she’s not being tricked to login to a different machine. You can also publish TLSA records, which contain information about your web server’s SSL/TLS certificate, and when someone visits your web site, he can verify that his HTTPS connection has not been hijacked, and the certificate he received over HTTPS matches the one you published in DNS. This all relies on the fundamental property of DNSSEC that we can verify the authenticity of the responding name server, and the integrity of the answer received.

Being able to authenticate DNS messages is a big step forward not just for DNS, but also for the Internet as a whole because this would be the first time we have a global database that is trust-worthy.

Where is DNSSEC Deployed?

Although the original design intent was not for DNSSEC to be a server-only protocol, for practical reasons it has been deployed as such. This means DNSSEC protects communications among DNS servers and not the communication between the client and the local recursive DNS server. This last segment is commonly known as the “last mile,” and there are various other technologies that address this problem (see DoT and DoH).

¹ DNSSEC is documented in RFC 4033, RFC 4034, and RFC 4035, all ratified in March 2005.

² There are really 4 possible responses according to RFC 4035 Section 4.3, the one omitted here is “Indeterminate” or “Unknown”, usually a result of implementation error