November 5, 2026
Updated: November 5, 2026
How DNS resolution can be lied to, from the Kaminsky and SAD DNS cache poisoning attacks to Sea Turtle-style hijacking, and the controls that detect and prevent each one.
Mohammed Khalil
DNS spoofing is an attack that makes a computer accept a false answer to a DNS lookup, so a name like your bank's or your mail server's points to an address the attacker controls. The most studied form is DNS cache poisoning, where a resolver stores the forged answer and hands it to every user who asks. This guide explains how DNS resolution works, how cache poisoning evolved from the 2008 Kaminsky attack to the 2020 SAD DNS research, how local spoofing and DNS hijacking differ, and which controls actually detect and prevent each variant.
DNS spoofing is any attack that delivers forged Domain Name System data to a client or resolver, so a domain name resolves to an IP address the attacker chooses. Users type the right name, see the right name in the address bar, and still reach the wrong server.
The terms overlap in everyday use:
In MITRE ATT&CK, DNS manipulation shows up in more than one place. Adversary-in-the-Middle (T1557) lists DNS among the protocols attackers abuse to force traffic through their systems, and Compromise Infrastructure: DNS Server (T1584.002) covers attackers who alter records to redirect an organization's traffic. Our MITRE ATT&CK framework guide explains how those techniques fit together.
To see where a lie can enter, you need the normal path first. DNS is defined in RFC 1034, published in November 1987. A typical lookup for www.example.com works like this:
.com top-level domain (TLD) servers. Those refer it to the authoritative name servers for example.com.Two design facts matter for security. First, classic DNS runs over UDP, which has no handshake, so the resolver matches an answer to its question by a few fields: the query name and type, a 16-bit transaction ID (TXID) and the UDP port the question left from. Second, plain DNS has no built-in proof that an answer came from the real authoritative server. Any packet that matches those fields and arrives first can be accepted.
The records an attacker would forge or change also matter. An A or AAAA record points a name at a server, an MX record decides where email goes, and an NS record decides who answers for a whole zone. Control of NS records is the most powerful, because it hands over every name below them.
| Attack point | Variant | What the attacker needs | Who is affected |
|---|---|---|---|
| Between the device and its resolver | Local or on-path spoofing | A position on the same network, for example through ARP spoofing or a rogue DHCP server | Users on that network segment |
| Inside the recursive resolver's cache | Off-path cache poisoning | The ability to send packets with a spoofed source address and to guess or learn the TXID and port | Every user of that resolver until the TTL expires |
| The resolver or router itself | Compromised resolver or changed DNS settings | Control of the resolver, a home or branch router, or the device's DNS configuration | Everyone who uses that resolver or device |
| The authoritative records, registrar or registry | DNS hijacking | Credentials or access at the DNS provider, registrar or registry | Every user worldwide, often with valid TLS certificates |
Cache poisoning is the variant that made DNS spoofing famous, because one successful forged answer can redirect a whole user base. The attacker is "off-path": they cannot see the resolver's traffic, so they must guess what the resolver expects.
The race works like this, as described in Google's Public DNS security documentation. The attacker causes the resolver to look up a name that is not in its cache. While the resolver waits for the real authoritative server, the attacker sends many forged responses that appear to come from that server. If one forged response matches the query name, type, TXID and source port, and arrives before the genuine one, the resolver caches it and drops the real answer. A long TTL on the forged record keeps it in place.
The TXID is 16 bits. CERT/CC notes that with a strong random number generator an attacker needs, on average, 32,768 attempts to predict it. In the mid-2000s many resolvers also sent every query from one fixed source port, sometimes port 53 itself, so the TXID was the only secret. Weak random number generators in some implementations made even that easier, and some servers sent several identical queries at once, which raised the odds through a "birthday attack."
On July 8, 2008, CERT/CC published VU#800113, and NVD published CVE-2008-1447, the flaw widely called "the Kaminsky bug" after researcher Dan Kaminsky. NVD describes it as a birthday attack that "uses in-bailiwick referrals to conduct cache poisoning against recursive resolvers," caused by insufficient randomness of transaction IDs and source ports. It names BIND 8 and 9 before 9.5.0-P1, 9.4.2-P1 and 9.3.5-P1, Microsoft DNS in several Windows versions, and other implementations.
The idea, at a conceptual level, was to remove the waiting time between guesses. Before 2008, a failed attempt meant waiting for the real answer's TTL to expire. Kaminsky's approach asked about a stream of random, nonexistent names under the target domain. Each name was uncached, so each one gave a fresh race. The forged answers did not need to fake the random name itself; they carried a referral that claimed authority over the parent domain. One win could hand the attacker control of the whole zone in that resolver's cache.
The coordinated fix was source-port randomization: send each query from a random UDP port. CERT/CC says this adds about 16 bits of randomness and, if properly implemented, reduces an attacker's chances "by several orders of magnitude." It also warned of two limits that still apply:
The standards follow-up came in January 2009 as RFC 5452, "Measures for Making DNS More Resilient against Forged Answers," which standardized hardening behavior for resolvers.
For twelve years, a random 16-bit port plus a random 16-bit TXID meant an off-path attacker faced about 2^32 combinations, which is impractical. In November 2020, researchers from the University of California, Riverside and Tsinghua University showed how to split that problem in two. Their paper, "DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels" by Keyu Man, Zhiyun Qian, Zhongjie Wang, Xiaofeng Zheng, Youjun Huang and Haixin Duan, was presented at ACM CCS 2020 and named the attack SAD DNS.
The key was ICMP. When a packet reaches a closed UDP port, the operating system may reply with an ICMP "port unreachable" message, and it limits how many such replies it sends per second with a global counter. That shared counter leaks information: by watching whether a probe uses up the limit, an attacker can tell whether a guessed port is open. So the attacker finds the resolver's source port first, then guesses only the TXID. In the paper's words, the search drops from 2^32 to "only 2^16 + 2^16 spoofed responses." The researchers also showed ways to keep the resolver's query outstanding longer, which widens the window.
What the paper and the authors' SAD DNS FAQ report:
The same team published a follow-up at ACM CCS 2021 ("Resurrections with Side Channels") that found further side channels. The lesson for defenders is not that one patch failed. It is that randomization defends DNS only as long as the randomness stays secret, while DNSSEC adds a cryptographic check that a guessing attacker cannot pass.
Cache poisoning targets the resolver. Local spoofing targets the hop between a device and its resolver, which on most networks is plain, unauthenticated UDP. An attacker who can see or redirect that traffic does not need to guess anything; they read the TXID and port from the real query and answer first.
The common ways to get that position are all adversary-in-the-middle techniques:
A related Windows issue is name-resolution poisoning of fallback protocols such as LLMNR and NBT-NS, which ATT&CK groups with SMB relay under T1557.001. It is not DNS, but it exploits the same idea: a device asks the local network "who is this name?" and believes the first answer.
Local spoofing affects fewer people than a poisoned resolver, but it is far easier, and on internal networks it often leads straight to credential capture. That is why internal network tests examine it, as our internal penetration testing guide describes.
The two terms are often used as synonyms, but defenders need to separate them because the fixes are different. Spoofing forges answers; hijacking changes the source of truth.
| DNS spoofing and cache poisoning | DNS hijacking | |
|---|---|---|
| What the attacker changes | A single answer in transit or in a cache | The authoritative records, the delegation or a device's resolver setting |
| Typical access needed | Network position or the ability to send spoofed packets | Stolen credentials at a registrar, registry or DNS provider, or control of a router or device |
| Scope | One network, or one resolver's users until the TTL expires | Everyone who looks up the domain, worldwide |
| Duration | Until the cache entry expires or is flushed | Until someone notices and reverts the change |
| Does DNSSEC help? | Yes, if the zone is signed and the resolver validates | Often not: an attacker who controls the registrar or provider may be able to change the signing setup too |
| Do TLS certificates help? | Yes, a spoofed site normally cannot present a valid certificate | Not reliably: the attacker can pass domain validation and get a valid certificate |
| Main defenses | Patched, randomizing and validating resolvers; encrypted client-to-resolver DNS; LAN protections | Phishing-resistant MFA, registry lock, change monitoring, Certificate Transparency monitoring |
DNS hijacking is also different from two other routing and naming attacks that DeepStrike covers separately. BGP hijacking redirects the IP routes themselves, so even a correct DNS answer can lead to the wrong network. DNS tunneling abuses DNS as a covert channel for data rather than lying about addresses. Lookalike domains, such as those in a homoglyph attack, trick the user into typing or clicking the wrong name; DNS then answers honestly.
On April 17, 2019, Cisco Talos published its research on "Sea Turtle," a campaign it assessed with high confidence as state-sponsored. Talos reported that at least 40 organizations in 13 countries were compromised, mainly in the Middle East and North Africa, in activity that likely began as early as January 2017 and continued through the first quarter of 2019.
Sea Turtle is a hijacking case, not cache poisoning. Talos separated victims into two groups:
The attackers gained initial access by exploiting known vulnerabilities or through spear phishing, took control of the DNS records of their targets through those third parties, pointed the records at servers they controlled, and captured the credentials of users who connected. MITRE ATT&CK now tracks the group as Sea Turtle (G1041), noting that it modified name server records so its own servers answered all lookups. Talos assessed the campaign as distinct from an earlier DNS-focused operation it had reported in November 2018, known as DNSpionage.
Three months earlier, on January 22, 2019, the US Cybersecurity and Infrastructure Security Agency issued Emergency Directive 19-01, "Mitigate DNS Infrastructure Tampering", after tracking a series of incidents that affected multiple federal executive branch domains. The directive described the technique in three steps:
A, MX or NS records to point to infrastructure they control, inspecting or manipulating traffic before optionally passing it on to the real service.Agencies had 10 business days to complete four actions: audit public DNS records on all authoritative and secondary servers, change the passwords of every account that can change DNS records, add multi-factor authentication to those accounts (CISA recommended phishing-resistant factors and advised against SMS), and begin monitoring Certificate Transparency logs for certificates they had not requested.
CISA's page, dated January 8, 2026, states that the directive's purposes have been met and that it has been sunset. Its four actions remain a practical baseline for any organization that owns domains.
Across these cases, a successful DNS attack typically buys one or more of the following:
MX records or redirecting mail servers.Detection is hard because a successful spoof looks like a normal lookup to the user, and the SAD DNS authors note that end users generally cannot see the attack. The signals live with whoever runs the resolver, the network and the domains. The table lists signals by layer; it is guidance, not a complete detection program.
| Layer | Signal | What it can mean |
|---|---|---|
| Recursive resolver | Bursts of responses with the wrong transaction ID for outstanding queries | Someone is racing forged answers, a pattern the SAD DNS authors list as detectable |
| Recursive resolver | Many queries for random, nonexistent subdomains of one domain | Kaminsky-style attempts, though the same pattern can come from DNS tunneling or misconfigured software |
| Recursive resolver | DNSSEC validation failures (bogus answers) for a signed zone | A forged or stripped answer, or a broken signing setup at the zone owner |
| Network | UDP port scanning toward a resolver, or regular packet bursts (the SAD DNS authors cite one every 50 ms) | Side-channel probing |
| Local network | ARP replies that change the gateway's MAC address, or DHCP offers from an unknown server | An on-path position for local spoofing |
| Endpoints | Resolver settings or hosts file entries that differ from the managed baseline | Malware or tampering on the device or home router |
| Your domains | Unexpected changes to NS, A or MX records, or registrar account changes | DNS hijacking |
| Certificates | New certificates in Certificate Transparency logs that you did not request | Hijacking used to obtain certificates, as ED 19-01 warned |
Three habits make these signals useful. Log resolver activity centrally, including validation failures and unexpected replies. Compare your public records against a known-good baseline from more than one vantage point on a schedule, starting with NS and MX records as CISA advised. And subscribe to Certificate Transparency monitoring for every domain you own; the logs are defined in RFC 6962.
No single control covers every variant. Randomization stops blind guessing, DNSSEC stops forged data at validating resolvers, encrypted DNS protects the last hop, and account security protects the records themselves. NIST's SP 800-81 Revision 3, Secure Domain Name System (DNS) Deployment Guide, finalized in March 2026, is the most complete reference for enterprise deployments.
Run supported resolver software and keep the operating system patched, including the CVE-2020-25705 kernel fix on Linux. Confirm that queries use random source ports and random transaction IDs as RFC 5452 describes, and check that firewalls or NAT devices in front of the resolver do not rewrite ports into a predictable range. CERT/CC also recommends restricting recursion to your own clients: an open resolver answers anyone, which gives attackers a free way to trigger the lookups they need.
DNSSEC, introduced in RFC 4033 (March 2005), adds digital signatures to DNS data. A validating resolver checks the chain of signatures from the root down and rejects answers that do not verify, so a forged answer fails even if the attacker guessed every field. Two cautions apply. DNSSEC protects integrity and origin, not confidentiality; it does not encrypt anything. And it only protects names in signed zones, checked by resolvers that validate. Turn on validation in your resolvers, and sign the zones you own so other people's resolvers can protect your users.
DNS over TLS (RFC 7858, May 2016) and DNS over HTTPS (RFC 8484, October 2018) wrap the stub resolver's queries in an encrypted, authenticated connection. That defeats on-path spoofing on the local network, including ARP-based attacks. It does not protect the resolver's own cache, its traffic to authoritative servers, or records that were hijacked at the source. For managed devices, point encrypted DNS at resolvers you control or trust, so the security team keeps visibility into lookups.
Resolvers can add more secrets for an off-path attacker to guess. DNS Cookies (RFC 7873) let clients and servers recognize each other's responses. "0x20" encoding randomizes the upper and lower case of letters in the query name and checks that the answer matches. The SAD DNS authors list both, alongside DNSSEC, as ways to add secrets to DNS messages. Treat them as extra layers, not substitutes for validation.
As an illustration, these are real options in the Unbound resolver, documented in the unbound.conf manual. Check the manual for your version before applying any of them:
# Illustrative excerpt for a validating Unbound resolver. Not a complete configuration.
server:
auto-trust-anchor-file: "/var/lib/unbound/root.key" # DNSSEC validation from the root trust anchor
harden-glue: yes # do not trust out-of-zone glue
harden-dnssec-stripped: yes # treat missing DNSSEC data in signed zones as bogus
harden-referral-path: yes # extra validation of referrals (more queries)
use-caps-for-id: yes # 0x20 case randomization; experimental, test first
unwanted-reply-threshold: 10000000 # clear caches and warn after many unwanted repliesThe manual notes that use-caps-for-id is experimental and off by default, and that some domains need an exemption. unwanted-reply-threshold is a defensive trigger: when a thread sees that many unwanted replies, Unbound clears its caches and writes a warning to the log, which also makes it a useful detection signal.
DNS hijacking bypasses every network control above, so protect the accounts that can change your records:
clientUpdateProhibited, while registries set server codes that take precedence. Registry-level locking, often sold as "registry lock," requires an out-of-band verification before critical changes, which is what Sea Turtle-style attacks need to get past.NS, MX and other critical records, and review registrar audit logs.Stop the on-path position that local spoofing needs. On managed switches, DHCP snooping blocks rogue DHCP servers and Dynamic ARP Inspection drops forged ARP replies. Segment guest and IoT networks, disable LLMNR and NBT-NS where they are not needed, and lock down endpoint resolver settings through device management.
TLS checks the server's certificate, so a spoofed site usually cannot impersonate an HTTPS service without a browser warning, and HTTP Strict Transport Security stops downgrades to plain HTTP. This is a strong last line against spoofing and cache poisoning. It is weak against hijacking, because an attacker who controls your DNS can obtain a valid certificate, which is exactly what ED 19-01 warned about.
| Control | What good looks like | How to verify |
|---|---|---|
| Resolver patching | Supported resolver and OS versions, including the CVE-2020-25705 kernel fix on Linux | Compare versions against vendor advisories |
| Port and ID randomization | Random source ports and TXIDs, not rewritten by NAT | Review resolver and firewall configuration; inspect captured queries in a lab |
| Recursion | Recursion allowed only for your own clients | Query from an outside address in an authorized test; expect refusal |
| DNSSEC validation | Enabled on every internal resolver | Look up a deliberately broken DNSSEC test domain; expect a failure |
| Zone signing | Your zones signed, with DS records at the parent | Check the chain of trust with a DNSSEC analysis service |
| Encrypted client DNS | Managed devices use DoT or DoH to approved resolvers | Review device policy and resolver logs |
| Registrar security | Phishing-resistant MFA, minimal users, registry lock on key domains | Account review; registry status codes in a WHOIS or RDAP lookup |
| Record monitoring | Alerts on NS, A and MX changes against a baseline | Make an approved test change and confirm the alert |
| CT monitoring | Alerts for unrequested certificates on every domain | Confirm the domain list in the monitoring service |
| LAN protections | DHCP snooping, Dynamic ARP Inspection, LLMNR and NBT-NS disabled | Switch configuration review; lab test on a test VLAN |
DNS testing has to be scoped carefully, because DNS is shared infrastructure and forged traffic can affect people outside the test. Professional testing works only on systems the client owns or is authorized to test, keeps active spoofing to an isolated lab or an agreed test segment, and never sends forged answers to public resolvers or other organizations' servers. The steps below describe a method; they are not attack instructions.
Testers list every resolver, forwarder and authoritative server in scope, the registrars and DNS providers that hold the organization's domains, and how devices get their resolver settings (DHCP, device management or manual). Our network penetration testing guide explains how this fits into a wider infrastructure assessment.
From inside the network, testers check whether resolvers are patched, whether they randomize source ports through any NAT in front of them, whether they validate DNSSEC, and whether recursion is limited to internal clients. From outside, an external penetration test confirms that no resolver answers recursive queries for the whole internet.
On a test VLAN with test devices, testers check whether the switch blocks forged ARP replies and rogue DHCP offers, whether endpoints accept a changed resolver, and whether LLMNR and NBT-NS answers are possible. A finding records which control was missing and what an attacker on that segment could reach.
Testers review registrar and DNS-provider account security with the client (MFA type, number of users, lock status), check that critical zones are signed with a valid chain of trust, compare live records against the intended configuration, and confirm that Certificate Transparency monitoring covers every domain.
A useful report names each weak point, the variant it enables (local spoofing, cache poisoning or hijacking), the realistic impact, and the fix. After remediation, the same checks are repeated to confirm the change.
DNS spoofing is when an attacker gives your computer a fake answer to the question "what is this website's address?" You type the right name but connect to a server the attacker controls, which can then steal passwords, intercept email or deliver malware.
Not exactly. DNS spoofing is any forged DNS answer. Cache poisoning is the case where the forged answer is stored in a resolver's cache and served to many users until it expires. All cache poisoning is DNS spoofing, but local spoofing on a single network does not have to poison a cache.
Use patched resolvers that randomize ports and validate DNSSEC, sign your own zones, encrypt device-to-resolver DNS with DoT or DoH, protect the local network with DHCP snooping and Dynamic ARP Inspection, and secure registrar accounts with phishing-resistant MFA and registry lock.
Usually not by the end user, but resolver operators and network teams can. Signals include bursts of replies with wrong transaction IDs, DNSSEC validation failures, ARP or DHCP anomalies, unexpected record changes and unrequested certificates in Certificate Transparency logs.
It prevents forged answers for signed zones when the resolver validates signatures. It does not encrypt queries, does not help unsigned domains, and does not stop an attacker who hijacks the records or signing setup at the registrar or DNS provider.
Largely, for spoofing and cache poisoning: a fake server normally cannot present a valid certificate, so the browser warns the user. It does not protect against DNS hijacking, where attackers who control the domain's records can obtain a valid certificate.
Switching to a large public resolver such as Google Public DNS (8.8.8.8) is generally safe. Google documents DNSSEC validation, DoT and DoH support and extra entropy measures against cache poisoning. It sends your lookups to Google instead of your ISP, so weigh privacy and corporate policy, and use encrypted DNS so the local hop is protected too.
A VPN that sends DNS queries through its tunnel protects the hop between your device and the VPN's resolver, which defeats local spoofing on public Wi-Fi. It does not protect against a poisoned or compromised resolver at the VPN provider, or against hijacked records.
DNS spoofing rarely announces itself. A resolver that stopped randomizing behind a new firewall, a zone that was never signed, a registrar account with password-only login or a flat office network can each open the door, and none of them shows up in day-to-day operations. The useful questions are concrete: which resolvers validate DNSSEC, which domains have registry lock, who can change your NS records, and what an attacker on your network could answer for you.
DeepStrike's penetration testing services include infrastructure penetration testing performed manually, with reports that give reproduction steps, remediation and root causes for each validated finding. When you scope a test, ask for resolver, domain and local-network DNS checks to be included. To discuss scope, contact DeepStrike.
Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us