DNS Security

DNS Hijacking

DNS hijacking redirects legitimate DNS queries to attacker-controlled responses, sending users to malicious servers while the legitimate URL appears in the browser bar. Multiple attack vectors exist at different points in the DNS resolution chain.

• BGP hijacking: Announcing fraudulent BGP routes to intercept traffic at the routing level, affecting DNS resolution for entire IP blocks
• Registrar compromise: Attacking domain registrar accounts (via credential theft, social engineering) to change authoritative nameserver records
• Resolver poisoning: Injecting false records into recursive resolvers; affects all clients using that resolver until TTL expiry
• Router firmware attacks: Consumer router compromise to change the DNS server setting — redirects all queries from the local network

DNS Cache Poisoning

The Kaminsky attack (2008) demonstrated a fundamental flaw in DNS design: a recursive resolver could be tricked into accepting a forged response to a query it just sent, poisoning its cache and serving the false answer to all subsequent clients.

• Classic Kaminsky: race condition between legitimate response and forged response; attacker floods with forged answers across all transaction IDs
• Source port randomization (the 2008 fix) raises the bar from 65,535 guesses to ~16 million — but not impossible
• SAD DNS (2020): side-channel attack that leaks source port information, reducing randomization to ~3,000 guesses
• DNSSEC is the definitive fix; resolver randomization is a mitigation only

DNS Tunneling

DNS tunneling encodes arbitrary data inside DNS queries and responses — typically as hostnames like encoded-data.attacker-c2.com — to create a covert channel through firewalls that allow DNS traffic.

• Data exfiltration: encoding stolen data in DNS query subdomains (e.g., 30-40 bytes per query)
• C2 channel: malware receives commands encoded in DNS TXT or NULL record responses
• Bypasses network egress filtering that blocks direct outbound connections but allows DNS port 53
• Tools: dnscat2, iodine, dns2tcp — all publicly available
• Detection signature: high query volume to single domain, long/high-entropy subdomains, unusual record types (TXT, NULL, CNAME)

DNS Amplification DDoS

DNS servers are reflectors: a small query to a public open resolver can return a response 10–100x larger. Attackers spoof the victim's IP as the source, directing the amplified response flood at the target.

• Amplification factor: standard A record ~40 bytes; ANY query response can be 3,000+ bytes — up to 54x amplification
• Open resolvers (DNS servers that answer queries from any IP) are the enabler — millions still exist on the public internet
• Mitigation: BCP38 (ingress filtering at ISP level to prevent IP spoofing); rate limiting on resolvers; disabling open recursion
• DNSBomb (2024): new variant using DNS query flooding to time-coordinate pulsing DDoS bursts

Domain Generation Algorithms (DGAs)

Malware using DGAs generates hundreds or thousands of pseudo-random domain names daily using an algorithm seeded with the current date. The attacker only needs to register one of those domains to receive callbacks — making blacklisting impractical.

• Families: Conficker, Murofet, Rovnix, Necurs — all use DGA for C2 resilience
• Detection: NX response bursts (NXDOMAIN for all the unregistered DGA domains), high entropy domain names, short TTLs, newly registered domains
• ML-based detection: character-level n-gram models distinguish DGA domains from human-readable ones with high accuracy
• Sinkholes: registering DGA domains before malware operators to redirect C2 traffic for research and disruption

Key Statistics

• 90%+ of malware uses DNS for C2 communication or data exfiltration (Cisco Umbrella annual report)
• DNS port 53 is allowed outbound in virtually all enterprise firewall policies
• Average dwell time before DNS-based C2 detection: 7–28 days in organizations without DNS monitoring
• DNS is involved in ~80% of phishing attacks (malicious domain resolution)
• DNS tunneling data exfiltration rate: ~100KB/minute over typical DNS — sufficient for credential and document theft

The Chain of Trust

DNSSEC establishes a hierarchical chain of trust from the DNS root down to individual zones. Each level signs the public key material of the level below, creating a verifiable chain all the way from ICANN's root key to the specific record being validated.

• Root zone: ICANN signs the root zone; the root public key (DNSKEY) is distributed with operating systems and resolvers
• TLD (.com, .org, .net): Root signs the DS record for each TLD's zone-signing key
• Authoritative nameserver: TLD signs the DS record for the domain's zone-signing key
• Recursive resolver: Validates the entire chain using the pre-configured root trust anchor — rejects any response that fails signature validation

Key Record Types

• DNSKEY: Contains the zone's public key; used to verify RRSIG signatures on other records in the zone
• RRSIG (Resource Record Signature): Cryptographic signature over a set of DNS records; validators check this against the DNSKEY
• DS (Delegation Signer): Hash of a child zone's KSK (key-signing key); stored in the parent zone to establish the chain of trust across zone boundaries
• NSEC / NSEC3: Authenticated denial of existence — proves that a queried name does NOT exist, preventing an attacker from fabricating NX responses

DNSSEC Limitations

