TL;DR: DNS tunneling hides command-and-control and exfiltration inside allowed DNS traffic, and Wazuh shows how to detect it by correlating high-entropy queries, deep subdomains, and suspicious record types such as TXT or NULL, according to Wazuh. The security lesson is that DNS remains a blind spot when teams rely on perimeter allow-listing without behavioural inspection.
At a glance
What this is: This is a Wazuh blog post explaining how DNS tunneling hides malicious commands and data inside allowed DNS traffic, and how to spot it using behavioural indicators.
Why it matters: It matters because DNS is still widely permitted on enterprise networks, so IAM, security architecture and SOC teams need visibility that goes beyond simple allow-listing when covert channels can carry exfiltration or command-and-control.
Context
DNS tunneling is a covert communications technique, not a separate protocol. Attackers abuse the trust that most networks place in DNS, using allowed queries and responses to move data and instructions past controls that only inspect ports and destinations.
For security teams, the governance gap is not whether DNS exists, but whether DNS traffic is being inspected for behaviour that indicates encoded payloads, suspicious record types or unnatural query patterns. The identity angle appears when those covert channels carry stolen secrets, machine commands or other non-human identity abuse.
The article is framed around practical detection, which is the right emphasis for this problem. Once DNS is treated as a monitored control plane rather than routine background traffic, tunneling becomes a visibility and detection issue instead of an invisible transport path.
Key questions
Q: What fails when DNS traffic is only allow-listed instead of inspected?
A: Allow-listing alone fails when attackers hide encoded commands or data inside permitted DNS queries and responses. The network still sees DNS as acceptable traffic, while the payload carries covert communication. That is why DNS monitoring has to look for behavioural anomalies such as high entropy, deep labels and suspicious record types, not just permitted destinations.
Q: Why does DNS tunneling create command-and-control risk as well as exfiltration risk?
A: DNS tunneling can move both outbound data and inbound instructions through a channel that is normally trusted for name resolution. That means the same covert path can support data theft, tasking, staging and malware delivery. When DNS becomes an uninspected transport layer, adversaries gain a durable way to maintain remote coordination.
Q: What are the signs that DNS tunneling detection is too weak?
A: Common signs include long random-looking subdomains, repeated queries to the same suspicious domain, excessive request volume from one host and unusual TXT or NULL records. If your detections only trigger on one symptom at a time, the control is probably too brittle. Stronger monitoring correlates several weak signals before escalation.
Q: How should security teams balance DNS visibility with operational noise?
A: Treat DNS visibility as a layered control problem. Start with endpoint or network capture, normalise the fields you need for analysis, then use combined indicators to reduce false positives. The goal is not to alert on every odd lookup, but to identify the subset of DNS activity that looks like covert transport.
Technical breakdown
How DNS tunneling turns allowed traffic into a covert channel
DNS tunneling works by placing attacker-controlled data inside query names or responses, then routing that traffic through infrastructure that appears legitimate to the network. Because DNS is usually permitted for normal business operations, controls that focus only on egress ports or domain allow-lists can miss the abuse. The key mechanic is not the protocol itself but the payload hidden in fields that should normally contain human-readable names. That makes DNS traffic a useful transport layer for command-and-control, exfiltration and staging when deeper inspection is absent.
Practical implication: inspect DNS payload patterns, not just destination allow-lists.
Why encoded queries and deep subdomains are useful tunneling signals
High-entropy subdomains are a common tunneling artefact because attackers need to pack encoded data into labels while staying inside DNS size constraints. Long strings of mixed characters, repeated label patterns and unusually deep subdomain structures are all evidence that the query is carrying more than ordinary name resolution intent. By themselves, these signals are not proof of malice, but combined they sharply narrow the search space for suspicious activity. The strongest value comes from correlating several weak indicators instead of relying on a single threshold.
Practical implication: correlate query entropy, label depth and repetition before escalating an alert.
Why TXT and NULL records increase suspicion in DNS monitoring
Record type matters because tunneling tools often choose DNS types that can carry arbitrary text or unusual data structures. TXT records are a familiar abuse path because they are flexible, and NULL records or similarly uncommon types can also indicate covert carriage rather than normal resolution. In a mature detection model, the record type is not used in isolation. It is combined with query length, subdomain depth and frequency so that the SOC is alerting on an abnormal communication pattern, not merely an uncommon DNS lookup.
Practical implication: add record-type awareness to DNS monitoring rules and correlate it with behaviour.
Threat narrative
Attacker objective: The attacker wants a covert channel that can carry commands or data out of the environment without being blocked by standard network controls.
- Entry begins when an endpoint makes DNS queries that look ordinary to the network but contain encoded payloads or unusually deep subdomain structures.
- Credential or command transfer occurs inside those queries and responses, allowing the attacker to move instructions or data without opening a separate channel.
- Impact follows when the tunnel supports command-and-control, data exfiltration or staging while traditional perimeter controls remain unaware of the exchange.
Breaches seen in the wild
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
DNS visibility is now a governance control, not just an operations concern. DNS is often treated as background infrastructure, but that assumption fails when the same channel can transport commands and data out of the environment. Security teams need to regard DNS inspection as part of detection governance, because blind trust in permitted traffic creates a standing concealment path for adversaries. The practitioner conclusion is simple: if DNS is not inspected behaviourally, it is not controlled.
Covert traffic detection depends on correlation, not single-rule certainty. High entropy, deep subdomains and unusual record types are individually noisy, but together they form a much stronger abuse pattern. That approach aligns with NIST-CSF detection thinking and with ATT&CK-style adversary behaviour analysis, where one weak signal becomes meaningful only when combined with others. The practitioner conclusion is to build layered detections instead of chasing one perfect indicator.
DNS tunneling is a non-human identity problem when secrets or agent commands are in transit. Once stolen API keys, tokens or automated instructions are embedded in DNS traffic, the issue becomes NHI governance as much as network monitoring. That is the important intersection for IAM and NHI programmes: identity-bound data can move through channels that were never designed for identity lifecycle controls. The practitioner conclusion is to extend identity and secrets visibility into network detection workflows.
DNS tunnel detection should be treated as a control-quality signal, not an alerting exercise. If a SOC can only spot tunneling after multiple indicators line up, the underlying control objective is to shrink exposure and shorten dwell time, not just raise more alerts. That makes DNS logging, decoder quality and rule maintenance part of broader resilience. The practitioner conclusion is to measure whether DNS telemetry is detailed enough to support timely containment.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
What this signals
Covert DNS traffic becomes a real programme risk when it carries secrets or machine instructions. Security teams should treat DNS monitoring as part of the identity and secrets surface, not only the network perimeter. The same behaviour that exposes tunneling can also reveal stolen credentials moving through non-traditional channels, which is why this control belongs in SOC and IAM conversations together.
43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec. That concern extends to covert channels such as DNS when sensitive data can be encoded, replayed or exfiltrated outside normal application paths.
DNS tunnel detection should feed a broader secrets and egress governance model. If the SOC can see suspicious DNS but the IAM or NHI programme cannot trace what credential, token or service identity was active, the organisation still lacks full containment context. The practical response is to link network detections to identity and secrets inventories so exposure can be investigated end to end.
For practitioners
- Inspect DNS for behavioural anomalies Monitor query entropy, label depth, frequency and record type together so detections reflect the full tunneling pattern rather than one noisy symptom.
- Capture DNS traffic at the endpoint Use host-level packet capture or equivalent telemetry on key systems so covert DNS activity is visible before it is flattened by upstream logging.
- Tune detection rules for compound indicators Require at least two suspicious DNS characteristics before raising a high-confidence alert, then prioritise the strongest combinations for triage.
- Review DNS telemetry retention and rotation Keep DNS logs available long enough to investigate slow-burn tunneling campaigns and ensure rotated logs remain searchable for retrospective analysis.
Key takeaways
- DNS tunneling exploits the trust that many networks still place in permitted DNS traffic, which makes behavioural inspection essential.
- The strongest detection patterns combine query entropy, subdomain depth and unusual record types instead of relying on one indicator alone.
- Teams that can see DNS behaviour, retain the logs and correlate them with identity and secrets data are in a better position to detect covert communications early.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001; TA0006; TA0010; TA0040 — Initial Access; Credential Access; Exfiltration; Impact | DNS tunneling is used for covert access, data movement and operational impact. |
| Recommendation — Map suspicious DNS patterns to ATT&CK techniques and prioritise detections for exfiltration and command-and-control. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | The article is fundamentally about detecting anomalous DNS behaviour in continuous monitoring. |
| Recommendation — Extend continuous monitoring to DNS traffic so anomalous query patterns are visible to the SOC. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | DNS logging and retention are central to investigating and proving tunneling activity. |
| Recommendation — Centralise and retain DNS logs so suspicious query patterns can be investigated after the alert fires. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The detection method depends on analysing DNS audit data for suspicious patterns. |
| Recommendation — Review DNS audit records for encoded queries, unusual record types and repeated request bursts. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | DNS tunneling can move tokens and other machine secrets through covert channels. |
| Recommendation — Hunt for leaked NHI secrets moving through DNS and revoke exposed credentials immediately. | ||
Key terms
- DNS Tunneling: DNS tunneling is the use of DNS queries and responses to carry hidden data for command-and-control or exfiltration. Because DNS is commonly trusted and lightly inspected, attackers can hide malicious communication inside traffic that looks routine at first glance.
- High Entropy Query: A high entropy query contains a string that looks random rather than human-readable. In DNS monitoring, that often suggests encoded payloads such as base32 or base64 fragments, especially when the pattern appears in long labels or repeats from a single host.
- Deep Subdomain Structure: Deep subdomain structure means a DNS name contains multiple nested labels before the registered domain. Attackers use this structure to split and move encoded data within DNS size limits, so repeated depth combined with other anomalies is a useful tunneling indicator.
- Suspicious Record Type: A DNS record type that is unusual for the expected lookup pattern, such as TXT or NULL in a context where address resolution would normally use A or AAAA records. Record type anomalies matter because they often signal that DNS is being used for data carriage rather than lookup.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org