What is the purpose of DNSSEC?

The purpose of DNS Security Extensions, or DNSSEC, is to authenticate DNS responses with the major goal of preventing spoofing. DNSSEC is a backward-compatible protocol extension to DNS that brings authentication and a data integrity check; so, when a DNS message is received, the receiver can verify that this message originated from the “real” DNS server (not a spoofed one) and that the message content integrity is not compromised during transmission.

For more Details on DNSSEC.

Prevent Spoofing

Spoofing, or DNS cache poisoning, is a type of attack that is focused on corrupting the cached answers on DNS servers with recursion enabled, either through software exploits or protocol weakness. Software exploits can be patched with software updates, but protocol weakness can only be updated with protocol fixes or extensions. DNSSEC is the “fix” for the traditional DNS protocol.

Figure FAQ-1 illustrates how an attacker performs DNS spoofing:

• Recursive DNS server sends a query to an authoritative server, such as querying for the MX record of example.com.
• The attacker competes with the authoritative server by sending forged responses, through timing to arrive before the authoritative server, and often with multiple “guesses” to increase the chance of success.
• Upon receiving the forged response, the recursive server has no mechanism to verify the validity of the response and stores the forged answer in its cache.
• Unsuspecting client queries for the name example.com MX record.
• The recursive server provides the answer from the now-poisoned cache with the forged answer from the attacker.

What DNSSEC provides is in step 3: the recursive DNS server would have a validating mechanism to verify the answer before storing it in its cache. With DNSSEC enabled, the authoritative DNS server would respond with security signatures that can be fully validated at each delegation level all the way to root, making it extremely difficult or nearly impossible for the attacker to spoof. In the example above, the attacker would have to impersonate not just example.com, but also .com, and root, in order to convince the recursive server to accept the forged answer into its cache.

To learn more about spoofing or cache poisoning, see cache poisoning.

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.

Fully Validated DNS

DNSSEC aims to provide a globally distributed database that can be fully validated. It accomplishes this by using public key cryptography to authenticate each message, ensuring it originated from the right source, and the content remains unaltered. All of the cryptographic information is stored in DNS itself, published as additional DNS records. A DNSSEC-enabled resolver (knowns as validating resolver) can chase up the DNS hierarchy, from example.com to .com to root, validating every layer.

Once we have a public database that can be fully validated, new features such as DANE becomes viable, opening doors to new possibilities and security features.

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