Dns Security - Learning Module

Loading content...

0/228

DNS Attacks: Understanding the Threat Landscape

DNS: The Internet's Soft Underbelly

DNS is simultaneously one of the internet's most critical services and one of its most vulnerable. Every connection begins with DNS—making it an extraordinarily valuable attack target. Compromise DNS, and you can redirect users anywhere, steal credentials, distribute malware, or render services completely inaccessible.

The original DNS protocol was designed for reliability and efficiency, not security. It trusts responses without verification, transmits in plaintext, and has limited defense against volumetric attacks. These fundamental weaknesses have spawned an entire category of attacks that security professionals must understand and defend against.

What You Will Learn

By the end of this page, you will understand: (1) Cache poisoning attacks and the Kaminsky vulnerability, (2) DNS amplification attacks for DDoS, (3) DNS hijacking at various levels (local, ISP, registrar, BGP), (4) DNS tunneling for data exfiltration, (5) Typosquatting and homograph attacks, (6) DNS rebinding for internal network attacks, and (7) Resource exhaustion attacks against DNS infrastructure.

Cache Poisoning Attacks

Cache poisoning is one of the most dangerous DNS attacks—it allows an attacker to inject false DNS records into a resolver's cache, affecting all clients using that resolver. Once poisoned, the resolver returns the attacker's IP address for the target domain until the cache entry expires.

How cache poisoning works:

Attacker identifies target domain (e.g., bank.com) and victim resolver
Attacker triggers resolver to query for target domain (if not already cached)
Before the legitimate response arrives, attacker floods resolver with forged responses
If a forged response matches transaction ID/port, resolver accepts and caches it
All subsequent queries for bank.com return attacker's IP until TTL expires

The matching challenge:

For poisoning to succeed, the forged response must match:

