What is DNS Poisoning, and How to Prevent It at Scale

DNS poisoning (also known as DNS spoofing or DNS cache poisoning) is a significant cybersecurity threat to enterprise networks that IT administrators and managed service providers (MSPs) must guard against. This guide explains the steps you need to take to prevent DNS poisoning with a repeatable playbook for hardening against DNS attacks.

What is DNS poisoning/DNS spoofing?

DNS poisoning is when an attacker inserts fake DNS records into the cache of a domain name server, with the aim of directing users to a malicious website that is controlled by the attacker. For example, a hacker may insert a record that sends users to a fake banking website that looks just like the real thing, and use it to steal their login details.

This is possible due to how DNS works: every domain has authoritative DNS servers, and DNS resolvers use these to look up the IP address of the web servers and other services available on that domain. Your devices will use a DNS resolver near to you (for example, one configured on your corporate intranet, or supplied by your ISP), and details retrieved during these lookups are cached to speed up future requests.

To poison the DNS cache on a resolver, hackers attempt to create a response that looks like it’s from an authoritative server, and respond faster than the authoritative DNS server for a domain, hoping that they can get their response cached instead of the legitimate one. Once it’s cached, the poisoned result will be returned until the cache expires or is purged. As the DNS system is distributed, resolvers may ask other resolvers for their cached details to speed up lookups (known as DNS recursion), propagating the poisoned records until they expire.

What you need to prevent DNS poisoning

To prevent DNS cache poisoning attacks, you’ll need:

• Authority and access to configure internal recursive DNS resolvers and firewall egress rules
• Inventory of approved upstream resolvers and forwarding paths
• Change window to enforce DoH/DoT profiles and block unauthorized DNS
• Central documentation for storing logs, evidence, and monthly summaries

Step 1: Lock down recursion and upstream resolvers

Iterative DNS queries occur when your DNS resolver asks a DNS server where it can find the authoritative server for a domain to retrieve DNS records. This other server will then point the resolver to the next DNS server, until the authoritative server is found and the DNS records can be read from it. This comes at a performance cost, so resolvers use caching to avoid having to do the full lookup each time. Recursive DNS occurs when the resolver asks a DNS server to do the iterative lookup rather than doing it itself.

If DNS cache poisoning has occurred on any resolver along the chain, you could be provided with poisoned records.

To protect against this, you should only allow recursion from trusted servers and disable open resolver behavior on internet-reachable interfaces. Limit upstreams to only approved servers, and monitor for unexpected changes to IP addresses in responses. Set conservative cache TTLs to ensure poisoned responses are short-lived if they do reach your network.

Step 2: Enable DNSSEC validation

Configure your DNS servers to use DNSSEC (Domain Name System Security Extensions). This technology protects against DNS poisoning by providing authentication to the process by adding secure cryptographic signatures to DNS records, so that systems can check whether they were tampered with.

Step 3: Enforce encrypted DNS

DNS over TLS (DoT) and DNS over HTTPS (DoH) should be used to encrypt DNS traffic between clients and resolvers. Enforce encrypted DNS by blocking outbound port 53 (except for your DNS resolvers) to prevent client devices from falling back to unencrypted DNS.

You can also leverage your endpoint management solution to deploy and enforce standardized configurations to servers and client devices.

Step 4: Add first-hop and anti-spoofing controls to your infrastructure

Use automated tools to block unexpected and potentially forged DNS traffic at your network boundary. Protect resolvers by randomizing query elements and rejecting mismatched responses. Record configurations to avoid drift, and run regular tests to ensure that they are effective.

Step 5: Detect, respond, and prove compliance

Log all resolver and cache activity for active alerts and future diagnoses if unexpected behavior occurs. Configure alerts in your monitoring solution for unusual TTLs, repeated NXDOMAIN errors (which occur when a domain cannot be resolved) or SERVFAIL errors (when the authoritative server does not provide a valid response), or spikes in DNSSEC validation failures.

If a DNS poisoning incident occurs, flush all affected caches, verify new records with a trusted external resolver, and log all responses (from both before and after the attack) for comparison and post-mortem review.

NinjaOne provides automated tools for configuring and enforcing DNS policies, and testing for suspicious behavior

NinjaOne provides a comprehensive toolkit for IT administrators and MSPs, including endpoint protection, remote monitoring and management (RMM), configuration deployment, automation, and documentation. Using this unified combination of industry-best tools, you can deploy and enforce DNS configuration on servers and end-user devices (including Windows, Mac, iOS, Android, and Linux), centralize the collection of logs, and generate monthly DNS protection summaries for client documentation.

This allows you to focus on creating hardened configurations and deploy them consistently across all infrastructure and devices, and maintain the integrity of your enterprise networks.