Firewalls usually allow DNS because name resolution is required for business operations. Attackers exploit that trust by hiding commands or data inside permitted traffic, so the network sees approved protocol usage rather than obvious exfiltration. The problem is not DNS itself, but the lack of content-aware inspection and behavioural baselining around it.
Why This Matters for Security Teams
dns tunneling succeeds because it hides inside a protocol that organisations must keep open for daily operations. That makes it a control-gap problem, not a simple firewall failure. A perimeter rule can confirm that DNS packets are allowed, but it cannot, by itself, determine whether those packets carry legitimate name resolution or covert command-and-control traffic. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports stronger monitoring and boundary protection, but those controls still need practical tuning to be effective.
Security teams often get caught out because DNS is treated as a utility layer rather than an attack surface. If visibility is limited to port-based allow rules, then long, encoded subdomains, unusual query volume, and rare destination domains can blend into normal traffic patterns. The risk is especially high in environments with broad outbound egress, unmanaged endpoints, or fragmented logging across resolvers and firewalls.
In practice, many security teams encounter DNS tunneling only after data has already left the environment or remote instructions have already been executed, rather than through intentional DNS inspection.
How It Works in Practice
DNS tunneling works by splitting payloads into chunks and embedding them into DNS queries or responses. The attacker relies on the fact that recursive resolution is expected to reach external servers, so the traffic does not look inherently suspicious at the transport layer. A firewall may see permitted UDP or TCP port 53 traffic and allow it through, while the actual content carries encoded data, tasking, or exfiltrated fragments.
Operationally, detection depends on inspecting more than the destination port. Teams usually combine DNS logging, resolver analytics, threat intelligence, and anomaly detection. Key indicators include long or high-entropy subdomains, high query rates to a single domain, repeated NXDOMAIN responses, unusual TXT record use, and traffic to domains with weak reputation or short-lived registrations. NIST-aligned monitoring controls can help, but the practical value comes from baselining what normal DNS looks like in that specific environment.
- Inspect DNS at the resolver, not only at the firewall boundary.
- Log query name, record type, response code, client identity, and destination.
- Alert on encoding patterns, excessive label length, and bursty query behaviour.
- Restrict direct outbound DNS so endpoints use approved resolvers only.
- Correlate DNS events with endpoint and proxy telemetry for context.
In more mature environments, teams also validate whether split-horizon DNS, content filtering, and domain generation detection are working together rather than as isolated tools. Attackers adapt quickly, so the control objective is to make DNS abuse noisy and hard to sustain. These controls tend to break down in remote-work and branch-office environments where devices can reach the internet directly and resolver telemetry is incomplete.
Common Variations and Edge Cases
Tighter DNS control often increases operational overhead, requiring organisations to balance user connectivity against inspection depth. Blocking all unusual DNS is rarely realistic, so current guidance suggests focusing on risk-based exceptions and layered detection rather than absolute denial.
Some environments have legitimate reasons for high-volume or encoded DNS usage, including software update systems, service discovery, or security tooling. That makes blanket rules unreliable. Best practice is evolving toward allowlisting approved resolvers, monitoring record-type usage, and validating whether exceptions are genuinely required. Where DNS-over-HTTPS or DNS-over-TLS is enabled, visibility can shift away from the firewall entirely, so policy and telemetry need to account for encrypted name resolution paths.
DNS tunneling also becomes harder to spot in cloud, hybrid, and multi-tenant environments where outbound traffic may exit through shared infrastructure. In those settings, the key question is not whether DNS is allowed, but whether the organisation can distinguish business resolution from covert transport. For a control baseline, security teams can map DNS monitoring and boundary safeguards back to NIST SP 800-53 Rev 5 Security and Privacy Controls, then tailor detection to local traffic patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | DNS tunneling is a data security and exfiltration problem. |
| MITRE ATT&CK | T1071.004 | DNS is a common command-and-control channel for adversaries. |
Track DNS C2 techniques and correlate them with resolver and endpoint telemetry.
Related resources from NHI Mgmt Group
- Why do socially engineered attacks remain effective even when email filtering is in place?
- Why do lookalike domains remain effective even when email authentication is in place?
- Why do pig butchering scams remain effective even with stronger security controls?
- Why does DNS spoofing remain dangerous even if the first malicious query is brief?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
