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):
- Your DNS client does a DNS lookup for the destination domain’s MX record
- The client mail server receives a response
- 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):
- Your DNS client does a DNS lookup for the destination domain’s MX record which is DNSSEC signed (A cryptographic signature added)
- The client mail server receives a response and performs a DNSSEC validation, checking that the signatures match
- 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!
