Skip to main content
  • Cybersecurity

SAD DNS: the return of DNS Cache Poisoning

By Rob Williamson
Marketing Manager

Before I go any further, if you are a customer of one of CIRA’s DNS services then I will start with the conclusion. Our customers are not impacted by the latest threat to the DNS making the rounds on the internet.  

What is Side channel AttackeD DNS

A new security incident has been making the rounds on the internet this week. SAD DNS, standing for Side channel AttackeD DNS is basically a form of cache poisoning targeting the DNS.

This technique was used by the researchers to inject malicious DNS records into the DNS cache so they could redirect a query to a spoofed site in a man-in-the-middle attack. Their documentation on it is amazing, you should check it out if you’re into the technical details. However, if  academic papers with over 60 references aren’t your thing, we’ll provide a quick overview.

Primer on the DNS

When a user wants to visit a website or application they use human-readable domain names (ideally ones that end in .CA). Their device or browser then begins the process of looking up where the server is located. It does this by visiting a recursive resolver, which is a server on the internet that has cached the answer or knows how to look it up. If it doesn’t know the answer or determines that the answer it has might be out of date, it begins the process of looking it up.  This means it then traverses the massively distributed hierarchical database of authoritative resolvers that make up the internet’s DNS function. 

CIRA’s DNS services

To be clear, authoritative nameservers are not the target of this kind of attack, but they are mentioned here for those who may be concerned. The DNS resolvers that we provide in conjunction with the suppliers that provide the software have evaluated the risk and determined that we had already deployed the necessary functionality to prevent this DNS poisoning risk.

CIRA Anycast TLD – Authoritative resolver to top-level domains (i.e. .CA but also over 250 others around the world)

CIRA Anycast DNS – Authoritative service for organizations domains (i.e.

CIRA DNS Firewall – Recursive DNS that blocks threats for organizations

CIRA Canadian Shield – Recursive DNS that blocks threats for households 

You would be accurate in saying that we also operate a fifth service as the authoritative DNS for .CA.  As the country code top-level domain registry, I might as well state here that our portion of making over 2.9 million domains resolve isn’t impacted either.

SAD DNS targets recursive resolvers

We have been saying to anyone who listens that the DNS is too often overlooked by most organizations. Why? Well, even when it is misconfigured, it typically still works and it is often the last fire to put out in the day of most IT folks. Therefore, we understand why many folks don’t pay close attention to the hardware and software they have configured.

However, the DNS is taking on more and more responsibilities and so being compromised can be quite impactful. Most of the “attacks” we hear about these days are typical social engineering attacks at domain registrars to convince the technical support staff to change DNS records of others. Some of these have even been very costly and it seems that lately the focus of the hackers is on the DNS of cryptocurrencies due to the potential for theft. Unlike more hands-on social engineering attacks, SAD is more threatening because it occurs at the machine level and can be executed by bots. The paper explored several scenarios targeting home routers and DNS resolvers running BIND/Unbound.  To quote the report:

“With permissions, we also tested the attack against a production DNS resolver that serves 70 million user queries per day, overcoming several practical challenges such as noises, having to wait for cache timeouts, multiple backend server IPs behind the resolver frontend, and multiple authoritative name servers. In our stress test experiment, we also evaluate the attack in even more challenging network conditions and report positive results.”

The study evaluated 14 popular public DNS resolvers and found that 12/14 were, in principle, vulnerable, but they did not (thankfully) take the step of actually attacking these servers without the permission of the resolvers. I suspect each of these vendors have or will release a message of their own to address this latest published threat.

In addition to the public service, perhaps more worryingly was their success rate in attacking home routers was 100% in their test scenarios. We aren’t going to comment on home routers because it is a bit out of scope here.

Didn’t we solve this in 2008? Whatever happened to DNSSEC?

The study pointed out that the attack is off-path and therefore mitigated with cryptographic solutions. DNS Security Extensions was devised as a solution to cache poisoning. The extensions are designed to authenticate the origin of the DNS data and the data integrity.  Answers are digitally signed and the resolver can check if the information is identical to the information on the authoritative server. 

Many people have suggested that DNSSEC is a solution looking for a problem. We disagree.  And you might be tempted to think that those of us who favour the technologies adoption would be celebrating this recent news – I can assure you we are not. For us, the DNS is very serious business and we do hope that those who run the networks that make up the internet can become more active in enabling DNSSEC so it can help in the future.

For the end-user, the main problem with DNSSEC is that in order for an end-to-end chain of trust to be set up on the internet, every step in the chain has to support it. This requires the servers on the internet to support DNSSEC validation. In North America only 30% of servers do, and around the world, that number drops to 25%. This analysis is maintained by APNIC globally and makes for interesting navigation. The result of all this is virtually nobody has signed their zones.  The number is under 1% for all the domains out there.

Unfortunately today we cannot commit to recommending DNSSEC signing of zones at the organizational level but hope that one day the ISP and carrier networks can help catch us all up to help mitigate the next round of threats.

For further reading on DNSSEC, here is a good article from Network World.

What about DoH and DoT?

While it would be tempting to consider DNS encryption to be a solution, the reality is that it only protects the path to the resolver and it is still vulnerable. The resolver can still send you the wrong answer if it has been subject to cache poisoning and you can still get redirected to something malicious – the bad information will just be encrypted.

Any recommendations?

CIRA has always recommended using best-practice suppliers that are dedicated to the critical infrastructure they operate. It is the reason for the cloud model of computing and, when you think of it, the DNS is the internet’s original cloud. Even if a DNS provider is determined to be vulnerable to a zero-day problem, they are dedicated to monitoring the threatscape and to solving problems in an expedited matter.

On the recursive side, for organizations that choose to continue to run their own recursive servers, they can always be maintained behind the firewall and act as a (short period) caching server that forwards to something like CIRA’s DNS Firewall. This can continue to give the metrics you may be used to seeing while also benefiting from DNS management and, in our case, excellent malware and phishing protection.

About the author
Rob Williamson

Rob brings over 20 years of experience in the technology industry writing, presenting and blogging on subjects as varied as software development tools, silicon reverse engineering, cyber-security and the DNS. An avid product marketer who takes the time to speak to IT professionals with the information and details they need for their jobs.