1. Why DNS Is a High-Value Target¶

DNS sits in front of essentially every internet interaction — before a browser, an API client, or a mail server can do anything, it resolves a name. This gives an attacker who can manipulate DNS an unusually powerful position: redirect resolution and you can intercept traffic, serve malware, or take a service offline, all without touching the target's actual infrastructure. Combine that leverage with DNS's historical design (UDP-based, largely unauthenticated by default, chatty, and often left in permissive default configurations) and it's consistently one of the most attacked layers of internet infrastructure.

2. Cache Poisoning / Spoofing¶

What it is: injecting a forged DNS response into a resolver's cache so it returns attacker-controlled data (typically a malicious IP) for a legitimate name, for as long as the poisoned TTL lasts.

How it works (classically): DNS queries over UDP have no built-in authentication — a resolver accepts the first response that matches the query's transaction ID, source/destination ports, and question. An off-path attacker (the classic Kaminsky attack, disclosed 2008) floods a resolver with forged responses for a name it's about to query, racing the real authoritative server's genuine reply. If the attacker's forged packet arrives first and its guessed transaction ID/port happens to match, the resolver caches the forged answer — and every client using that resolver gets the poisoned result until the TTL expires.

Mitigations: - Source port randomization — makes the port an attacker must guess unpredictable, hugely increasing the number of forged packets needed for a successful race (this became a standard mitigation after Kaminsky's disclosure, and is table-stakes in any modern resolver). - 0x20 encoding — randomizing the case of letters in the query name as extra, resolver-side-verifiable entropy the forger must also match. - DNSSEC — the structural fix; a validating resolver rejects any response, forged or not, that doesn't carry a valid signature chain (see the dedicated DNSSEC guide).

3. DNS Amplification / Reflection (DDoS)¶

What it is: using DNS servers as unwitting force-multipliers in a Distributed Denial of Service attack against a third party.

How it works: the attacker sends a DNS query to an open (publicly reachable, recursion-enabled) resolver with the source IP address spoofed to the victim's address. The resolver, having no way to know the source address was forged, sends its response — which can be many times larger than the query, especially with EDNS0 and DNSSEC records inflating response size — to the victim. Coordinating this across many open resolvers simultaneously turns a modest amount of attacker-controlled outbound bandwidth into a much larger flood aimed at the victim (amplification factors of 50x or more are well documented for certain query types against certain servers).

Mitigations: - Restrict recursion (allow-recursion in BIND, access-control in Unbound, interface binding in dnsmasq) to known, trusted clients — an authoritative-only or intentionally-scoped resolver should never answer recursive queries from arbitrary internet addresses. - Response Rate Limiting (RRL) — a server-side feature (present in BIND, PowerDNS, and others) that throttles repeated identical responses to the same apparent source, blunting the amplification even if the server is somehow still reachable. - BCP38 (source address validation) at the network operator level — filtering outbound traffic with spoofed source addresses at the network edge, which prevents this and many other reflection attacks at the root cause rather than the DNS-server-specific mitigations above; this is a network-operator responsibility, referenced directly in the RHEL BIND default config's own comments.

4. DDoS Against Authoritative Infrastructure Directly¶

Distinct from using DNS to amplify an attack elsewhere: attacking the DNS servers themselves so a target's domain becomes unresolvable, taking down every service under that domain without touching any of those services directly. The 2016 Dyn/Mirai attack is the reference case — a botnet-driven volumetric attack against a major managed DNS provider caused widespread outages for the provider's customers (Twitter, Reddit, Spotify, and others), none of whose own infrastructure was directly attacked at all.

Mitigations: - Anycast — distributing authoritative service across many geographically/topologically diverse endpoints sharing one advertised IP, so an attack against "the server" is diffused across many physical machines and networks rather than concentrated on one. - Multiple, diverse providers — running authoritative service across two genuinely independent providers (different networks, different anycast fabrics) so a single provider's outage — attack-driven or otherwise — doesn't take the domain fully offline. - Hidden primary architecture (see the zone-delegation guide, §7) — keeping the actual editable master server off the public delegation entirely, so it can't be targeted directly; only replaceable public secondaries absorb attack traffic.

5. DNS Hijacking / Domain Hijacking¶

What it is: an attacker gains the ability to change what a domain's DNS actually points to — not by attacking the DNS protocol, but by compromising the account or credentials that control the zone (registrar account takeover, a compromised API key for a cloud DNS provider, social engineering a registrar's support staff).

