December 31, 2025
Updated: November 6, 2026
Understanding DNS tunneling, its risks, real-world abuse, and how defenders detect and stop covert DNS channels.
Mohammed Khalil
DNS is allowed on almost every network, which makes it an attractive way to move data out of an environment that blocks other channels. DNS tunneling hides command-and-control traffic or stolen data inside DNS queries and responses, often by encoding information in the subdomain labels of a domain the attacker controls. It matters because ordinary firewall rules rarely inspect those queries, so detection depends on DNS logging and behavioral analysis. This guide explains how DNS tunneling works, how to spot it, and how to limit it.
DNS tunneling is the abuse of the Domain Name System as a covert communication channel. MITRE ATT&CK describes the behavior as adversaries hiding command-and-control traffic inside DNS queries and responses so that it blends in with existing traffic. It is catalogued as technique T1071.004 under the Command and Control tactic.
Tunneling is a channel, and what travels through it can vary. When the channel is used to move stolen data out, the activity is better described as DNS data exfiltration. This article focuses on the channel itself and how defenders recognize it. Tunneling hides data in DNS; DNS spoofing does the opposite job and lies about addresses so users reach the wrong server. DNS tunneling is also different from a VPN tunnel, which is a protection you choose to use rather than a covert channel.
A DNS tunnel needs two things: malware or a tool on a compromised host, and a domain whose authoritative name server the attacker controls. The sequence is the same regardless of the tool:
KNCUGUSFKQ, which can be placed in front of a controlled domain as KNCUGUSFKQ.tunnel.example.The attacker never needs a direct network connection from the victim, because the victim's own resolver does the forwarding.
The DNS specification limits how much each query can carry. RFC 1035 sets labels at 63 octets or less, names at 255 octets or less, and UDP messages at 512 octets or less in the original protocol. Extensions raise the message size, but the label and name limits still cap each query.
A tunnel therefore has to split data across many queries, each with a long, unusual subdomain. That need for volume and length is the main reason tunneling can be detected.
Blocking DNS would stop users from reaching anything by name, so networks allow it. A firewall that sees an endpoint querying its internal resolver, and the resolver querying the internet, sees expected behavior. Unless something inspects the contents and frequency of those queries, the tunnel looks like ordinary DNS.
DNS tunneling query path (MITRE ATT&CK T1071.004) and where defenders can look. Control placement is DeepStrike's assessment.
Tunneling appears in both espionage and criminal operations. As of ATT&CK's September 2026 update, MITRE lists 56 procedure examples for T1071.004, including Cobalt Strike, Sliver, SUNBURST, and groups such as APT41, OilRig, and FIN7.
For data theft, MITRE's page on exfiltration over unencrypted protocols describes APT32 encoding data in the subdomain field of DNS packets and APT41 prepending encoded victim data as subdomains of an attacker-controlled domain during one campaign.
Our profile of OilRig covers a group known for DNS-based command and control.
Our guide to APT41 covers another group that MITRE lists for DNS-based techniques.
MITRE's detection strategy for this technique focuses on behavior rather than signatures. It looks for high-volume or anomalous DNS queries from non-browser processes, long or encoded subdomains, and DNS activity from scripting tools or scheduled jobs. Those are the right hypotheses to start with.
The table below summarizes common indicators. It is DeepStrike's practical guide, and the right thresholds depend on your own baseline.
Indicator | Why it matters | Common false positive |
|---|---|---|
Many unique subdomains under one parent domain | Each query carries a different piece of data | CDNs and some security products |
Long or high-randomness labels | Encoded data does not look like words | Some DNS-based services and licensing checks |
Unusual volume of TXT or NULL record queries | Responses can carry command data | Email authentication lookups use TXT records |
High rate of NXDOMAIN responses | Some one-way exfiltration tools leave queries unanswered or return errors | Misconfigured software, typos |
Regular intervals from one host | Beaconing behavior | Scheduled updates and monitoring agents |
DNS queries from a non-browser process | Normal users resolve names through browsers and services | Developer tools and scripts |
Timing analysis also overlaps with detection of other covert channels. Our explanation of HTTP beaconing shows how regular call-home intervals reveal malware, and the same logic applies to DNS.
No single indicator is conclusive. Combine them, attribute the queries to a process on the endpoint when you can, and review the domain's age and reputation before escalating.
Encrypted DNS changes what defenders can see. If a process on a host sends DNS over HTTPS to an external resolver, those queries bypass the organization's DNS logs and appear as ordinary HTTPS traffic. MITRE's list of T1071.004 examples includes malware that uses DNS over HTTPS.
The defensive options are to control which resolvers hosts may use, block known public encrypted-DNS endpoints where policy allows, and rely on endpoint telemetry to attribute DNS activity to processes. Encrypted DNS is valuable for user privacy, so the policy decision should be explicit rather than accidental.
DNSSEC does not address this problem. It authenticates DNS records and does not restrict what data a client puts in a query to a domain the attacker owns.
Prevention combines reducing the paths tunneling can use with improving visibility. These controls reflect MITRE's listed mitigations and common practice:
Control | What it addresses | Limits |
|---|---|---|
Force DNS through managed resolvers and block direct outbound DNS from endpoints | Removes the direct path to attacker servers | Does not stop tunneling through your own resolver |
Log and analyze DNS queries | Provides the data for detection and investigation | Needs storage, tuning, and ownership |
Protective DNS | Blocks connections to known-malicious domains | New or unknown domains may not be listed |
Endpoint telemetry | Ties DNS activity to a process | Requires deployed agents |
Network segmentation and egress rules | Limits what a compromised host can reach | Needs design and maintenance |
Data loss prevention | Detects sensitive data leaving | Weak against encoded fragments |
On protective DNS, the NSA and CISA published a joint information sheet in 2021. The agencies state that protective DNS can greatly reduce the effectiveness of ransomware, phishing, botnet, and malware campaigns by blocking known-malicious domains, and that DNS query logs support incident response and threat hunting. The alert does not address exfiltration specifically, so treat protective DNS as one layer rather than a complete answer.
Test only in environments you own or are authorized to assess. A defensive test should confirm four things: that DNS queries from every segment are logged centrally, that endpoints cannot reach outside resolvers directly, that your analytics flag an unusual pattern, and that someone responds. The test traffic should be small and use a domain you control.
A network penetration test can check egress filtering and monitoring together, which is closer to a real attack than reviewing configuration alone.
Measuring how long a detection takes also matters; see our explainer on mean time to detect for how to track it.
If an alert does fire, your incident response plan should say who investigates and how.
They convert data into characters that are valid in DNS labels, commonly with Base32 or similar encodings, and place the result in front of a domain they control. Because each label is limited to 63 octets, data is split across many queries. The attacker's name server decodes each label.
DNS is required for normal network operation, so firewalls generally allow it. Tunneling queries follow the same path and port as legitimate ones. Only inspection of query content and behavior can distinguish them.
Look for many unique subdomains under one domain, long or random-looking labels, unusual volumes of TXT queries, high NXDOMAIN rates, regular intervals, and DNS activity from processes that do not normally make it. Combine signals, because each has legitimate causes.
No. DNSSEC authenticates DNS answers and does not limit what a client sends in a query to a domain the attacker controls. An attacker can even sign their own domain.
Yes, when queries leave through an external encrypted resolver, they bypass your DNS logs. Controlling approved resolvers and using endpoint telemetry reduces this blind spot.
Mostly in authorized security testing and research, or as an emergency workaround on restricted networks. In normal business operation you should not see it, so unexplained tunneling-like patterns deserve investigation.
Layer controls: managed resolvers, blocked direct outbound DNS, DNS logging with analytics, protective DNS, and endpoint telemetry. No single control removes the risk, so test that each one works.
DNS tunneling endures because DNS must be allowed, and most networks do not examine what travels inside it. The practical response is to control which resolvers hosts can use, record and analyze DNS behavior, and treat unusual query patterns as a signal worth investigating. Verify that your controls work by testing them in an authorized exercise instead of assuming they do. Start by confirming that every DNS query is logged centrally, because without that record you cannot detect anything else.
If you want to validate whether your egress controls and DNS monitoring would catch a covert channel, you can discuss scope with DeepStrike's team.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us