DNSSEC email security protocol

What is DNSSEC?

Domain Name System Security Extensions, also known as DNSSEC, are a set of protocols that work alongside the well-known DNS.

DNSSEC was created to ensure that the DNS-answer your device receives is exactly the same as the one that the domain zone owner has provided. The common edition used today was released in 2005, with Google enforcing DNSSEC validation on all queries by default on it’s public DNS in 2013. 

When an email is sent, the process below takes place (simplified):  

  1. Your DNS client does a DNS lookup for the destination domain’s MX record
  2. The client mail server receives a response
  3. The email is sent

If the MX record in the above example was compromised and changed to an MX record under the control of an attacker, this email would end up in the wrong hands. 

DNS by default is not secure. When a recursive resolver makes a DNS query, it accepts any answer that it gets back, without questioning its authenticity. This leaves a vulnerability in a service that we use daily. To make things faster, recursive resolvers also use caching to maintain a list of the most accessed addresses. Therefore, if a hacker sends forged DNS data to the recursive resolver, the data would be cached for some period of time, causing all DNS queries done during this time to get fake responses. This is also known as DNS cache poisoning.

What can DNSSEC do and how does it help?

Since DNSSEC uses asymmetric cryptography, the DNS owner maintains a private key that is not shared and publishes a public key within their DNS, meaning anyone can see and use it for verification. With DNSSEC, DNS data is provided with a signature so it can be validated by the recipient. There are numerous advantages of DNSSEC including:

  • Integrity –  Information cannot be modified. If the data is changed the digital signature applied will not match and the data will be dropped by the recursive resolver. 
  • Data Origin – A recursive resolver can verify that the data received was from the zone where the data resides.   
  • Availability – Prevents cache poisoning attacks to give your services the best uptime.  

How it works

With DNSSEC, all zones publish their own public key which is used by a recursive resolver to validate the data in that zone. Along with each zone being signed, DNSSEC requires the zone’s public key to be signed. The zone’s public key is not signed by the zone’s private key, instead, it’s signed by the parent zone’s private key. 

E.g. redsift.io zone public key is signed by the .io parent zone.

When an email is sent out with DNSSEC enabled, the below process takes place (simplified):

  1. Your DNS client does a DNS lookup for the destination domain’s MX record which is DNSSEC signed (A cryptographic signature added) 
  2. The client mail server receives a response and performs a DNSSEC validation, checking that the signatures match
  3. The email is sent

A zone’s parent is responsible for the legitimacy of its child zone’s public key.

What is the chain of trust?

The public key at the start of the chain of trust is known as a trust anchor and recursive resolvers maintain a list of trust anchors for different zones. A common configuration is to have one trust anchor configured as the public key on the recursive resolver for the root zone. By starting the trust relationship at the root, a resolver can build trust with every zone in the DNS, as long as every zone is signed to be trusted.

Without the need for enabling encryption, DNSSEC performs an authentication using digital signatures. This gives the ability for DNSSEC to authenticate requests and provide a solution for the not secure DNS. 

Should you have any further questions about DNSSEC, please get in contact, or to begin demystifying the configuration of your domain’s DNSSEC, use our free Investigate tool today!

PUBLISHED BY

Murtazah Shah

8 Sep. 2020

SHARE ARTICLE:

Categories

Recent Posts

VIEW ALL
Security

How to drive cybersecurity as a top business priority

Jack Lilley

Everyone has a role to play in protecting the enterprise. Whether you’re shaping strategy or implementing solutions, aligning efforts to mitigate critical risks ensures a stronger, more resilient enterprise. If you missed Red Sift’s recent webinar on “From Data to Buy-In: Driving Cybersecurity as a Top Business Priority” we’ve got you covered. The session…

Read more
DMARC

BreakSPF: How to mitigate the attack

Red Sift

BreakSPF is a newly identified attack framework that exploits misconfigurations in the Sender Policy Framework (SPF) a widely used email authentication protocol. A common misconfiguration involves overly permissive IP ranges, where SPF records allow large blocks of IP addresses to send emails on behalf of a domain. These ranges often include shared infrastructures like…

Read more
Certificates

Never miss an expiring certificate again with Red Sift Certificates Lite

Francesca Rünger-Field

SSL/TLS certificates are the backbone of secure, uninterrupted digital experiences—but managing them effectively to prevent downtime remains a persistent challenge. With browser and certificate authorities looking to reduce certificate durations to as little as 90 or even 47 days, keeping track of renewals has never been more critical. That’s why we’re excited to introduce…

Read more
DMARC

Navigating G-Cloud 14 for DMARC solutions: A guide for former NCSC Mail…

Francesca Rünger-Field

Navigating G-Cloud 14 for DMARC solutions: A guide for former NCSC Mail Check users With the NCSC discontinuing key features of its Mail Check service, including DMARC aggregate and TLS reporting, after March 2025, UK public sector organisations must prepare for this change by transitioning to alternative email security solutions. To support this shift,…

Read more