What is DNS poisoning and how to prevent it

DNS poisoning and DNS cache poisoning use security gaps in the Domain Name System (DNS) protocol to redirect internet traffic to malicious websites.

DNS poisoning attacks exploit vulnerabilities built into DNS from the beginning. Without getting into the details of DNS protocol, suffice it to say that DNS was built with scalability—not security—in mind.

This post will cover how DNS poisoning and its cousin, DNS cache poisoning, work. It will then examine ways to prevent both. And it will touch on how the BlueCat platform makes it easy to manage your DNS to keep poisoning at bay.

How DNS poisoning works

A user types example.com into a web browser. After that, the client device asks for IP address information and tries to find the answer locally on the device.

When your browser or an application goes out to the internet, it starts by asking a local DNS server to find the address for a name (such as bluecatnetworks.com). The local DNS server will ask the root servers that own that domain, and then ask that domain’s authoritative name server for the address.

DNS poisoning happens when a malicious actor intervenes in that process and supplies the wrong answer.

These types of man-in-the-middle attacks are often called DNS spoofing attacks. The malicious actor is, in essence, tricking the DNS server into thinking that it has found the authoritative name server when, in fact, it hasn’t.

Once it has tricked the browser or application into thinking that it received the right answer to its query, the malicious actor can divert traffic. By doing so, it can feed whatever fake website it wants back to the host device. These are usually pages that look like the desired website. In reality, they are actually phishing websites, attempting to collect valuable information like passwords or account numbers.

How DNS cache poisoning works

Standard-issue DNS poisoning can also turn into DNS cache poisoning. When that happens, the attack becomes even more difficult to deal with.

Most DNS resolvers are caching resolvers. This both reduces the load on remote DNS servers and more quickly returns answers. Caching resolvers will only make requests to remote servers the first time a domain name is asked for and again when that cache entry expires. In the meantime, it might serve thousands of requests with the cached value.

So, once a malicious actor intercepts and “answers” a DNS query, the DNS resolver stores that answer in a cache for future use. And in this case, it makes the attack worse by continuing to supply that wrong answer.

Even if your filters and firewalls identify the IP address as a malicious site and block it, browsers and applications will still try to go there as long as the cache defaults to the wrong answer.

How long those DNS entries remain in your cache depends on the time to live (TTL). This is a DNS server setting that tells the cache how long to store DNS records before refreshing the search for a legitimate server.

How to prevent DNS poisoning

Thankfully, there is an antidote: DNS Security Protocol (DNSSEC). This protocol was developed specifically to counter DNS poisoning.

Implementation of DNSSEC is a recognized best practice used by most large enterprises. ICANN recommends DNSSEC for everyone and it is also part of many industry standards such as NIST 800-53. (Note that DNSSEC is different from DNS security.)

DNSSEC uses public-key cryptography to verify that an authoritative nameserver is providing the correct information back to the requesting device. In reality, it’s a lot more complicated than that. So, BlueCat has put together this handy resource on how DNSSEC works.

DNSSEC can be simple with the right solution

Unfortunately, DNSSEC implementation isn’t as widespread as it should be.

The decentralized configuration of default DNS solutions such as Microsoft DNS or BIND is primarily to blame. For both of these, the configuration of DNSSEC settings is a manual and complex server-by-server process. And any update to those settings or DNS architectures requires another round of configurations.

The advantage of a centralized, automated DNS solution like BlueCat is that protecting your network against DNS poisoning through DNSSEC is simple. Setup is straightforward, with configurations and updates happening automatically on the back end across the network.

DNS response data also helps

Another way to prevent poisoning is to pay attention to DNS responses. Even without the protocol-level cryptography of DNSSEC, you can simply compare the DNS request and the DNS response data to see if they match. BlueCat’s platform makes it easy to do that with comprehensive DNS logging.

How to prevent DNS cache poisoning

DNSSEC also lowers the threat to your domain name server from DNS cache poisoning attacks. But there are still more things you can do to further protect your network.

Adjusting the TTL of your DNS caching servers will certainly help with any DNS cache poisoning issues. Lower TTLs will naturally decrease the number of DNS queries that could be led to the wrong address. How low that TTL setting needs to go is ultimately up to your network team. There’s a balance between security and performance for TTL values that will probably need tuning over time.

Since it sits as the first hop in any network query, BlueCat manages the caching function of every DNS server on your network. With BlueCat DNS infrastructure in place, you can automatically adjust the TTL on every query to help prevent DNS poisoning attacks. BlueCat experts tend to set the TTL somewhere between five and 30 seconds. But that’s something you can adjust if performance becomes an issue.

The challenges from spoofed DNS are significant, but closing the technical loophole that allows them to happen is probably easier than you think.

Implementing a comprehensive DNS, DHCP, and IP address management (together known as DDI) strategy is the best way to deal with these kinds of security vulnerabilities. At the same time, you can improve the performance and reliability of your core infrastructure. DNS is usually thought of as something that needs to be protected. But you can also leverage your DNS to better secure your enterprise network.