DNS poisoning (also known as DNS cache poisoning or DNS spoofing) is a type of attack which uses security gaps in the Domain Name System (DNS) protocol to redirect internet traffic to malicious websites.
How DNS poisoning works
When your browser or an application goes out to the internet, it starts by asking a local DNS server to find a particular address (such as bluecatnetworks.com or 22.214.171.124). The DNS server will then search for the answer by trying to locate the authoritative name server assigned to that IP 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 because 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 feed back whatever fake website it wants back to the host device – usually web pages which look like the desired website but actually are there to collect valuable information like passwords, banking information, and the like.
When standard issue DNS poisoning turns into DNS cache poisoning, the attack becomes even more difficult to deal with.
How DNS cache poisoning works
Once a DNS query is intercepted and “answered” by a malicious actor, the DNS resolver stores that answer in a cache for future use. While the caching process is designed to make frequently visited websites faster to load, in this case it makes a DNS poisoning 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) – a DNS server setting which tells the cache how long to store DNS records before refreshing the search for a legitimate server.
How to prevent DNS poisoning
Malicious actors are able to carry out DNS poisoning attacks because of inherent insecurities in the DNS protocol. We won’t go into the details of TCP and UDP here, but suffice it to say that DNS was built with convenience – not security – in mind. DNS poisoning attacks exploit vulnerabilities which were built into DNS from the beginning.
Thankfully, there are ways to prevent both DNS poisoning and DNS cache poisoning.
The DNS Security Protocol (DNSSEC) 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. It’s a lot more complicated than that, which is why we’ve put together this handy resource on how DNSSEC works.
Unfortunately, DNSSEC implementation isn’t as widespread as it should be. The primary reason for that is the decentralized configuration of default DNS solutions such as Microsoft DNS or BIND. For both of these, configuration of DNSSEC settings is a manual, complex, server-by-server process. Any update to those settings or DNS architectures requires another round of configurations.
The advantage of a centralized, automated DNS solution like BlueCat Adaptive DNS 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.
Another way to prevent DNS 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. This is another preventive measure which BlueCat’s Adaptive DNS solution enables through comprehensive DNS logging.
How to prevent DNS cache poisoning
Dealing with DNS poisoning through DNSSEC has the added benefit of lowering the threat of DNS cache poisoning to your domain name server. Yet there are still things you can do to protect your network further.
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 which could be led astray. How low that TTL setting needs to go is ultimately up to your network team – there’s a balance between security and performance which will probably need to be tuned 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 with the goal of preventing DNS poisoning attacks. We tend to set the TTL somewhere between five and thirty seconds, but that’s something you can adjust on your own if performance becomes an issue.
The twin challenges of DNS poisoning and DNS cache poisoning are significant, but closing the technical loophole which allows this to happen is probably easier than you think. Implementing a comprehensive DDI strategy is the best way to deal with these kinds of security vulnerabilities while at the same time improving the performance and reliability of your core infrastructure.
Learn more about BlueCat’s DDI solutions.