DNS

What DNS Is and Why It Is the Backbone of Every Attack

• DNS (Domain Name System) is the hierarchical, distributed naming system that translates human-readable domain names (google.com) into machine-routable IP addresses (142.250.80.46).
• It operates primarily over UDP port 53, with TCP port 53 used for zone transfers and responses exceeding 512 bytes.
• DNS was defined in RFC 1034 and 1035 in 1987 and has been extended continuously since; DNSSEC (RFC 4033-4035), EDNS0 (RFC 6891), DNS over HTTPS (RFC 8484), and DNS over TLS (RFC 7858).

DNS Record Types — The Complete Reference

How DNS Resolution Works (Recursive vs. Authoritative)

User types example.com
         │
         ▼
Step 1: Browser checks local cache (hosts file + OS DNS cache)
         │ (miss)
         ▼
Step 2: Query goes to recursive resolver (ISP, 8.8.8.8, 1.1.1.1)
         │ (recursive resolver does the work)
         ▼
Step 3: Recursor queries root server → asks "who manages .com?"
         │
         ▼
Step 4: Recursor queries .com TLD server → asks "who manages example.com?"
         │
         ▼
Step 5: Recursor queries example.com's authoritative nameserver → gets A record
         │
         ▼
Step 6: Returns IP to browser, caches result for TTL duration

Detection implications: Each of these steps can be abused. Attackers can poison a recursive resolver’s cache (DNS cache poisoning), register lookalike domains at the TLD level, or compromise authoritative name servers to redirect traffic.

Detection — DNS-Based Attacks

Detection 1: DNS Tunneling

DNS tunneling encodes data in DNS queries and responses. Since DNS is almost always allowed outbound from a network, attackers use it to bypass firewalls and proxies.

How it works: The client sends encoded data as subdomains of the attacker’s domain (e.g., base64encodeddata.evil.com), the attacker’s DNS server receives the query, extracts the data from the subdomain, and sends responses back as TXT records.

Indicators:

• High volume of DNS queries from a single host to a single domain
• Subdomain lengths consistently exceeding 20 characters (normal subdomains are short)
• TXT record responses larger than expected (> 512 bytes)
• DNS queries at unusual hours (workstations doing DNS lookup at 3 AM)
• TTL values that never change from a fixed value across hundreds of queries
• Domains rarely seen in baseline traffic

SPL query — detect DNS tunneling by query count and subdomain length:

index=dns sourcetype=dns_query
| eval subdomain_len = len(query)
| where subdomain_len > 30
| stats count, dc(query) as UniqueQueries, values(subdomain_len) as SubdomainLengths by src_ip, query_domain
| where count > 100 OR UniqueQueries > 50
| eval subdomain_avg_len = mvavg(SubdomainLengths)
| eval alert = if(subdomain_avg_len > 40, "HIGH — possible DNS tunneling (long subdomains)", "MEDIUM — elevated DNS queries to single domain")
| sort - count
| table src_ip, query_domain, count, UniqueQueries, subdomain_avg_len, alert

Detection 2: Domain Generation Algorithms (DGA)

Malware generates hundreds of potential C2 domains daily (DGA), queries each one, and connects when one resolves. The failed DNS queries (NXDOMAIN responses) are the key indicator.

Indicators:

• High rate of NXDOMAIN responses from a single host
• Domains with random-looking character patterns (gibberish, consonant-heavy)
• Domains with TLDs not commonly used by the organization (.tk, .ml, .ga, .top, .xyz)
• Failed DNS queries followed by a single successful resolve — the beacon found its rendezvous point
• Burst queries: rapid series of DNS queries to random-looking domains in 1-3 second bursts

SPL query — detect DGA via NXDOMAIN rate:

index=dns sourcetype=dns_query
| search response_code=3 (NXDOMAIN)
| timechart span=5m count by src_ip
| where count > 50
| eval alert = "HIGH — possible DGA activity, " . count . " failed DNS lookups in 5 minutes"
| sort - count

Detection 3: DNS C2 (Beaconing via DNS)

Some implants use DNS queries as a lightweight C2 channel — regular DNS queries to a C2 domain signal the host is alive and awaiting commands.

Indicators:

• Regular, periodic DNS queries at fixed intervals (±100ms jitter)
• Consistent query size and structure across multiple events
• Domains that resolve to IPs with known-bad reputation
• Domains registered recently (< 30 days) with privacy WHOIS
• Domains with names resembling legitimate services but with subtle misspellings (typosquatting)

Detection 4: DNS Cache Poisoning

Attacker injects malicious DNS records into the recursive resolver’s cache, redirecting users from legitimate sites to attacker-controlled servers.

Indicators:

• Users report being redirected to wrong sites
• A record for a legitimate domain (google.com) resolves to an unexpected IP
• Traffic to a legitimate domain connects to an IP in a different geographic region
• Certificate warnings on previously trusted sites
• DNS resolver logs show unexpected responses (port mismatches, TXID collisions)

DNS Reconnaissance Detection

Attackers use DNS to map the network before launching attacks.

SPL query — detect reverse DNS scan:

index=dns sourcetype=dns_query
| search query_type=PTR
| rex field=query "(?<subnet>\\d+\\.\\d+\\.\\d+)\\."
| stats dc(query) as UniquePTRs by subnet, src_ip
| where UniquePTRs > 25
| eval alert = "HIGH — reverse DNS scan detected from " . src_ip . " scanning subnet " . subnet

DNS Hardening for Analysts

Related

• TCP/IP — covers the tcp/ip concepts
• Common Ports and Protocols — covers the common ports and protocols concepts
• SPF and DKIM — detection and response for T1566 techniques

Sources

• Cloudflare — What is DNS?
• SANS DNS Tunneling Detection
• NIST SP 800-81-2 DNS Security
• MITRE ATT&CK T1572 (Protocol Tunneling)
• DNSSEC — ICANN