TL;DR: DNS is one of the oldest and most trusted protocols on the internet — and attackers exploit that trust relentlessly. From registrar-level hijacking that redirects entire domains, to DNS tunneling that exfiltrates data through firewalls, to dangling CNAME records that hand subdomain control to anyone who claims them, the DNS attack surface is broad and routinely underestimated. Most organizations monitor HTTP traffic religiously but barely glance at their DNS logs. This post covers the attack vectors we encounter during infrastructure and external penetration tests, and the defenses that actually work.
DNS Attack Types at a Glance
| Attack Type | Severity | Detection Difficulty | Primary Impact |
|---|---|---|---|
| Registrar Hijacking | Critical | Medium | Full domain takeover, MX/NS redirection |
| Cache Poisoning | Critical | Hard | Traffic redirection for targeted users/networks |
| DNS Tunneling | High | Hard | Data exfiltration, C2 communication |
| Dangling CNAME Takeover | High | Easy (if monitored) | Subdomain hijacking, phishing, cookie theft |
| DNS Rebinding | High | Hard | Bypass same-origin policy, access internal services |
| Zone Transfer Leakage | Medium | Easy | Full DNS zone disclosure, reconnaissance |
Registrar-Level DNS Hijacking
The most devastating DNS attack does not exploit a protocol weakness — it exploits the human and administrative layer. Registrar-level hijacking occurs when an attacker gains access to the domain registrar account (GoDaddy, Namecheap, Cloudflare, etc.) and modifies the domain's nameserver records to point to infrastructure they control. Once the nameserver delegation changes propagate, the attacker controls every DNS response for the domain — web traffic, email, API endpoints, everything.
This attack has been used in high-profile campaigns against major organizations. The attacker typically gains registrar access through credential stuffing, phishing the domain administrator, social engineering the registrar's support staff, or exploiting weak account recovery mechanisms. Once inside, they change the NS records, configure their own authoritative nameserver with the victim's existing records (to avoid immediate detection), and selectively redirect traffic — often MX records first, to intercept email and use it to compromise additional accounts.
Defenses: Enable registrar lock (also called transfer lock or clientTransferProhibited). Use MFA on all registrar accounts. Enable registry lock where available — this requires out-of-band verification for any NS changes. Monitor your NS records externally and alert on any unauthorized changes.
DNS Cache Poisoning
Cache poisoning targets recursive DNS resolvers — the servers that ISPs and organizations operate to resolve queries on behalf of their users. The attacker's goal is to inject a forged DNS response into the resolver's cache, so that all subsequent queries for the targeted domain return the attacker's IP address instead of the legitimate one.
The classic Kaminsky attack (2008) demonstrated that cache poisoning was far easier than previously assumed. Modern defenses include source port randomization, 0x20 encoding (randomizing the case of query names), and DNSSEC validation. However, many internal corporate resolvers still run without DNSSEC validation enabled, and side-channel attacks against source port randomization continue to be published. SAD DNS (2020) showed that ICMP rate limiting behavior in the Linux kernel could be used to derandomize source ports on many resolver implementations.
Why Cache Poisoning Still Matters
Even with mitigations, cache poisoning remains relevant because the resolver infrastructure is fragmented. A corporate environment may use an internal resolver that forwards to an upstream resolver, and neither may validate DNSSEC. An attacker on the same network segment as the resolver — common in internal penetration tests — can race legitimate responses with forged ones. The window is small but the payoff is enormous: all users on that resolver see the attacker's IP for the targeted domain.
DNS Tunneling for Data Exfiltration
DNS tunneling exploits the fact that DNS traffic is almost universally allowed through firewalls. Organizations that block all outbound traffic except HTTP/HTTPS often forget that DNS queries must also traverse the network boundary — typically to port 53 on an external resolver. An attacker who can execute code on an internal host (post-exploitation) can encode stolen data into DNS queries directed at a domain they control.
The mechanics are straightforward: the attacker operates an authoritative nameserver for a domain (e.g., exfil.attacker.com). Malware on the compromised host encodes data in the subdomain field of DNS queries: base64encodeddata.exfil.attacker.com. The query traverses the corporate DNS infrastructure, reaches the internet, and is routed to the attacker's nameserver, which logs the encoded subdomain and extracts the data. Response data can be returned via TXT records, enabling bidirectional communication.
Tools like iodine, dnscat2, and dns2tcp automate this process. Throughput is limited — typically 5-50 KB/s depending on query rate and encoding — but sufficient for exfiltrating credentials, database dumps, and configuration files. More critically, DNS tunneling is commonly used for command-and-control communication, allowing persistent remote access through networks that appear fully locked down.
Detection: Monitor for anomalous DNS query patterns — high query volume to a single domain, unusually long subdomain labels, high entropy in query names, and TXT record queries to uncommon domains. DNS analytics platforms and SIEM rules can flag these patterns, but they must be tuned to avoid false positives from legitimate services that use long DNS names (CDNs, cloud services).
Dangling CNAME and Subdomain Takeover
Subdomain takeover via dangling CNAME records is one of the most common findings in our external attack surface assessments. The vulnerability arises when an organization creates a CNAME record pointing a subdomain to a third-party service — a cloud storage bucket, a Heroku app, a GitHub Pages site, a SaaS marketing platform — and later deprovisions the service without removing the DNS record.
The CNAME record still exists, pointing to a resource that no longer belongs to the organization. An attacker who discovers the dangling record can register the same resource name on the third-party platform and serve arbitrary content on the organization's subdomain. The impact depends on the subdomain's position in the domain hierarchy:
- Cookie scope escalation: If the parent domain sets cookies with
Domain=.example.com, the attacker's subdomain can read and set those cookies — including session tokens - Phishing credibility: Content served from
support.example.comorportal.example.cominherits the trust of the parent domain - Email implications: Depending on SPF/DMARC configuration, the attacker may be able to send emails from the taken-over subdomain
Prevention: Maintain an inventory of all DNS records and the services they point to. When deprovisioning a service, remove the DNS record first. Automate detection with tools that resolve all CNAME records and check whether the target resource still exists. Services like AWS S3, Azure, and Heroku each have specific fingerprints that indicate a claimable dangling resource.
DNS Rebinding Attacks
DNS rebinding exploits the browser's same-origin policy by manipulating DNS responses over time. The attacker hosts a page on their domain that the victim visits. The initial DNS response returns the attacker's server IP, delivering malicious JavaScript to the victim's browser. The attacker's DNS server is configured with a very short TTL. When the JavaScript makes a subsequent request to the same domain, the DNS response now returns an internal IP address — 192.168.1.1, 127.0.0.1, or the IP of an internal service.
Because the browser considers the request to be same-origin (same domain), the JavaScript can read the response. The attacker's code is now making authenticated requests to internal services — routers, IoT devices, cloud metadata endpoints, internal APIs — and exfiltrating the responses back to the attacker's server. This effectively turns the victim's browser into a proxy for accessing internal network resources.
Defenses: Internal services should validate the Host header and reject requests from unexpected domains. DNS resolvers should implement DNS rebinding protection by refusing to resolve external domains to internal IP ranges (many modern resolvers support this). Network segmentation limits the blast radius.
DNSSEC: What It Solves and What It Doesn't
DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses have not been tampered with between the authoritative server and the client. It effectively prevents cache poisoning and man-in-the-middle modification of DNS responses in transit.
However, DNSSEC adoption remains incomplete. Signing your zones is only half the equation — resolvers must also validate signatures, and many corporate and ISP resolvers do not. DNSSEC also introduces operational complexity: key rotation, signature expiry management, and the risk of breaking resolution if DNSSEC is misconfigured. Organizations that deploy DNSSEC must monitor for signature expiry and automate key rotation to avoid self-inflicted outages.
Critically, DNSSEC does not encrypt DNS queries. An observer on the network can still see which domains are being resolved. For query privacy, DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) is required — and these introduce their own operational and visibility trade-offs for enterprise security teams that rely on DNS logging for threat detection.
DNS Monitoring: The Overlooked Defense
Most organizations have extensive HTTP/HTTPS logging and monitoring but minimal visibility into their DNS traffic. This blind spot is exactly what attackers exploit. Effective DNS monitoring should include: logging all DNS queries from internal resolvers, alerting on new or unusual query patterns, monitoring authoritative zone changes, tracking CNAME record targets for service deprovisioning, and baseline analysis to detect tunneling activity.
At Lorikeet Security, we consistently find that organizations with mature security programs still lack DNS-specific monitoring. During external penetration tests, we identify dangling CNAME records, open zone transfers, and missing DNSSEC on domains that handle sensitive transactions. During internal assessments, DNS tunneling is frequently a viable exfiltration path because egress filtering focuses on HTTP/HTTPS and ignores DNS.
Map Your DNS Attack Surface
Lorikeet Security's external penetration testing and attack surface management includes comprehensive DNS reconnaissance — subdomain enumeration, dangling record detection, zone transfer testing, and DNSSEC validation. Discover what's exposed before an attacker does.