• No encryption: DNSSEC signs records but does not encrypt them — the content of DNS queries and responses is still visible to network observers. Use DoH/DoT for privacy.
• Zone walking: NSEC records can be iterated to enumerate all hostnames in a zone (use NSEC3 with opt-out to mitigate)
• Key management complexity: Zone-signing keys should be rotated regularly; key-signing key rollover is a complex operational procedure
• DNSSEC amplification: Larger response sizes (signatures add hundreds of bytes) can increase DDoS amplification factor
• Deployment errors: Misconfigured DNSSEC can cause the entire zone to become unresolvable — high operational risk

Validation Tools

• dig +dnssec: Query with DNSSEC validation; examine RRSIG records and AD (Authenticated Data) flag in responses
• dnsviz.net: Visual DNSSEC chain-of-trust analyzer — displays each link in the chain, flags validation failures with clear explanations
• drill (ldns): Alternative to dig with strong DNSSEC support; drill -D example.com
• Verisign DNSSEC Analyzer: Online tool for checking zone signing status and chain integrity

dig +dnssec +short example.com A
# Look for "ad" flag in flags section:
# flags: qr rd ra ad
# "ad" = Authenticated Data (DNSSEC validated)

DNS over HTTPS (DoH)

RFC 8484 (2018). DNS queries are encoded in HTTP/2 POST or GET requests, transported over a standard TLS connection to port 443. From a network perspective, DoH traffic is indistinguishable from regular HTTPS web traffic.

• Uses port 443 — passes through virtually all firewalls without special rules
• Browser-native: Chrome, Firefox, Edge, Safari all support DoH with configurable providers
• Cloudflare 1.1.1.1: https://cloudflare-dns.com/dns-query
• Google: https://dns.google/dns-query
• Privacy implication: the DoH provider sees all your queries — choose your provider carefully

DNS over TLS (DoT)

RFC 7858 (2016). DNS queries are sent over a dedicated TLS connection on port 853. Unlike DoH, DoT uses a distinct port, making it clearly identifiable on the network — and easy to block or monitor at the network level.

• Dedicated port 853 — easily identified and controlled by network administrators
• No HTTP overhead — slightly lower latency than DoH in theory
• OS-level support: Android 9+ (Private DNS), Linux via systemd-resolved, stub resolvers
• Enterprise-friendly: visible to network monitoring, can be selectively permitted or blocked
• Connection reuse across queries (persistent TLS session) reduces per-query overhead

DNS over QUIC (DoQ)

RFC 9250 (2022). DNS queries over the QUIC transport protocol — the same UDP-based, multiplexed, encrypted protocol underlying HTTP/3. Combines the privacy of TLS with QUIC's connection resilience and lower head-of-line blocking.

• Uses port 853 (same as DoT, distinguished by protocol)
• QUIC's 0-RTT connection resumption reduces latency for frequent queries
• Better performance on lossy networks (UDP, no TCP head-of-line blocking)
• Still emerging: limited resolver support (AdGuard DNS, some NextDNS endpoints)
• Expected to become the preferred encrypted DNS protocol as QUIC adoption grows

The Enterprise Visibility Tension

DoH creates a significant enterprise security challenge: when browsers use DoH to a public resolver, DNS-level security controls (RPZ firewalls, malware domain blocking, data loss prevention via DNS) are bypassed entirely. The corporate DNS resolver never sees the query.

• Employee privacy argument: DoH prevents employer from monitoring personal browsing DNS queries
• Corporate security argument: DNS inspection is a critical security control; DoH bypasses it
• Resolution: Enterprise MDM can configure browsers/OS to use an internal DoH resolver; block public DoH endpoints at firewall level
• Chrome/Firefox enterprise policy: doh-resolver and doh-auto-upgrade-from settings for managed devices

Protective DNS (PDNS)

Protective DNS is the practice of blocking or redirecting DNS queries for known-malicious domains at the resolver level. Instead of returning the real IP address, the resolver returns NXDOMAIN or a sinkhole IP — the client's browser or malware never establishes a connection.

• Blocks at DNS layer — prevents connection before TCP handshake occurs
• Effective against malware C2, phishing, malware download domains, cryptomining
• CISA Protective DNS: free service for US federal agencies; blocks confirmed malicious domains from multiple threat intelligence sources
• Cisco Umbrella: enterprise PDNS with global threat intelligence from Talos, one of the largest threat research organizations
• Cloudflare Gateway: PDNS integrated with Zero Trust network access controls

Response Policy Zones (RPZ)

RPZ is a standard DNS firewall mechanism (supported by BIND and Unbound) that allows operators to define policy rules for how to handle queries matching specific domain patterns. RPZ zones are consumed as regular DNS zone files, making them easy to integrate with existing threat intelligence feeds.

• Actions: NXDOMAIN (block), redirect to sinkhole IP, passthru (force allow), NODATA
• Match on: exact domain, wildcard (*.evil.com), IP address of returned record (rpz-ip), client IP (rpz-client-ip)
• Zone transfer: RPZ zones can be distributed to all recursive resolvers via AXFR/IXFR
• Commercial feeds: ISC DNSDB, Farsight DNSDB, Spamhaus, Infoblox threat intelligence

