DNS was designed in the 1980s for a friendly network: answers travel over UDP with no signature, any server will talk to anyone, and whoever controls a domain's registration controls where it points. Each of those choices is a door someone has learned to push on. This chapter takes the doors one at a time, from the defender's side: how each abuse works at the level the public advisories describe it, what stops it, and what it looks like in your logs. If "the internet is down, it's probably DNS" is new to you, start with DHCP & DNS on networks.jelia.nyc; this chapter assumes you know what a resolver and a cache are.
Common mix-up: cache poisoning and DNS hijacking are different attacks with different cures. Poisoning slips a forged answer into a resolver's cache; the real records never change, and DNSSEC validation stops it cold. Hijacking changes the real records, or the delegation, at the source, usually by taking over a registrar or DNS-hosting account. The hijacker's answers are "authentic" because they come from the place resolvers are told to trust, and someone holding the registrar account can replace the DNSSEC keys too. Hijacking is stopped by guarding accounts and locking the registration, not by cryptography on the wire.
It helps to sort DNS attacks by what they target. Some aim at the answers themselves, trying to make a resolver believe something false. Some use DNS servers as a weapon against a third party who has nothing to do with DNS. Some attack the servers. Some attack the people and accounts that own the names. And some do not attack DNS at all, but quietly use it as a delivery van. Each kind has a different defender: the resolver operator, the authoritative operator, the network operator, or the domain owner.
| Abuse | What is attacked | Main defense | Who must act | What you see |
|---|---|---|---|---|
| Cache poisoning | A resolver's cache | Random ports and IDs, 0x20, cookies, DNSSEC validation | Resolver operator, zone owner (sign) | Bursts of answers with the wrong ID; validation failures |
| Reflection & amplification | A third party's bandwidth | Source-address validation, closed resolvers, rate limiting, minimal ANY | Network and server operators | Floods of answers to questions nobody asked |
| Random-subdomain flood | Authoritative servers | Anycast capacity, aggressive negative caching, filtering | Authoritative operator | NXDOMAIN rate spikes for one zone |
| Registration hijack | The registrar or DNS-host account | Phishing-resistant MFA, registry lock, NS/DS monitoring | Domain owner | NS or DS records you did not change |
| Dangling records | A forgotten subdomain | An inventory, and deleting DNS before the resource | Domain owner | CNAMEs to names that no longer exist |
| Covert channel | Your firewall's blind spot | Force DNS through monitored resolvers; inspect names | Network defender | Long, random labels under one domain |
| Look-alikes & rebinding | People and browsers | Brand monitoring, IDN display rules, Host checks, private-answer filtering | Domain owner, app and resolver operators | New registrations that resemble yours |
When your resolver asks an authoritative server a question, it sends one UDP packet and waits for one UDP packet back. UDP has no handshake, so the resolver cannot know for sure who sent the reply. It decides whether to believe an answer by checking that the answer matches the question it sent: it must come from the address the question went to, arrive on the port the question left from, carry the same 16-bit transaction ID, and repeat the same question. The ID and the header layout are described in Chapter 2.
Now imagine a forger who is off-path: they cannot see your resolver's traffic, but they can send packets to it with a forged source address. If they know your resolver is about to ask about a name, they can fire off fake answers in the gap between the question leaving and the real answer arriving. Each fake is a lottery ticket: it is accepted only if its ID and destination port both happen to match. If one does, the resolver caches the forgery and hands it to every client that asks until its TTL runs out. The real answer, arriving a moment later, is thrown away as a duplicate.
Until 2008, many resolvers sent every question from the same source port. That left the forger guessing only the ID: 65,536 possibilities. The defense people relied on was the cache itself: once the real answer was cached, there was no question to race against until the TTL expired, so a forger got one chance per TTL. The flaw coordinated in CERT's VU#800113 (July 2008) removed that brake. In concept, a forger who can make the resolver ask about a stream of different, nonexistent names under the target domain gets a fresh race for every name, so the TTL no longer limits the attempts; and a forged answer for one of those names could carry extra records that the resolver would accept for the domain itself. The fix vendors shipped together was simple to describe: randomize the source port as well as the ID, so every guess has to hit both.
A worked example. Take RFC 5452's typical numbers: a 0.1-second window, 2.5 authoritative servers on average, one outstanding question, and a forger sending 7,000 packets a second. With one fixed port the bottom of the fraction is 2.5 × 1 × 65,536 = 163,840 and the top is 7,000 × 0.1 = 700, so each window is a 0.43% chance. If a fresh window can be opened every 0.1 seconds by asking about a new name, 162 windows, about 16 seconds, give better-than-even odds. Spread the questions across 64,000 random ports and the same forger needs 64,000 times as many windows: about 12 days of uninterrupted flooding at a rate an alert operator would notice long before. The calculator below does this arithmetic for any settings you choose.
Bailiwick rules. A resolver should only accept records from a server that is responsible for them. If it asked a server for the example.com zone, an extra record about example.net in the reply is out of bailiwick and must be ignored. RFC 5452 tightens what a resolver may believe from an answer; Chapter 3 follows bailiwick through a full lookup. This limits what a successful forgery can plant, not whether it succeeds.
0x20 case randomization. DNS names are compared without regard to case, but servers copy the question back exactly as they received it. A resolver can therefore randomize the case of each letter (wWw.ExAmPlE.cOm) and insist that the answer repeat it exactly. Each letter adds one bit for the forger to guess. The idea comes from an IETF draft, and resolvers such as Unbound offer it as an option (use-caps-for-id, described there as experimental). It adds nothing for names with few letters, and a few servers do not echo case faithfully, which is why it is not on everywhere.
DNS cookies. RFC 7873 (updated by RFC 9018) lets a client and a server exchange small random values in an EDNS option. The client sends an 8-byte client cookie with each query; a forged answer has to echo it. Once a resolver knows a server supports cookies, an off-path forger has to guess 64 more bits, which ends the race outright. Cookies only help where both sides support them.
DNSSEC. The only defense that does not depend on secrets the forger might guess. If the zone is signed and the resolver validates, a forged answer fails its signature check and is discarded, however perfectly the forger guessed the ID and port. The worst a forger can do is make the lookup fail (SERVFAIL) for a moment. Chapter 11 explains how the chain of signatures works.
Set up a resolver and an imaginary off-path forger. The bar shows how many bits of unpredictability the forger must guess for one forged answer to be accepted; the chart shows the chance that at least one forgery has succeeded after a given amount of time. Two curves: the dashed one is a 1990s resolver with one fixed port; the solid one is your settings. This is pure probability, using RFC 5452's formula: no packets, no tools, nothing sent anywhere.
Probabilities this small are computed with log1p/expm1 so they do not round to zero. "Expected windows" is 1 ÷ chance per window. Simulated numbers; real resolvers also rate-limit, log and alarm on mismatched answers, which this model ignores in the forger's favor.
The second big abuse does not try to fool DNS at all. It uses DNS servers as a megaphone. Three ingredients are needed. First, the attacker's network must let packets out with a forged source address, so a question can carry the victim's address as its return address. Second, there must be servers on the internet that will answer anyone: open resolvers, or authoritative servers, which answer anyone by design. Third, some questions must have answers much bigger than the questions. A 64-byte question that produces a 3,000-byte answer turns each byte the attacker sends into nearly 50 bytes arriving at the victim, from thousands of innocent servers at once. MITRE ATT&CK files this as T1498.002, Reflection Amplification; CISA's TA14-017A lists DNS's bandwidth amplification factor as 28 to 54.
Every ingredient has an owner who can remove it, and that is the shape of the defense:
responses-per-second 10 as a starting point. A truncated reply tells a real client to retry over TCP, which cannot be spoofed in the same way.; a well-run resolver, asked from outside its own network (simulated, documentation address) $ dig @192.0.2.53 example.org A ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 4113 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ; REFUSED, no answer: it will not do recursion for strangers, so it cannot be used as a reflector. ; An open resolver would have returned "status: NOERROR" with "ra" (recursion available) in the flags.
Pick an answer type and a flood size someone might aim at a victim, then switch on defenses one at a time. The calculator works out the amplification factor, how much upload bandwidth the attacker would need, and the most the remaining reflectors could deliver. The sizes and reflector counts are labeled, illustrative numbers chosen to sit inside the range CISA reports, not measurements of any real network.
A cache is a shield for the servers behind it: if a million people ask for www.example.com, the authoritative servers hear about it once per TTL per resolver (Chapter 4). An attacker who wants to hurt those servers therefore asks about names that cannot be cached, because they have never been asked before: k3j9q.example.com, zz81m.example.com, a new random label every time. Each question misses every cache, travels to the zone's authoritative servers, and comes back NXDOMAIN. Operators call it a random-subdomain or "water torture" attack. It is often sent through ordinary resolvers from many infected devices, so the authoritative servers see their own legitimate resolvers misbehaving, and the resolvers in the middle strain too.
The defenses are mostly about capacity and about letting resolvers answer for themselves:
Some of the most damaging DNS attacks of recent years did not touch the protocol. They went after the accounts that control a domain: the registrar account that sets the domain's NS and DS records in the parent zone, and the DNS-hosting account that edits the zone itself. In January 2019 the US Cybersecurity and Infrastructure Security Agency issued Emergency Directive 19-01 after a campaign in which attackers obtained the credentials of accounts that could change DNS records, pointed records such as A, MX and NS at infrastructure they controlled, and, because they now controlled the domain's DNS, obtained valid certificates for it. To users nothing looked wrong. MITRE ATT&CK describes the adversary's side as T1584.002, Compromise Infrastructure: DNS Server.
Why is this so powerful? Delegation is the internet's chain of trust for names (Chapter 1). Whoever can change the NS records for example.com in the .com zone decides which servers every resolver in the world will believe about example.com. DNSSEC does not help here: the same registrar account usually controls the DS record, so a hijacker can publish their own key, or simply remove DS and turn validation off for the zone.
The directive's required actions are a good defender's checklist for any organization:
Two more measures are standard practice. A registry lock, offered by many registries through registrars, refuses changes to NS and DS records unless they are confirmed out of band, often by a phone call between people who know each other, so a stolen password alone is not enough. And continuous monitoring of the delegation: ask the parent zone's servers for your NS and DS records every few minutes and alert on any change.
; a delegation watch, run every 5 minutes (simulated; reserved names) 2026-10-21 09:00Z example.com NS ns1.example.net. ns2.example.net. DS 12345 13 2 … ok 2026-10-21 09:05Z example.com NS ns1.example.net. ns2.example.net. DS 12345 13 2 … ok 2026-10-22 03:14Z example.com NS ns1.imposter.test. ns2.imposter.test. DS (none) ALERT NS set changed and DS removed at the parent. Nobody on the change calendar. Page the domain owner; call the registrar's abuse line; check the registrar account's audit log and active sessions.
Hosting platforms hand out names. Create a website, a storage bucket or an app on many clouds and you get a name inside the provider's domain; to put your own name on it you add a CNAME: shop.example.com CNAME shop-example.storefront.example. Months later the shop closes and someone deletes the platform resource. Nobody deletes the CNAME. It now dangles: your name points at a provider name that nobody owns.
On platforms where names are first come, first served, anyone can now create a resource with that same name, and your shop.example.com serves their content, under your domain, often with a valid certificate. That is a subdomain takeover. It is used for phishing pages that sit on a trusted domain, for stealing cookies scoped to the parent domain, and for damaging reputations. The OWASP Web Security Testing Guide has a test for subdomain takeover that walks through the same reasoning from the tester's side.
The same thing happens with A records that point at cloud IP addresses you have released (the address goes back into the provider's pool and may be handed to another customer), and with NS delegations to a DNS-hosting zone you deleted. The fixes are unglamorous:
; what a dangling CNAME looks like from outside (simulated; reserved names) $ dig promo.example.com A ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51870 ;; ANSWER SECTION: promo.example.com. 300 IN CNAME promo2023.bucket.example.net. ; The CNAME exists in YOUR zone, but its target does not exist any more. ; NXDOMAIN refers to the target. That combination is the signature of a dangling record.
Below is a simulated zone for example.com and a simulated inventory of what the company still holds at its hosting providers. First mark the records you think dangle; then press Run audit. The auditor checks every record against the inventory and scores your guesses. Untick inventory items to decommission them (the way a busy team does, forgetting the DNS) and watch new dangling records appear.
| Dangles? | Record | Audit |
|---|
| Held | Resource |
|---|
Almost every network lets DNS out, because nothing works without it. That makes it attractive to software that needs to talk to the outside without being noticed. The trick is that a question is itself a message: if someone controls the authoritative server for t.example.net, then a lookup for mzxw6ytboi4dcmbqgu2a.t.example.net delivers the encoded string in the first label to that server, through your resolver, without your firewall ever seeing a direct connection. The answer, a TXT record or a set of addresses, carries data back. MITRE ATT&CK lists this as T1071.004, Application Layer Protocol: DNS, used for command and control and for moving data out.
A related technique is the domain generation algorithm (DGA), T1568.002. Instead of a fixed address that defenders could block, malware computes a long list of random-looking domain names each day and tries them; its operator registers only one or two. The infected machine therefore asks about dozens of names that do not exist, which is exactly what makes it visible.
Defenders look for the shapes these channels leave behind:
Here are 120 simulated queries from four machines on a small network, every one labeled with the truth: ordinary traffic (blue circles), a tunnel (magenta triangles) or a DGA (green squares). Each dot is placed by the longest label's length and its entropy. Drag the thresholds, turn the volume and NXDOMAIN rules on and off, and watch the trade between catching the bad traffic and raising false alarms. Real detectors combine dozens of signals; the point is to feel why no single one is enough.
Look-alike names. Not every attack needs to touch your DNS. Registering examp1e.com, example-login.com or example.co is cheap, and a link to one in an email is often enough. Internationalized domain names add homographs: characters from other scripts that look identical to Latin ones, such as Cyrillic "а" for Latin "a". In DNS such a name travels as an ASCII "xn--" string (Punycode, RFC 3492, within the IDNA framework of RFC 5890), but a browser may display it in Unicode. Unicode's Technical Standard #39 defines the "confusable" character data and mixed-script checks browsers use to decide when to show the xn-- form instead. Defenders register the obvious variants of their own names, watch new registrations and certificate logs for look-alikes, and publish strict email authentication (Chapter 8) so a look-alike cannot borrow the real domain's reputation.
Never trust reverse DNS for a decision. A PTR record is published by whoever controls the reverse zone for an address, which means whoever holds the address can make it claim to be trusted.example.com. MITRE's CWE-350, Reliance on Reverse DNS Resolution for a Security-Critical Action, is the formal name for the mistake. Forward-confirmed reverse DNS (look up the PTR, then look up that name and check the address is in its answer) is useful for logging and email reputation, but access control should rest on authentication. Chapter 7 covers PTR records.
DNS rebinding, in one paragraph. A web page is allowed to talk back to the site it came from, judged by the site's name. If a hostile site's name first resolves to its own server and, a moment later, to an address inside your network, scripts on the page may be able to reach a device inside that was never meant to face the internet, such as a router's admin page. The defenses are on both ends. Devices and internal web apps should check the HTTP Host header against the names they expect and require authentication even on the local network. Resolvers can refuse to pass public names that resolve to private addresses: Unbound's private-address option removes such answers and its documentation describes it as protection against DNS rebinding.
NIST's SP 800-81 Revision 3, Secure Domain Name System (DNS) Deployment Guide (March 2026, superseding SP 800-81-2) is the long version. The short version, sorted by who has the power to act:
| If you run… | Do this | Stops |
|---|---|---|
| A recursive resolver | Answer only your own clients; randomize ports and IDs (every current resolver does); validate DNSSEC; enable aggressive NSEC caching; filter private addresses in public answers; log queries | Reflection, poisoning, rebinding; feeds detection |
| Authoritative servers | Response rate limiting; minimal ANY; cap UDP answer size; anycast or a provider that has it; sign the zone; support cookies | Amplification, floods, poisoning of your names |
| A domain | Phishing-resistant MFA on registrar and DNS-host accounts; registry lock; NS/DS monitoring; CT log monitoring; delete DNS before resources; inventory audits | Hijacking, subdomain takeover |
| A network | Source-address validation at the edge (BCP 38); allow DNS out only from your resolvers; watch label length, entropy, volume and NXDOMAIN rates | Spoofing for reflection, covert channels, DGAs |
| An app or device | Check the Host header; authenticate local admin pages; never authorise by reverse DNS | Rebinding, CWE-350 |
RFC 3833, "Threat Analysis of the Domain Name System" (2004), was written to pin down what DNSSEC was supposed to fix. It walks through packet interception, ID guessing and query prediction, name chaining (stuffing extra records into answers), betrayal by a trusted server, and denial of service, and is frank that DNSSEC addresses some and not others. On denial of service it says plainly that DNSSEC does not help, and that because signed answers are longer, DNSSEC-aware servers make even more effective amplifiers. That division of labour is visible across this site: signatures for integrity (Chapter 11), encryption for privacy (Chapter 12), and operational care for everything else.
use-caps-for-id, the 0x20 option; private-address, rebinding protection).responses-per-second 10 example).