Air gaps fail when internal DNS is allowed to reach public DNS or when DNS traffic is trusted too broadly. Attackers can encode data, inject commands, or maintain command and control through queries that look routine. Because DNS is deeply embedded in normal operations, defenders may miss abuse unless they monitor resolver paths, payload patterns, and domain behavior carefully.
Why DNS stays a viable attack path inside an air gap
Air-gapped environments are often protected by policy, not absolute isolation. DNS is one of the easiest services to “leak” across that boundary because organisations still need name resolution for internal operations, updates, monitoring, and third-party dependencies. If the resolver can reach outside, or if internal DNS is too broadly trusted, attackers can ride that legitimate channel instead of trying to break the air gap directly.
That is why DNS-based abuse remains effective even where the network boundary looks strong on paper. The attack is not usually about defeating the air gap itself, it is about using a trusted protocol that defenders are reluctant to block or inspect too aggressively.
- Queries can be made to look routine while still carrying encoded data.
- Responses can be used to deliver instructions or stage follow-on activity.
- Repeated lookups can support command and control with very low noise.
DNS is also easy to underestimate because it is foundational infrastructure, which means many environments allow it more freely than other outbound traffic.
What attackers gain from DNS as a covert channel
DNS provides three advantages that make it useful in constrained networks: it is widely permitted, it is highly normalized, and it can be fragmented into small, hard-to-notice transactions. Those traits let an attacker move data in small bursts, disguise command traffic as ordinary name resolution, or establish a durable beaconing pattern that blends into expected resolver behavior.
The practical risk is not limited to exfiltration. DNS can also be used to confirm reachability, trigger staged payloads, or create a control path that survives when direct internet access is otherwise restricted. If defenders only watch for obvious downloads or direct sockets, they may miss the real control plane entirely.
- Data encoding is possible because subdomains can be structured to carry content.
- Command retrieval is possible because DNS responses can point to next steps.
- Persistence is possible because resolver traffic is continuous and usually trusted.
For this reason, DNS abuse is best treated as an abuse of control-plane trust, not just a network anomaly.
What to monitor when DNS is allowed in restricted networks
Detection has to focus on resolver paths and behavior, not only volume. In practice, the most useful signals are unusual query patterns, rare or newly seen domains, high entropy subdomains, repeated NXDOMAIN activity, abnormal query length, and unexpected recursive resolution to public infrastructure. DNS logs are especially valuable when correlated with endpoint, proxy, and firewall telemetry so you can see whether the traffic is part of a normal application flow or a covert channel.
Defenders should also be careful about where trust ends. If internal systems are allowed to query external resolvers directly, or if split-horizon and recursive resolution are not tightly controlled, the air gap can become porous without anyone noticing. The control objective is not to eliminate DNS, but to constrain which resolvers are allowed, what they may resolve, and what patterns are considered normal.
- Baseline normal domain behavior before looking for outliers.
- Alert on long, encoded, or highly unique subdomains.
- Verify that resolver egress is limited and logged.
When DNS is part of the path, the quality of the resolver boundary matters as much as the perimeter boundary.
Risk and Threat Considerations
DNS-based attacks matter in air-gapped or partially isolated environments because they exploit a trusted service that is often left open for operational convenience. The main danger is covert control or data movement through a channel defenders assume is harmless, which can leave compromise undetected for long periods.
Failure mechanism: The environment allows internal DNS resolution to reach public infrastructure, or trusts DNS traffic so broadly that malicious queries, encoded payloads, and command retrieval blend into normal name resolution.
Impact: Attackers can exfiltrate data, maintain command and control, and extend persistence without needing a direct inbound connection, weakening the assurance that the air gap provides.
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 CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Restricts outbound DNS paths and resolver access in restricted environments. |
| 8 — Audit Log Management | DNS abuse is best caught through resolver and query logging. | |
| Recommendation — Limit DNS egress to approved resolvers and remove unnecessary resolution paths. Log DNS queries centrally and alert on anomalous domain and payload patterns. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Controls which systems may use external resolution paths. |
| DE.CM — Security Continuous Monitoring | DNS covert channels require continuous monitoring of resolver behavior. | |
| PR.PT — Protective Technology | Protective controls can constrain DNS as a covert outbound channel. | |
| Recommendation — Enforce least-privilege network access to DNS services and resolvers. Monitor DNS telemetry for rare domains, entropy spikes, and abnormal query sequences. Use resolver restrictions and filtering to reduce DNS tunneling opportunities. | ||
| MITRE ATT&CK | T1071.004 — Application Layer Protocol: DNS | DNS tunneling and DNS-based C2 are explicit adversary techniques. |
| T1041 — Exfiltration Over C2 Channel | DNS can carry stolen data out through an existing command channel. | |
| Recommendation — Hunt for DNS tunneling, encoded subdomains, and DNS-based command and control. Inspect DNS patterns for data exfiltration riding on covert command traffic. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | DNS egress control is a boundary-protection problem in air-gapped designs. |
| Recommendation — Constrain DNS traffic to approved boundary devices and monitored resolvers. | ||
Practitioner Guidance
What to verify: Confirm exactly which resolvers are permitted, whether any internal host can query the internet directly, and whether outbound DNS is forced through monitored infrastructure. If the answer is “some systems can still resolve externally,” treat the air gap as degraded rather than intact.
What to prioritize: Start with resolver control, query logging, and anomaly detection for payload-shaped DNS behavior. That gives you the highest value because DNS abuse usually succeeds by looking ordinary, not by generating massive traffic.
Practitioner takeaway: An air gap is only as strong as the DNS path that can cross it, so the real control question is whether DNS is bounded, observable, and provably necessary, not whether it is simply allowed.
Related resources from NHI Mgmt Group
- Why do air-gapped networks still face identity security risk even when they are isolated from the internet?
- Why do air-gapped networks still get breached?
- Why do organisations still face account takeover risk even after deploying FIDO-based passkeys?
- Why do connected industrial devices increase security risk compared with older air gapped networks?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