DNS Sinkholes

A DNS sinkhole redirects malicious domain resolution to a controlled server (the sinkhole) rather than returning NXDOMAIN. This is more valuable for detection: the sinkhole server receives connection attempts from infected hosts, revealing which machines in the network are running malware.

• Detection: sinkhole connection logs identify infected hosts even before they're flagged by endpoint security
• Research sinkholes: security vendors register DGA domains to enumerate infected systems and disrupt botnets
• Enterprise sinkhole: internal server at a reserved IP receives all RPZ-redirected connections; logs are fed to SIEM
• Combined with RPZ: RPZ redirects to sinkhole IP, sinkhole logs all incoming connections with source IP

Home & SMB DNS Filtering

Enterprise-grade DNS filtering capabilities are now accessible to home users and small organizations through self-hosted and cloud solutions:

• Pi-hole: Self-hosted DNS sinkhole for local networks; blocks ads and malware domains; runs on Raspberry Pi or Docker; community-maintained blocklists
• AdGuard Home: Similar to Pi-hole with native DoH/DoT upstream support; built-in parental controls; supports custom RPZ-style rules
• NextDNS: Cloud-hosted; no hardware required; customizable blocklists; analytics dashboard; free tier available
• Quad9: Free public resolver with malware blocking; no configuration required — just change DNS server to 9.9.9.9

DNS Logging as Security Data

• Log everything: Every DNS query — domain, record type, response code, source IP, timestamp, resolver used
• Passive DNS (pDNS): Historical record of what IP addresses a domain has resolved to over time — invaluable for incident investigation ("what was this domain resolving to on the day of the incident?")
• Retention: Minimum 90 days; 12 months preferred for effective incident response and threat hunting
• SIEM integration: Forward DNS logs to your SIEM for correlation with other security events; DNS query spikes often correlate with malware activity in other log sources
• Volume baselines: Establish normal query volume per host; significant deviations warrant investigation

Detecting DGA Domains

• High-entropy names: DGA domains have high character entropy (lots of consonant clusters, no recognizable words); compute entropy score on query names
• NXDOMAIN bursts: A host hitting 50+ NXDOMAIN responses in a minute is likely trying all the unregistered DGA names for the day
• Short TTLs: Fast-flux infrastructure uses very low TTLs (60 seconds) to rotate IPs rapidly — flag domains with TTL under 300 seconds
• Length distribution: DGA domains tend to cluster around 12–22 characters; filter on length
• ML classification: Scikit-learn or purpose-built tools (PDNS toolkit) can classify DGA vs. legitimate with 95%+ accuracy using n-gram features

Beaconing Detection

• Malware beaconing manifests as highly regular DNS queries to the same domain at fixed intervals — automated behavior has much lower timing variance than human browsing
• Detection: compute inter-query timing standard deviation per (src IP, domain) pair; flag pairs with variance below threshold
• Legitimate services also beacon (NTP, telemetry, update checks) — build an allowlist of known-good beaconers to reduce false positives
• Jitter detection: some malware adds random jitter to intervals — look for consistent base interval even with jitter using autocorrelation

Newly Registered Domain (NRD) Monitoring

• The majority of malicious domains are newly registered — attackers register domains specifically for campaigns and abandon them quickly
• Flag any DNS query to a domain registered in the last 30 days for additional scrutiny
• NRD feeds: WhoisXMLAPI, DomainTools Iris, SecurityTrails provide NRD data for integration with DNS filtering
• Risk scoring: combine NRD with other signals (entropy, TLD, hosting provider, WHOIS privacy) for a composite risk score
• Homoglyph/typosquat detection: monitor for domains similar to your organization's domains (e.g., 0 for o, rn for m)

Registrar & Registry Lock

• Registrar lock (transfer lock): Prevents unauthorized domain transfer; standard and free at all major registrars; enable immediately after registration
• Registry lock: Higher-security lock applied at the TLD registry level (requires manual registry staff involvement to change); available for high-value domains at additional cost; prevents nameserver changes, DNSSEC changes, and domain deletion without out-of-band verification
• MFA on registrar account: Hardware key (YubiKey) preferred; SMS MFA provides minimal protection against SIM-swapping attacks on high-value domains
• Dedicated registrar account: Manage critical domains in an account separate from any other services; use a unique email address not used elsewhere

Email Domain Security: SPF, DKIM, DMARC

• SPF (Sender Policy Framework): TXT record listing authorized mail servers for your domain; prevents trivial spoofing of your domain's From: address
• DKIM (DomainKeys Identified Mail): Cryptographic signature on outgoing email, verified against a public key in DNS; authenticates the message body and headers
• DMARC: Policy record that tells receiving servers what to do with mail that fails SPF or DKIM; start with p=none (monitor), graduate to p=quarantine then p=reject; receive aggregate reports on spoofing attempts via the rua= tag
• BIMI: Brand Indicators for Message Identification — display your logo in supporting email clients; requires DMARC enforcement first