DNS Poisoning Attacks: A Guide for Website Admins
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

DNS Poisoning Attacks: A Guide for Website Admins

How to protect your website against DNS cache poisoning attacks

There are literally hundreds of exploits and several million viruses that could penetrate your network defenses. Going after them all is a full-time job. Fortunately, that job is handled by experts whose only purpose is cyber security and technology that’s designed to detect and root out troublemakers.

One of the most odious and difficult to detect is DNS poisoning, also known as DNS spoofing, DNS hijacking, DNS cache poisoning, or DNS redirection.

What is this digital ailment, and what can you do to protect your networks?

Let’s hash it out.

What is DNS Poisoning?

How DNS works

Domain name systems are the equivalent of the internet’s phone directory. Every website has a unique domain name that’s used to identify its location on the internet. A domain name server (DNS) attack is a cybercrime that probes these servers looking for weaknesses to exploit. Once in, they can change coding or other information.

Simply put, a DNS poisoning attack compromises DNS servers so visitors who try to go to a website are secretly routed to the wrong IP address behind the scenes. The user may type “google.com” into their browser, but they’re actually routed to a server run by a hacker.

The main symptom of a DNS poisoning attack is a sudden, unexplained drop in web traffic. Though web traffic is always volatile, if you see a sudden reduction in the number of visitors to your site, it’s always worth investigating why. You can sometimes spot a DNS poisoning attack by pretending to be a customer: borrow a friend’s computer, or use a VPN to change your location, and try to access your site. If you’re re-directed to a site you don’t recognize, the chances are good that your DNS cache has been compromised.

How a DNS Exploit Endangers Your Website

Unlike a Direct Denial of Service (DDoS) attack, which overloads your server by sending an avalanche of requests, DNS spoofing discreetly draws traffic away from your website. Once individuals have been lured to the fake website, all kinds of malfeasance can occur

DNS exploits can spread from server to server, impacting more and more users. This is because of the way that IP addresses and domain name systems work. Domain names are readable only to humans. When a URL is typed into the address bar on your browser, it sends a request to a server, which returns a numeric IP address that can be read by the computer. Many times, it returns more than one IP address.

Because internet service providers handle millions of requests and IP addresses, they’re all stored in the same cache until the request can be routed to the proper location. In addition to the server and ISP you use to access the internet, your router acts as a type of DNS server that caches the information from the servers connected to your ISP.

That’s a lot of potential attack surfaces and points of entry to protect. In theory, the only sure way to stop the cycle of poisoning is for every cache attached to the DNS, ISPs, and personal or business routers to be cleared simultaneously. In practice, the most likely fix is for the DNS server most upstream with the corrupt record to be fixed and then trickle the correct data down to the rest.

A recent example of the impact these exploits can have is last year’s attack on MyEtherWallet servers. This crime involved hijacking the crypto company’s domain and redirecting account holders to a phishing website, where they were tricked into revealing their wallet security keys and transferring the money in their accounts to the hacker’s wallet. The attacker was able to make away with $160,000 in Ethereum cryptocurrency before the breach was discovered.

What makes these exploits so hard to detect is that they occur on the user side. Account holders have no idea that the domain has been hijacked and they’re being redirected to a fictitious website. They’re just going through their normal routine. The website owners won’t notice either until they discover a problem with their metrics.

Preventing DNS Poisoning Attacks

On Feb. 1 of each year, various DNS software developers host a DNS Flag Day symposium to address security issues and create compliance metrics to shore up problems with servers. However, they haven’t been able to do enough to keep up with new or revamped attacks.

Preventing DNS attacks is important for two groups: users who want to avoid being spoofed, and sysadmins who want to protect their own site from this kind of attack. In this section, we’ll give you methods for avoiding DNS cache poisoning from both perspectives.

Preventing DNS Cache Poisoning as a System Administrator

Let’s look at the website administration side first. Since it’s often so hard for website owners and administrators to detect DNS poisoning until after a lot of damage is done, and exploits can be spread to every associated DNS once launched, prevention is the best cure.

Choose Your Platform Wisely

The first place to start in preventing DNS poisoning is by choosing a secure hosting platform and content management system. If you don’t have the budget for a dedicated server, make sure that the hosting plan you choose has the most current encryption standards, DNS leak protection, SSL authentication, and a comprehensive back and restoration system. If you’re using WordPress as a CMS, follow basic security procedures like two-factor authentication (2FA) and regular software updates.

Keep Your DNS Servers Up to Date

In addition to choosing the right hosting platform for your security needs, you need to keep your DNS server updated. Regardless of whether you’re running Bind, MicrosoftDNS, or another server, the latest version is always going to have security patches and fixes installed as well as security standards like HSTS, DNSSec and Response Rate Limiting (RRL) to repel DNS attacks.


Probably the single most important thing you can do to protect against DNS poisoning is to use DNSSec, which is critical for avoiding DNS cache poisoning. The standard has been strengthened in recent years with features specifically designed to prevent this kind of attack. It will verify the root domain (referred to as “signing the root”) whenever an end user attempts to access a site.

Audit Your Zones

Many private DNS servers are loaded with old test domains and subdomains that are out of sight and mind. These are ripe for exploitation. You can monitor all zones, including hidden or forgotten ones, as well as all IPs and records using a tool like Security Trails. These types of tools allow you to catch possible vulnerabilities and prevent attacks before they happen.

Consider Forcing HTTPS

With HSTS, you can force browsers to always load your website on HTTPS. This helps you avoid DNS cache poisoning in one key way: a hacker who creates a fake version of your website is unlikely to be able to get a trusted SSL/TLS certificate for your domain. This means that when visitors are directed to the hacker’s fake version of your website, they’ll get a big security warning in their browser.

Preventing DNS Cache Poisoning as a User

Users should also be aware of the dangers of DNS redirects, since this type of attack can fool you into entering sensitive details into fake websites. Here are a couple of ways you can avoid that:

Mask Your Bind Version

Hackers usually keep track of common flaws in various generations of commonly used platforms. They then use this information to break into networks or platforms that are using a particular version. By hiding software versions, you can make things just a little harder for hackers to perform DNS poisoning. If you’re using the popular Linux-based DNS service, Bind, masking your Bind version is a good idea.

If Bind is your DNS software, all that’s required for a hacker to get your version number is to perform a remote query using this code: dig @ns1.server.com -c CH -t txt version.bind

That would return an answer like this if the Bind version is not hidden:

VERSION.BIND. 0 CH TXT "named 9.8.2...

To hide this information, go into your /etc/named.conf file and find the configuration block options { … }. This leads you to a line that says version “BIND”;.

Change that line to say version “Forbidden”;, and then save and close the file. You’ll have to restart Bind to apply the changes.

Check the Browser

One fast way to know if your DNS has been hijacked is to look for your business name in the certificate details displayed by the browser. The ability to see the company name in the address bar is an indication that the website is authenticated by an EV SSL/TLS certificate. Not all websites have an extended validation (EV) certificate, but the presence of the company name in the browser lets you know that it’s safe to proceed.

Final Thoughts

Your domain name is how your brand is identified on the internet. Protecting it from DNS poisoning attacks should be of the highest priority. Our goal is to provide you with actionable solutions that keep you from becoming the next cybercrime statistic and potentially costing your site its reputation.


Gary Stevens

Gary Stevens is a web developer and technology writer. He's a full time blockchain geek and a volunteer working for the Ethereum foundation as well as an active Github contributor.