Transaction ID (16 bits = 65,536 possibilities)
Source port (resolver's UDP port for the query)
Query name and type
Expected response format

Converting Mermaid diagram...

The Kaminsky Attack (2008):

Dan Kaminsky discovered a devastating cache poisoning technique that dramatically increased attack efficiency:

Traditional poisoning: Attacker must guess transaction ID for queries to the TARGET domain. If wrong, must wait for TTL to expire and try again (could take days).

Kaminsky's insight: Query for RANDOM subdomains (abc123.target.com, def456.target.com) that won't exist. Include a poisoned "additional" record for the parent domain (target.com) in the forged authority section. Each random subdomain is a fresh opportunity—no waiting for TTL expiration.

Attack multiplication:

65,536 transaction IDs × 65,536 possible source ports = ~4.3 billion combinations
Before Kaminsky: Attack might take weeks
After Kaminsky: With random subdomains, can try thousands of queries per second
Modern resolvers with source port randomization: Still a race, but much harder

Mitigations:

Source Port Randomization (SPRS) — Use random UDP source ports (not just fixed 53)
0x20 Encoding — Randomize case in query names (google.COM vs GoOgLe.com)
DNSSEC — Cryptographically validate responses
Response Rate Limiting — Limit responses to suspicious query patterns

Real-World Impact

The 2008 Kaminsky disclosure triggered an unprecedented coordinated patch across all major DNS software vendors simultaneously. The vulnerability was so severe that the disclosure was secretly coordinated before public announcement—one of the largest coordinated vulnerability disclosures in history.

DNS Amplification Attacks

DNS amplification attacks exploit the protocol's asymmetry—small queries generate large responses—to amplify attack traffic for Distributed Denial of Service (DDoS). By spoofing the victim's IP address as the source, attackers can direct massive traffic volumes toward targets.

Attack mechanics:

Attacker identifies open DNS resolvers that accept queries from any source
Attacker spoofs victim's IP address as the query source
Attacker sends small DNS queries designed to generate large responses
Open resolvers send large responses to victim's IP (the spoofed source)
Victim is overwhelmed by response traffic

Amplification factor:

The amplification factor measures how much the traffic is multiplied:

Amplification = Response Size / Query Size

DNS can achieve amplification factors of 50-100x or more:

Query: ~60 bytes (asking for large record)
Response: ~3000-6000 bytes (TXT, ANY, or DNSSEC-signed responses)
Amplification: 50-100x

DNS Query Types for Amplification
Query Type	Typical Response Size	Amplification Factor	Notes
ANY	2000-4000+ bytes	40-70x	Returns all record types; being deprecated (RFC 8482)
TXT (large)	1000-4000 bytes	20-60x	SPF, DKIM, and other large TXT records
DNSSEC (signed zone)	2000-6000 bytes	40-100x	Signatures add significant size
DNSKEY	1000-2000 bytes	20-40x	Zone signing keys can be large (RSA)
NS (with glue)	500-1000 bytes	10-20x	Multiple nameservers with address records
A (simple)	60-100 bytes	1-2x	Minimal amplification; not useful for attack

Scale of amplification attacks:

Real-world DNS amplification attacks have reached staggering scales:

2013 Spamhaus attack: 300 Gbps, one of the largest at the time
2016 OVH attack: 1.1 Tbps from combined DNS + NTP amplification
2018+ attacks: Regularly exceed 1 Tbps using DNS + memcached + other amplifiers

Why DNS is attractive for amplification:

Stateless UDP — No handshake means easy IP spoofing
High amplification — Excellent query:response ratio
Ubiquitous open resolvers — Millions of misconfigured servers
Legitimate traffic — Hard to distinguish attack from real queries
Anycast distribution — Many reflecting sources available globally

Mitigations:

For resolver operators:

Deploy BCP38 (Source Address Validation) — reject spoofed packets
Disable open recursive resolution — only serve configured clients
Implement Response Rate Limiting (RRL)
Block or limit ANY queries (RFC 8482)
Use DNS cookies (RFC 7873)

For potential victims:

DDoS mitigation services (Cloudflare, Akamai, AWS Shield)
Excess bandwidth capacity
Anycast distribution of services
Rate limiting at network edge

amplification-detection.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Detecting DNS Amplification Attack Participation
# Signs your resolver is being abused for amplification:
 
# High volume of ANY queries from diverse sources
$ grep 'query.*ANY' /var/log/named/query.log | wc -l
 
# Large responses to external IPs
$ dnstop -r eth0   # Monitor response sizes
 
# Many queries for same domain from different sources
# (attackers target same amplification-friendly zone)
 
---
 
# Response Rate Limiting (RRL) in BIND
# /etc/named.conf
 
rate-limit {
    responses-per-second 5;      # Max identical responses/sec
    referrals-per-second 5;      # Limit referral responses
    nodata-per-second 5;         # Limit NODATA responses
    nxdomains-per-second 5;      # Limit NXDOMAIN responses
    errors-per-second 5;         # Limit error responses
    window 15;                   # 15-second tracking window
    log-only no;                 # Actually enforce limits
};
 
---
 
# Detecting if you're a victim
# Receiving unsolicited DNS responses
 
$ tcpdump -i eth0 'udp src port 53 and not dst port 53'
 
# Volume of incoming DNS responses >> outgoing queries
# = You're likely being targeted by amplification attack

Check Your Infrastructure

Open resolvers are constantly scanned and abused for amplification. Verify your DNS servers only accept recursive queries from authorized clients. Use 'dig @your-resolver example.com' from an external IP—if it works, you have an open resolver. Tools like Shodan regularly index open resolvers.

DNS Hijacking

DNS hijacking refers to attacks that redirect DNS queries or modify responses to send users to attacker-controlled destinations. Unlike cache poisoning (which targets a single resolver), hijacking can occur at multiple points in the DNS resolution path.

Levels of DNS hijacking:

DNS Hijacking Attack Vectors
Level	Attack Method	Scope	Detection Difficulty
Local/Device	Malware modifies resolv.conf or hosts file	Single device	Easy to detect on inspection
Router/DHCP	Compromise router; serve malicious DNS via DHCP	All network clients	Moderate; requires router audit
ISP Resolver	Compromise or coerce ISP's DNS servers	All ISP customers	Hard to detect; responses look legitimate
Registrar	Compromise registrar account; change NS records	All domain queries globally	Very hard; domain appears hijacked
BGP Hijack	Announce routes to DNS server IPs	All users routing through hijacked path	Detected by BGP monitors; hard to prevent
Root/TLD	Compromise root or TLD servers	Potentially entire TLD	Extremely rare; would be globally detected

Registrar-level hijacking:

One of the most devastating attacks involves compromising domain registrar accounts:

Attacker gains access to registrar control panel (phishing, credential stuffing, social engineering)
Attacker changes domain's NS records to point to attacker-controlled nameservers
TLD servers (e.g., .com) now delegate to attacker's servers
Attacker responds with any records they choose
All DNS queries for the domain now resolve to attacker's servers

Case study: 2019 Sea Turtle campaign

Advanced persistent threat actors hijacked DNS for dozens of organizations across the Middle East and North Africa:

Targeted registrars and DNS providers directly
Modified NS records to inject attacker-controlled nameservers
Intercepted credentials for email, VPNs, and other sensitive services
Obtained legitimate TLS certificates for hijacked domains (via email validation)
Persisted for years before detection

BGP hijacking for DNS:

Attackers can use BGP (internet routing) hijacking to intercept DNS traffic:

Attacker announces BGP routes for DNS server IP prefixes
Internet traffic destined for those IPs routes through attacker
Attacker intercepts queries, returns malicious responses
Attacker may forward legitimate traffic to avoid detection

Notable incident: In 2018, attackers used BGP hijacking to intercept Route 53 DNS traffic, stealing cryptocurrency by redirecting MyEtherWallet.com.

DNS Hijacking Defenses

•DNSSEC — Cryptographic validation detects unauthorized record changes (but requires validator client)
•Registrar security — Enable MFA, registry lock, and monitor NS record changes
•CAA records — Limit which CAs can issue certificates for your domain
•Certificate Transparency — Monitor CT logs for unauthorized certificate issuance
•RPKI/BGPsec — Validate BGP route origins to prevent BGP hijacking
•DNS monitoring — Continuously query your own domain from multiple locations; alert on unexpected changes
•DoH/DoT — Encrypt DNS to prevent local interception (doesn't help against registrar/BGP attacks)

The Nuclear Option

Registrar-level hijacking is particularly dangerous because DNSSEC doesn't fully protect against it—if an attacker controls your registrar account, they can potentially update DS records in the parent zone. Defense requires strong registrar authentication, registry locks, and monitoring. Major domains should use registrar EPP status codes like 'clientTransferProhibited' and 'serverUpdateProhibited'.

DNS Tunneling

DNS tunneling exploits the DNS protocol to smuggle arbitrary data through networks that would otherwise block such traffic. Because DNS is essential for normal operation, it's rarely blocked—even on heavily restricted networks. Attackers use this for data exfiltration, command-and-control (C2) communication, and bypassing captive portals.

How DNS tunneling works:

Attacker controls a domain (e.g., evil.com) and its authoritative nameserver
Client encodes data into DNS query names: dGhpcyBpcyBzZWNyZXQ.data.evil.com
Query travels through network (allowed as "normal" DNS)
Attacker's nameserver receives query, decodes the subdomain data
Response data encoded in TXT, NULL, or other record types
Bidirectional communication channel established via DNS

Converting Mermaid diagram...

Data encoding techniques:

DNS labels (between dots) are limited to 63 characters; total domain name is limited to 253 characters. Tunneling uses various encoding:

Base32/Base64 — Encode binary data in domain-safe characters
Hexadecimal — Simpler but less efficient encoding
Custom encodings — Balance efficiency and detection evasion

Tunneling bandwidth:

DNS tunneling is slow compared to direct connections:

Query: ~200 characters of data (after encoding overhead)
Response: ~4000 bytes in TXT record
Latency: DNS resolution delays for each "packet"
Throughput: Typically 10-100 KB/s

Detection indicators:

Long subdomains — Normal queries rarely have lengthy encoded labels
High query entropy — Encoded data has high randomness
Unusual query volume — Tunnel requires many queries per "connection"
Uncommon record types — TXT, NULL, CNAME queries unusual for normal browsing
Query timing patterns — Regular intervals suggest automated tunneling
Single domain, many queries — Tunnel uses attacker's domain repeatedly

DNS Tunneling Tools and Detection
Tool	Purpose	Detection Strategy
Iodine	IP over DNS tunnel; popular for bypassing captive portals	Look for long labels, NULL record queries, consistent domain
dnscat2	C2 framework using DNS; encrypted bidirectional channel	Detect high entropy labels, unusual query frequency
DNSExfiltrator	Data exfiltration tool; encodes files in queries	Monitor for query bursts to single domain, base64 labels
NSTX	Legacy IP-over-DNS tool	NULL record type queries, tunnel domain patterns
Cobalt Strike DNS Beacon	Commercial red team C2	Detect beacon timing patterns, domain analysis

dns-tunnel-detection.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# DNS Tunneling Detection Techniques
 
# 1. Detect long subdomain labels (>30 chars unusual)
$ grep -E '[a-zA-Z0-9]{30,}\.' /var/log/dns/queries.log
 
# 2. Calculate query entropy
# High entropy suggests encoded data
# Normal: "www.example.com" (low entropy)
# Tunnel: "YXR0YWNrZXJkYXRh.evil.com" (high entropy)
 
import math
def entropy(s):
    freq = {}
    for c in s:
        freq[c] = freq.get(c, 0) + 1
    return -sum((f/len(s)) * math.log2(f/len(s)) for f in freq.values())
 
# Threshold: entropy > 3.5 on subdomain = suspicious
 
# 3. Query frequency to single domain
$ awk '{print $1}' /var/log/dns.log | sort | uniq -c | sort -rn | head
# > 1000 queries to single unknown domain = investigate
 
# 4. TXT record query proportion
$ grep 'TXT' /var/log/dns.log | wc -l
# High TXT ratio compared to A records = tunneling indicator
 
# 5. Deploy DNS analytics tools:
# - Zeek (Bro) with DNS analyzer
# - Packetbeat + Elasticsearch
# - Passive DNS (pDNS) analysis
# - Machine learning classifiers on query patterns

Legitimate Uses Exist

Not all DNS tunneling is malicious. Some legitimate services use DNS-based mechanisms (e.g., Dynamic DNS updates, certain anti-censorship tools). Detection should trigger investigation, not automatic blocking. Focus on identifying unexpected tunneling traffic from internal hosts—this suggests compromise.

Domain-Based Attacks

Beyond protocol-level attacks, DNS enables various domain name-based attacks that exploit human perception and behavior. These attacks don't require compromising DNS infrastructure—they abuse how humans interpret domain names.

Domain-Based Attack Categories

•Typosquatting — Register domains with common typos: gooogle.com, faceboook.com, gogle.com. Catches users who mistype URLs. Often used for phishing, malware distribution, or ad fraud.
•Homograph Attacks — Use lookalike characters from different scripts: аpple.com (Cyrillic 'a') vs apple.com (Latin 'a'). Visually identical in many fonts. Punycode encoding reveals difference: xn--pple-43d.com
•Combosquatting — Register domains combining brand + keyword: apple-support.com, facebook-security.net. Appears semi-legitimate; used for tech support scams, phishing.
•Lookalike Domains — Use similar words or structures: secure-paypal-login.com, mail.google-verify.net. Plays on user expectations of subdomain structure.
•Expired Domain Hijacking — Monitor for expiring domains with existing traffic/links. Register immediately upon expiration. Capture existing visitors, residual trust, and link equity.
•Subdomain Takeover — Find dangling CNAME/NS records pointing to decommissioned services. Register the pointed-to service (e.g., abandoned Heroku app). Control legitimate domain's subdomain.

Homograph attacks in detail:

Internationalized Domain Names (IDN) allow Unicode characters in domain names. This creates security issues when different scripts have similar-looking characters:

Character	Script	Unicode
a	Latin	U+0061
а	Cyrillic	U+0430
ɑ	IPA Extension	U+0251
а	Armenian	U+0561

All these look identical in most fonts! An attacker registers xn--pple-43d.com (displayed as аpple.com with Cyrillic 'a') and creates a convincing Apple phishing site.

Mitigation: Modern browsers display Punycode for mixed-script domains or domains with suspicious character combinations. Firefox, Chrome, and Safari have increasingly strict policies about when to display Unicode domains.

Subdomain takeover example:

Company creates subdomain: app.example.com → CNAME → example.herokuapp.com
Company shuts down Heroku app but doesn't remove CNAME
Attacker creates new Heroku app at example.herokuapp.com
app.example.com now points to attacker's content
Attacker can serve malicious content on company's domain

Domain Attack Defenses
Attack Type	Defense Strategy	Tools/Techniques
Typosquatting	Proactively register common misspellings; monitor for new registrations	dnstwist, URLCrazy, domain monitoring services
Homograph	Browser restrictions on IDN display; user awareness training	IDN policy enforcement, certificate transparency monitoring
Combosquatting	Trademark monitoring; UDRP disputes; brand protection services	Domain monitoring, legal action, takedown services
Subdomain Takeover	Audit DNS records; remove stale CNAMEs; automated scanning	Subjack, tko-subs, regular DNS auditing
Expired Domains	Set up auto-renewal; monitor expiration; registrar locks	Domain management policies, monitoring alerts

Defensive Domain Registration

Large organizations should defensively register common typos, homograph variants, and combosquatting domains for their primary brands. Tools like dnstwist can generate thousands of variations to consider. Some registrars offer brand protection services that automatically register or block suspicious variants.

DNS Rebinding Attacks

DNS rebinding is a clever attack that bypasses same-origin policy protections in browsers, allowing malicious websites to attack internal network resources that should be unreachable from the internet. It exploits the fact that DNS responses can change during a browser session.

The attack concept:

Victim visits attacker's site: evil.com
Browser resolves evil.com → attacker's server (203.0.113.1)
Page loads with JavaScript that waits for DNS cache to expire
Attacker's DNS server changes evil.com → internal IP (192.168.1.1)
JavaScript makes request to evil.com (now 192.168.1.1)
Browser considers this same-origin (still evil.com)
JavaScript can read responses from internal device!

Converting Mermaid diagram...

Why this works:

The browser's same-origin policy is based on protocol, host, and port (e.g., https://evil.com:443). It doesn't consider IP address. When evil.com rebinds to an internal IP, the browser still considers requests to evil.com as same-origin—even though the IP changed.

Attack targets:

Router admin interfaces — Change DNS settings, enable remote administration
IoT devices — Smart home devices often lack authentication
Internal web applications — Access supposedly "internal-only" tools
Localhost services — Development servers, Docker dashboards, databases
Cloud metadata services — 169.254.169.254 for AWS/GCP instance credentials

Advanced techniques:

Multiple A records: Return both external and internal IPs; browser may try both
Short TTL racing: Near-zero TTL forces constant re-resolution
CNAME switching: Point to controlled subdomain that rebinds
Time-of-check attacks: Rebind during in-flight requests

Defenses:

DNS Rebinding Mitigations

•DNS rebinding protection in resolvers — Block private IPs in DNS responses for public domains. Available in dnsmasq, Pi-hole, pfSense.
•Browser DNS pinning — Browsers cache DNS longer than TTL suggests. Chrome pins for 60 seconds minimum. Not reliable defense.
•Host header validation — Internal services should reject requests with unexpected Host headers (evil.com instead of 192.168.1.1).
•Authentication everywhere — Internal services shouldn't rely on network location for security; require authentication.
•CORS properly configured — Internal APIs should validate Origin headers and use restrictive CORS.
•Disable unnecessary services — Local development servers and admin interfaces that aren't needed should be disabled.

Modern Relevance

DNS rebinding from ~2007 has seen renewed interest with IoT devices and cloud metadata services. The 2018 disclosure that rebinding could steal cloud credentials (AWS/GCP metadata endpoint attack) made it relevant again. Many IoT devices now implement Host header checking specifically to prevent rebinding.

Infrastructure and Availability Attacks

Beyond manipulation attacks, DNS infrastructure faces availability attacks designed to disrupt service. Given DNS's critical role, even temporary unavailability can have widespread impact.

Resource exhaustion attacks:

DNS Infrastructure Attack Types
Attack	Target	Mechanism	Impact
NXDOMAIN flood	Resolver	Query millions of non-existent domains	Exhaust resolver cache/CPU; slow legitimate queries
Random subdomain attack	Authoritative + Resolver	Query random.random.random.victim.com	Bypass caching; overload authoritative server
TCP SYN flood	DNS server	Standard SYN flood on port 53	Exhaust connection table; block TCP DNS
Reflection/Amplification	Victim (not DNS)	DNS is the weapon, not target	Overwhelm victim with reflected DNS responses
Zone transfer abuse	Authoritative	Request zone transfers (AXFR) repeatedly	Exhaust bandwidth/CPU; may expose zone data
Malformed query flood	DNS servers	Send queries that trigger parsing errors	CPU exhaustion processing invalid packets

Random subdomain attack (water torture):

This sophisticated attack combines resolver and authoritative server exhaustion:

Attacker generates queries for: abc123.victim.com, def456.victim.com, etc.
Each random subdomain is a cache miss (can't be cached in advance)
Resolver must query authoritative server for every request
Authoritative server is overwhelmed by query volume
Resolver's pending query slots fill up
Legitimate queries for victim.com are delayed or dropped

Why it's effective:

Random subdomains defeat caching
Resolver contributes its resources to attacking authoritative server
Both resolver and authoritative server are impacted
Traffic looks legitimate (valid DNS queries)

DDoS attacks against DNS providers:

Major DNS providers have become DDoS targets:

2016 Dyn attack: Mirai botnet attack took down Dyn DNS, affecting Twitter, Netflix, GitHub, etc.
2019 AWS Route 53: Brief availability issues from DDoS attack
Regular attacks: Authoritative DNS for major domains faces constant attack pressure

Defense strategies:

DNS Availability Protection

•Anycast deployment — Multiple geographically distributed servers share same IP address; attack traffic distributed; local failures don't cause global outage.
•Overprovisioning — Maintain capacity far exceeding normal load; absorb attack traffic.
•Rate limiting — Limit queries per source IP; implement Response Rate Limiting (RRL).
•Multiple authoritative providers — Use multiple NS records pointing to different providers; redundancy at provider level.
•DDoS mitigation services — Cloudflare, AWS Shield, Akamai Prolexic can scrub attack traffic.
•DNS cookies — RFC 7873 cookies prevent IP spoofing; reduces amplification attack surface.
•Aggressive NSEC caching — RFC 8198 allows caching proof of non-existence; reduces random subdomain attack impact.

The 2016 Dyn Attack Lesson

The Mirai botnet attack against Dyn DNS demonstrated single-provider risk. Major websites using only Dyn became unreachable when Dyn was attacked. Best practice now recommends multiple DNS providers (e.g., both Route 53 and Cloudflare) so that attack on one doesn't cause complete outage.

Summary: DNS Attack Landscape

DNS faces threats across multiple dimensions—from protocol-level attacks exploiting cryptographic weaknesses to human-perception attacks using lookalike domains. Understanding this landscape is essential for implementing effective defenses.

Let's consolidate the key attack categories:

Key Takeaways

•Cache poisoning injects false records — The Kaminsky attack showed how devastating this could be; DNSSEC and source port randomization are primary defenses.
•Amplification turns DNS into a DDoS weapon — Small queries generate large responses; open resolvers must be eliminated; BCP38 source validation is critical.
•Hijacking can occur at many levels — From local malware to BGP attacks, each level requires different defenses; DNSSEC helps but isn't complete.
•Tunneling exfiltrates data through DNS — High-entropy queries, unusual record types, and excessive query volumes are detection indicators.
•Domain-based attacks exploit human perception — Typosquatting, homographs, and combosquatting require proactive domain registration and monitoring.
•DNS rebinding bypasses same-origin policy — Internal services need Host header validation and proper authentication; resolvers should block private IP responses.
•Infrastructure attacks target availability — Distributed deployment, multiple providers, and DDoS mitigation are essential for critical DNS.

What's next:

Now that we understand DNS attack vectors, the final page brings everything together with comprehensive DNS security measures—a practical guide to implementing defense-in-depth for DNS infrastructure. We'll cover monitoring, hardening, incident response, and security architecture for DNS at various scales.

Page Complete

You now understand the major DNS attack categories: cache poisoning, amplification, hijacking, tunneling, domain-based attacks, rebinding, and infrastructure attacks. This threat awareness is essential for appreciating why the security measures covered in this module exist. Next, we'll synthesize defenses into a comprehensive security framework.

DNS Attacks: Understanding the Threat Landscape

DNS: The Internet's Soft Underbelly

What You Will Learn

Cache Poisoning Attacks

How cache poisoning works:

Attacker identifies target domain (e.g., bank.com) and victim resolver
Attacker triggers resolver to query for target domain (if not already cached)
Before the legitimate response arrives, attacker floods resolver with forged responses
If a forged response matches transaction ID/port, resolver accepts and caches it
All subsequent queries for bank.com return attacker's IP until TTL expires

The matching challenge:

For poisoning to succeed, the forged response must match:

Transaction ID (16 bits = 65,536 possibilities)
Source port (resolver's UDP port for the query)
Query name and type
Expected response format

Converting Mermaid diagram...

The Kaminsky Attack (2008):

Dan Kaminsky discovered a devastating cache poisoning technique that dramatically increased attack efficiency:

Traditional poisoning: Attacker must guess transaction ID for queries to the TARGET domain. If wrong, must wait for TTL to expire and try again (could take days).

Attack multiplication:

65,536 transaction IDs × 65,536 possible source ports = ~4.3 billion combinations
Before Kaminsky: Attack might take weeks
After Kaminsky: With random subdomains, can try thousands of queries per second
Modern resolvers with source port randomization: Still a race, but much harder

Mitigations:

Source Port Randomization (SPRS) — Use random UDP source ports (not just fixed 53)
0x20 Encoding — Randomize case in query names (google.COM vs GoOgLe.com)
DNSSEC — Cryptographically validate responses
Response Rate Limiting — Limit responses to suspicious query patterns

Real-World Impact

DNS Amplification Attacks

Attack mechanics:

Attacker identifies open DNS resolvers that accept queries from any source
Attacker spoofs victim's IP address as the query source
Attacker sends small DNS queries designed to generate large responses
Open resolvers send large responses to victim's IP (the spoofed source)
Victim is overwhelmed by response traffic

Amplification factor:

The amplification factor measures how much the traffic is multiplied:

Amplification = Response Size / Query Size

DNS can achieve amplification factors of 50-100x or more:

Query: ~60 bytes (asking for large record)
Response: ~3000-6000 bytes (TXT, ANY, or DNSSEC-signed responses)
Amplification: 50-100x

DNS Query Types for Amplification
Query Type	Typical Response Size	Amplification Factor	Notes
ANY	2000-4000+ bytes	40-70x	Returns all record types; being deprecated (RFC 8482)
TXT (large)	1000-4000 bytes	20-60x	SPF, DKIM, and other large TXT records
DNSSEC (signed zone)	2000-6000 bytes	40-100x	Signatures add significant size
DNSKEY	1000-2000 bytes	20-40x	Zone signing keys can be large (RSA)
NS (with glue)	500-1000 bytes	10-20x	Multiple nameservers with address records
A (simple)	60-100 bytes	1-2x	Minimal amplification; not useful for attack

Scale of amplification attacks:

Real-world DNS amplification attacks have reached staggering scales:

2013 Spamhaus attack: 300 Gbps, one of the largest at the time
2016 OVH attack: 1.1 Tbps from combined DNS + NTP amplification
2018+ attacks: Regularly exceed 1 Tbps using DNS + memcached + other amplifiers

Why DNS is attractive for amplification:

Stateless UDP — No handshake means easy IP spoofing
High amplification — Excellent query:response ratio
Ubiquitous open resolvers — Millions of misconfigured servers
Legitimate traffic — Hard to distinguish attack from real queries
Anycast distribution — Many reflecting sources available globally

Mitigations:

For resolver operators:

Deploy BCP38 (Source Address Validation) — reject spoofed packets
Disable open recursive resolution — only serve configured clients
Implement Response Rate Limiting (RRL)
Block or limit ANY queries (RFC 8482)
Use DNS cookies (RFC 7873)

For potential victims:

DDoS mitigation services (Cloudflare, Akamai, AWS Shield)
Excess bandwidth capacity
Anycast distribution of services
Rate limiting at network edge

amplification-detection.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Detecting DNS Amplification Attack Participation
# Signs your resolver is being abused for amplification:
 
# High volume of ANY queries from diverse sources
$ grep 'query.*ANY' /var/log/named/query.log | wc -l
 
# Large responses to external IPs
$ dnstop -r eth0   # Monitor response sizes
 
# Many queries for same domain from different sources
# (attackers target same amplification-friendly zone)
 
---
 
# Response Rate Limiting (RRL) in BIND
# /etc/named.conf
 
rate-limit {
    responses-per-second 5;      # Max identical responses/sec
    referrals-per-second 5;      # Limit referral responses
    nodata-per-second 5;         # Limit NODATA responses
    nxdomains-per-second 5;      # Limit NXDOMAIN responses
    errors-per-second 5;         # Limit error responses
    window 15;                   # 15-second tracking window
    log-only no;                 # Actually enforce limits
};
 
---
 
# Detecting if you're a victim
# Receiving unsolicited DNS responses
 
$ tcpdump -i eth0 'udp src port 53 and not dst port 53'
 
# Volume of incoming DNS responses >> outgoing queries
# = You're likely being targeted by amplification attack

Check Your Infrastructure

DNS Hijacking

Levels of DNS hijacking:

DNS Hijacking Attack Vectors
Level	Attack Method	Scope	Detection Difficulty
Local/Device	Malware modifies resolv.conf or hosts file	Single device	Easy to detect on inspection
Router/DHCP	Compromise router; serve malicious DNS via DHCP	All network clients	Moderate; requires router audit
ISP Resolver	Compromise or coerce ISP's DNS servers	All ISP customers	Hard to detect; responses look legitimate
Registrar	Compromise registrar account; change NS records	All domain queries globally	Very hard; domain appears hijacked
BGP Hijack	Announce routes to DNS server IPs	All users routing through hijacked path	Detected by BGP monitors; hard to prevent
Root/TLD	Compromise root or TLD servers	Potentially entire TLD	Extremely rare; would be globally detected

Registrar-level hijacking:

One of the most devastating attacks involves compromising domain registrar accounts:

Attacker gains access to registrar control panel (phishing, credential stuffing, social engineering)
Attacker changes domain's NS records to point to attacker-controlled nameservers
TLD servers (e.g., .com) now delegate to attacker's servers
Attacker responds with any records they choose
All DNS queries for the domain now resolve to attacker's servers

Case study: 2019 Sea Turtle campaign

Advanced persistent threat actors hijacked DNS for dozens of organizations across the Middle East and North Africa:

Targeted registrars and DNS providers directly
Modified NS records to inject attacker-controlled nameservers
Intercepted credentials for email, VPNs, and other sensitive services
Obtained legitimate TLS certificates for hijacked domains (via email validation)
Persisted for years before detection

BGP hijacking for DNS:

Attackers can use BGP (internet routing) hijacking to intercept DNS traffic:

Attacker announces BGP routes for DNS server IP prefixes
Internet traffic destined for those IPs routes through attacker
Attacker intercepts queries, returns malicious responses
Attacker may forward legitimate traffic to avoid detection

Notable incident: In 2018, attackers used BGP hijacking to intercept Route 53 DNS traffic, stealing cryptocurrency by redirecting MyEtherWallet.com.

DNS Hijacking Defenses

•DNSSEC — Cryptographic validation detects unauthorized record changes (but requires validator client)
•Registrar security — Enable MFA, registry lock, and monitor NS record changes
•CAA records — Limit which CAs can issue certificates for your domain
•Certificate Transparency — Monitor CT logs for unauthorized certificate issuance
•RPKI/BGPsec — Validate BGP route origins to prevent BGP hijacking
•DNS monitoring — Continuously query your own domain from multiple locations; alert on unexpected changes
•DoH/DoT — Encrypt DNS to prevent local interception (doesn't help against registrar/BGP attacks)

The Nuclear Option

DNS Tunneling

How DNS tunneling works:

Attacker controls a domain (e.g., evil.com) and its authoritative nameserver
Client encodes data into DNS query names: dGhpcyBpcyBzZWNyZXQ.data.evil.com
Query travels through network (allowed as "normal" DNS)
Attacker's nameserver receives query, decodes the subdomain data
Response data encoded in TXT, NULL, or other record types
Bidirectional communication channel established via DNS

Converting Mermaid diagram...

Data encoding techniques:

DNS labels (between dots) are limited to 63 characters; total domain name is limited to 253 characters. Tunneling uses various encoding:

Base32/Base64 — Encode binary data in domain-safe characters
Hexadecimal — Simpler but less efficient encoding
Custom encodings — Balance efficiency and detection evasion

Tunneling bandwidth:

DNS tunneling is slow compared to direct connections:

Query: ~200 characters of data (after encoding overhead)
Response: ~4000 bytes in TXT record
Latency: DNS resolution delays for each "packet"
Throughput: Typically 10-100 KB/s

Detection indicators:

Long subdomains — Normal queries rarely have lengthy encoded labels
High query entropy — Encoded data has high randomness
Unusual query volume — Tunnel requires many queries per "connection"
Uncommon record types — TXT, NULL, CNAME queries unusual for normal browsing
Query timing patterns — Regular intervals suggest automated tunneling
Single domain, many queries — Tunnel uses attacker's domain repeatedly

DNS Tunneling Tools and Detection
Tool	Purpose	Detection Strategy
Iodine	IP over DNS tunnel; popular for bypassing captive portals	Look for long labels, NULL record queries, consistent domain
dnscat2	C2 framework using DNS; encrypted bidirectional channel	Detect high entropy labels, unusual query frequency
DNSExfiltrator	Data exfiltration tool; encodes files in queries	Monitor for query bursts to single domain, base64 labels
NSTX	Legacy IP-over-DNS tool	NULL record type queries, tunnel domain patterns
Cobalt Strike DNS Beacon	Commercial red team C2	Detect beacon timing patterns, domain analysis

dns-tunnel-detection.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# DNS Tunneling Detection Techniques
 
# 1. Detect long subdomain labels (>30 chars unusual)
$ grep -E '[a-zA-Z0-9]{30,}\.' /var/log/dns/queries.log
 
# 2. Calculate query entropy
# High entropy suggests encoded data
# Normal: "www.example.com" (low entropy)
# Tunnel: "YXR0YWNrZXJkYXRh.evil.com" (high entropy)
 
import math
def entropy(s):
    freq = {}
    for c in s:
        freq[c] = freq.get(c, 0) + 1
    return -sum((f/len(s)) * math.log2(f/len(s)) for f in freq.values())
 
# Threshold: entropy > 3.5 on subdomain = suspicious
 
# 3. Query frequency to single domain
$ awk '{print $1}' /var/log/dns.log | sort | uniq -c | sort -rn | head
# > 1000 queries to single unknown domain = investigate
 
# 4. TXT record query proportion
$ grep 'TXT' /var/log/dns.log | wc -l
# High TXT ratio compared to A records = tunneling indicator
 
# 5. Deploy DNS analytics tools:
# - Zeek (Bro) with DNS analyzer
# - Packetbeat + Elasticsearch
# - Passive DNS (pDNS) analysis
# - Machine learning classifiers on query patterns

Legitimate Uses Exist

Domain-Based Attacks

Domain-Based Attack Categories

•Typosquatting — Register domains with common typos: gooogle.com, faceboook.com, gogle.com. Catches users who mistype URLs. Often used for phishing, malware distribution, or ad fraud.
•Homograph Attacks — Use lookalike characters from different scripts: аpple.com (Cyrillic 'a') vs apple.com (Latin 'a'). Visually identical in many fonts. Punycode encoding reveals difference: xn--pple-43d.com
•Combosquatting — Register domains combining brand + keyword: apple-support.com, facebook-security.net. Appears semi-legitimate; used for tech support scams, phishing.
•Lookalike Domains — Use similar words or structures: secure-paypal-login.com, mail.google-verify.net. Plays on user expectations of subdomain structure.
•Expired Domain Hijacking — Monitor for expiring domains with existing traffic/links. Register immediately upon expiration. Capture existing visitors, residual trust, and link equity.
•Subdomain Takeover — Find dangling CNAME/NS records pointing to decommissioned services. Register the pointed-to service (e.g., abandoned Heroku app). Control legitimate domain's subdomain.

Homograph attacks in detail:

Internationalized Domain Names (IDN) allow Unicode characters in domain names. This creates security issues when different scripts have similar-looking characters:

Character	Script	Unicode
a	Latin	U+0061
а	Cyrillic	U+0430
ɑ	IPA Extension	U+0251
а	Armenian	U+0561

All these look identical in most fonts! An attacker registers xn--pple-43d.com (displayed as аpple.com with Cyrillic 'a') and creates a convincing Apple phishing site.

Subdomain takeover example:

Company creates subdomain: app.example.com → CNAME → example.herokuapp.com
Company shuts down Heroku app but doesn't remove CNAME
Attacker creates new Heroku app at example.herokuapp.com
app.example.com now points to attacker's content
Attacker can serve malicious content on company's domain

Domain Attack Defenses
Attack Type	Defense Strategy	Tools/Techniques
Typosquatting	Proactively register common misspellings; monitor for new registrations	dnstwist, URLCrazy, domain monitoring services
Homograph	Browser restrictions on IDN display; user awareness training	IDN policy enforcement, certificate transparency monitoring
Combosquatting	Trademark monitoring; UDRP disputes; brand protection services	Domain monitoring, legal action, takedown services
Subdomain Takeover	Audit DNS records; remove stale CNAMEs; automated scanning	Subjack, tko-subs, regular DNS auditing
Expired Domains	Set up auto-renewal; monitor expiration; registrar locks	Domain management policies, monitoring alerts

Defensive Domain Registration

DNS Rebinding Attacks

The attack concept:

Victim visits attacker's site: evil.com
Browser resolves evil.com → attacker's server (203.0.113.1)
Page loads with JavaScript that waits for DNS cache to expire
Attacker's DNS server changes evil.com → internal IP (192.168.1.1)
JavaScript makes request to evil.com (now 192.168.1.1)
Browser considers this same-origin (still evil.com)
JavaScript can read responses from internal device!

Converting Mermaid diagram...

Why this works:

Attack targets:

Router admin interfaces — Change DNS settings, enable remote administration
IoT devices — Smart home devices often lack authentication
Internal web applications — Access supposedly "internal-only" tools
Localhost services — Development servers, Docker dashboards, databases
Cloud metadata services — 169.254.169.254 for AWS/GCP instance credentials

Advanced techniques:

Multiple A records: Return both external and internal IPs; browser may try both
Short TTL racing: Near-zero TTL forces constant re-resolution
CNAME switching: Point to controlled subdomain that rebinds
Time-of-check attacks: Rebind during in-flight requests

Defenses:

DNS Rebinding Mitigations

•DNS rebinding protection in resolvers — Block private IPs in DNS responses for public domains. Available in dnsmasq, Pi-hole, pfSense.
•Browser DNS pinning — Browsers cache DNS longer than TTL suggests. Chrome pins for 60 seconds minimum. Not reliable defense.
•Host header validation — Internal services should reject requests with unexpected Host headers (evil.com instead of 192.168.1.1).
•Authentication everywhere — Internal services shouldn't rely on network location for security; require authentication.
•CORS properly configured — Internal APIs should validate Origin headers and use restrictive CORS.
•Disable unnecessary services — Local development servers and admin interfaces that aren't needed should be disabled.

Modern Relevance

Infrastructure and Availability Attacks

Beyond manipulation attacks, DNS infrastructure faces availability attacks designed to disrupt service. Given DNS's critical role, even temporary unavailability can have widespread impact.

Resource exhaustion attacks:

DNS Infrastructure Attack Types
Attack	Target	Mechanism	Impact
NXDOMAIN flood	Resolver	Query millions of non-existent domains	Exhaust resolver cache/CPU; slow legitimate queries
Random subdomain attack	Authoritative + Resolver	Query random.random.random.victim.com	Bypass caching; overload authoritative server
TCP SYN flood	DNS server	Standard SYN flood on port 53	Exhaust connection table; block TCP DNS
Reflection/Amplification	Victim (not DNS)	DNS is the weapon, not target	Overwhelm victim with reflected DNS responses
Zone transfer abuse	Authoritative	Request zone transfers (AXFR) repeatedly	Exhaust bandwidth/CPU; may expose zone data
Malformed query flood	DNS servers	Send queries that trigger parsing errors	CPU exhaustion processing invalid packets

Random subdomain attack (water torture):

This sophisticated attack combines resolver and authoritative server exhaustion:

Attacker generates queries for: abc123.victim.com, def456.victim.com, etc.
Each random subdomain is a cache miss (can't be cached in advance)
Resolver must query authoritative server for every request
Authoritative server is overwhelmed by query volume
Resolver's pending query slots fill up
Legitimate queries for victim.com are delayed or dropped

Why it's effective:

Random subdomains defeat caching
Resolver contributes its resources to attacking authoritative server
Both resolver and authoritative server are impacted
Traffic looks legitimate (valid DNS queries)

DDoS attacks against DNS providers:

Major DNS providers have become DDoS targets:

2016 Dyn attack: Mirai botnet attack took down Dyn DNS, affecting Twitter, Netflix, GitHub, etc.
2019 AWS Route 53: Brief availability issues from DDoS attack
Regular attacks: Authoritative DNS for major domains faces constant attack pressure

Defense strategies:

DNS Availability Protection

•Anycast deployment — Multiple geographically distributed servers share same IP address; attack traffic distributed; local failures don't cause global outage.
•Overprovisioning — Maintain capacity far exceeding normal load; absorb attack traffic.
•Rate limiting — Limit queries per source IP; implement Response Rate Limiting (RRL).
•Multiple authoritative providers — Use multiple NS records pointing to different providers; redundancy at provider level.
•DDoS mitigation services — Cloudflare, AWS Shield, Akamai Prolexic can scrub attack traffic.
•DNS cookies — RFC 7873 cookies prevent IP spoofing; reduces amplification attack surface.
•Aggressive NSEC caching — RFC 8198 allows caching proof of non-existence; reduces random subdomain attack impact.

The 2016 Dyn Attack Lesson

Summary: DNS Attack Landscape

Let's consolidate the key attack categories:

Key Takeaways

•Cache poisoning injects false records — The Kaminsky attack showed how devastating this could be; DNSSEC and source port randomization are primary defenses.
•Amplification turns DNS into a DDoS weapon — Small queries generate large responses; open resolvers must be eliminated; BCP38 source validation is critical.
•Hijacking can occur at many levels — From local malware to BGP attacks, each level requires different defenses; DNSSEC helps but isn't complete.
•Tunneling exfiltrates data through DNS — High-entropy queries, unusual record types, and excessive query volumes are detection indicators.
•Domain-based attacks exploit human perception — Typosquatting, homographs, and combosquatting require proactive domain registration and monitoring.
•DNS rebinding bypasses same-origin policy — Internal services need Host header validation and proper authentication; resolvers should block private IP responses.
•Infrastructure attacks target availability — Distributed deployment, multiple providers, and DDoS mitigation are essential for critical DNS.

What's next:

Page Complete