Insights

DNSSEC: the quickest win in Cyber Security?

Author:

Paul Ritchie

Enabling DNSSEC can take only a few minutes. It can be as simple as clicking a checkbox, and there is probably no potential impact for causing stability issues by enabling it. There is only security upside. Yet, despite this, the uptake for it has been extremely low.

We report this in almost every external infrastructure or web application penetration test report. Since we rate it as a low risk most customers seem to glaze over it and to choose to live with the risk. While we advise low risks are also mitigated, we understand that remediation effort is costly so must be targeted at the higher risk findings.

But please consider the costs of inaction on low risks. Every iteration of the project must verify the status of them again. Evidence is gathered and added to the report. This costs time from your penetration tester provider and internally when reports are being discussed you are now discussing it again. This is not a good use of valuable resources. A long chain of low risks following a target around inflates the size of reports and takes time and attention.

Not all low risks are the same. Some low risks can take a long time to fix and so they quite rightly may become accepted risks. They take planning, and they take user acceptance testing to verify things still work.

This is not the case with DNSSEC. It is an exceptionally quick win. In the time it takes for you to read this post you could have enabled DNSSEC to help protect the domains you own.

Actually… I urge you to stop reading and just go and do that!

Assuming you are still reading, the rest of this will explain what DNS is. What it is vulnerable to. A discussion of the risks of not enabling DNSSEC. Before ending with a list of references to how to enable DNSSEC for the most common DNS providers.

Hold up what is DNS?

Before we can explain what DNSSEC is, we must explain DNS (Domain Name System). DNS is the most human protocol in the Internet stack because it allows you to remember and enter a hostname (like “www.pentest.co.uk”) and to use that to access content. Without it you would need to memorise IP addresses, and human memory is not that good.

To get to this post your browser looked up “www.pentest.co.uk”, found the IP addresses, connected to one and loaded this content:

Translating the friendly name to an actual IP address is called DNS resolution. While DNS serves other functions this is the main function we need to understand.

What is DNS Vulnerable to?

DNS contains no authentication and has no transport layer security (TLS). DNS resolution occurs over insecure channels. It happens over a protocol which is stateless meaning a DNS resolution is a single request and response with no guarantees about who responded.

DNS is vulnerable to several attacks that take advantage of those weaknesses. For this blog post we have focused on two:

Man-in-the-middle (MiTM) attacks – An attacker, on the same network as the victim, can redirect traffic to themselves. This is commonly done using “ARP Spoofing”. When the victim sends a DNS request the attacker responds with an IP address under their control. The victim will then interact with a malicious service instead of the intended service. This can be configured to pass-through the user’s traffic to the legitimate host, and this leads to a loss of confidentiality for user traffic including credentials.
DNS Spoofing (Cache Poisoning) attacks – When a user requests a DNS resolution, their computer contacts a configured local DNS server. If the requested domain is not in the DNS server’s cache and the server is not authoritative for it, the server must query the domain’s authoritative name server to resolve the hostname. In a cache poisoning attack, an attacker exploits this by sending a DNS query and then flooding the user’s configured server with spoofed responses that appear to come from the authoritative server. This creates a race condition: if the forged response arrives before the legitimate one, the DNS server may cache the malicious record. Until the cached entry expires any user querying that domain through the poisoned DNS server will be directed to an IP address controlled by the attacker.

These are the most common threats.

What is DNSSEC (Domain Name System Security Extensions)

DNSSEC is an extension to DNS which adds in digital signatures to DNS records. This allows DNS clients to verify that a resolution response has come from a trusted source, and it has not been altered in transit. Cryptographically, this means the record cannot be tampered with by anyone who does not possess the private key.

Both MiTM and DNS Spoofing attacks are prevented because attackers lack the ability to sign the DNS response so the client will reject it.

What is the risk of not enabling DNSSEC?

Successful exploitation of the weaknesses within DNS most likely results in a loss of confidentiality. Tools exist which make this entirely possible to exploit. Typically, if there is a concrete risk with an impact and functional exploitation tools you would anticipate a high risk.

So, why is this not a high risk? To help, I present to you a snippet from one of our reports which shows our opinion of the risk:

The English explanation covers why it is a low risk by us on this occasion (each report should set the risk based on context). The bottom line is it is not an immediate threat from any Internet based attacker. The attacker needs to be – in most cases – on the same local network as the user. In order to elevate the risk, we would want to demonstrate exploitability.

There are situations where this would be true such as public WIFI networks or once an attacker has control of a machine on your internal network. However, in your typical external infrastructure or web application tests the scope is narrowly defined and exploitability is not possible in those scenarios.

Perhaps it is the sandbagging of these services for delivery, as the industry seems to dictate, that is losing vital context. If more projects were scoped as external and internal in the same report perhaps the risk could be proved and exploited more often? That is idle speculation.

How to Enable DNSSEC?

Fortunately, most DNS providers support DNSSEC and do so for free. Many even make enabling it as simple as clicking on a button within their portals.

In the following table we have linked you to DNSSEC documentation for a list of major DNS :

DNS Provider	DNSSEC Support	Setup Instructions	Cost to Enable DNSSEC
Cloudflare	Supported	Enable DNSSEC in Cloudflare	Free
Google Cloud DNS	Supported	Manage DNSSEC configuration	Free (standard DNS usage fees apply)
GoDaddy	Supported	Turn DNSSEC on or off	5 free DNSSEC credits; additional credits require Premium DNS subscription
NameCheap	Supported	Managing DNSSEC for domains pointed to Custom DNS	Free
Amazon Route 53	Supported	Configuring DNSSEC for a domain	Free, but AWS KMS charges apply for key management
Dyn (Oracle)	Supported	Adding DNSSEC To Your Zone	Free
IONOS	Supported	Setting Up and Managing DNSSEC	Free
DigitalOcean	Not Supported	N/A	Not Supported, as of May 2025.
Azure DNS	Supported	How to sign your Azure Public DNS zone with DNSSEC	Free
Oracle Cloud DNS	Supported	Enabling DNSSEC on a Zone	Free
DNS Made Easy	Supported	Enable DNSSEC to Prevent Security Issues	Free

What can you do if your DNS provider does not support DNSSEC?

You have two options:

1. Accept the risk – You are now aware of the potential risks and note that it has been rated as a low risk.
a. Track this in your risk register under known risks which you periodically review.
b. Who knows someday your provider might support DNSSEC and so you can move it off your register! You would only learn about this by reading the vendor’s site regularly which is why a technical risk register must be continually reviewed.

2. Migrate – to another DNS service provider which do support it and then enable it. You can then mark the risk in your risk register as “fixed”. Sit down and have a nice warm beverage of your choice.