Real-world pattern: once an attacker controls DNS for a domain, they can point mail (MX) records to their own infrastructure to intercept password resets, point the web A record at a phishing clone, or issue TLS certificates for the domain via automated CA validation (which typically relies on DNS or HTTP control as proof of ownership) — DNS control is often equivalent to full domain control for practical purposes.

Mitigations: - Registrar/DNS-provider account hardening — MFA, registrar locks (preventing unauthorized transfers), restricted API key scopes. - CAA records restricting which Certificate Authorities may issue certificates for a domain, limiting (though not eliminating) an attacker's ability to get a trusted cert once they do gain DNS control. - Monitoring/alerting on unexpected zone changes — the same discipline octoDNS's plan/apply workflow encourages (every change reviewable and diffable) also functions as a detection mechanism, since an unauthorized change shows up as an unexpected diff.

6. NXDOMAIN / Water Torture Attacks (Random Subdomain Attacks)¶

What it is: flooding an authoritative (or recursive) server with queries for randomly generated, non-existent subdomains of a real target domain (x7f2q9.example.com, k2n8pz.example.com, ...). Because these names don't exist and aren't cacheable in any useful way (each is unique), every query forces genuine work — the target's authoritative servers must process each one, and any resolver in the middle can't shield the target with caching since there's nothing repeatable to cache.

Effect: this can exhaust an authoritative server's query-processing capacity even at comparatively modest query volumes, and — because the queries often originate from a botnet of compromised recursive resolvers/open resolvers relaying the random-name queries — it can be difficult to filter by simple source-IP blocking.

Mitigations: - Response Rate Limiting, again, is effective here specifically because NXDOMAIN responses to the same source pattern can be throttled. - Aggressive negative caching (RFC 8198) at the resolver layer, which uses NSEC/NSEC3 range proofs from DNSSEC to let a resolver determine a name doesn't exist without forwarding every individual random query upstream — a direct DNSSEC side-benefit against exactly this attack pattern. - Provisioning/capacity headroom and anycast distribution, as with any volumetric attack.

7. Typosquatting and Homograph Attacks¶

Not an attack on the DNS protocol at all, but on DNS naming — registering a domain deliberately similar to a legitimate one (exarnple.com, or using Unicode homoglyphs that render visually identical to Latin characters, e.g. a Cyrillic "а" in place of a Latin "a" — an IDN homograph attack) to trick users or automated systems into resolving the wrong, attacker-controlled name entirely legitimately, through totally correct DNS resolution of a name that just isn't the one the user thought they were looking at.

Mitigations: largely outside DNS infrastructure itself — browser/registry-level restrictions on mixed-script domain names, brand monitoring for lookalike registrations, and user-facing certificate/URL display improvements; DNSSEC and server hardening don't address this category at all, since the forged domain resolves entirely correctly on its own terms.

8. DNS Tunneling¶

What it is: abusing DNS as a covert data channel — encoding arbitrary data (command-and-control traffic, exfiltrated data) into DNS query names and response records, since DNS traffic is almost universally permitted outbound through firewalls that would block most other protocols.

Detection signals: unusually long or high-entropy subdomain labels, abnormally high query volume to a small number of unusual domains, TXT/NULL record types used far more than expected for legitimate traffic, and query patterns with no corresponding legitimate application behavior.

Mitigations: DNS-aware firewalls/IDS with tunneling-detection signatures, restricting which record types and destinations are allowed to resolve at all from sensitive network segments, and general egress monitoring — this is fundamentally a network-security/monitoring problem more than a DNS-server-configuration one.

9. Summary Table¶

10. Reference Links¶

• Kaminsky attack overview: https://en.wikipedia.org/wiki/DNS_spoofing
• RFC 8198 (Aggressive Use of DNSSEC-Validated Cache)
• US-CERT/CISA advisories on DNS infrastructure hijacking campaigns: https://www.cisa.gov/