Who is responsible when DNS tunneling is missed in an environment?

Why This Matters for Security Teams

dns tunneling is rarely a pure DNS problem. It often reflects gaps in logging, endpoint telemetry, threat hunting, and escalation paths between teams that each believe someone else is watching the signal. Under NIST SP 800-53 Rev 5 Security and Privacy Controls, organisations are expected to establish monitoring, auditability, and incident handling that work together, not as isolated controls. That matters because DNS tunneling can blend into routine resolver traffic, especially in environments with permissive egress, weak baselining, or outsourced DNS services.

The practical risk is accountability drift. Network teams may own the resolver, SOC teams may own detection, and endpoint teams may own suspicious process activity, yet none of them may have authority to correlate all three. When that happens, tunnelled traffic can persist long enough for exfiltration, command-and-control, or lateral movement. The issue is not just whether an alert fired. It is whether the organisation had a named owner for the data path, the detection logic, and the response decision.

In practice, many security teams encounter DNS tunneling only after data leaves the environment or a responder notices unusual resolver behaviour during a separate investigation.

How It Works in Practice

Operational responsibility should be mapped across the full detection chain. Network security typically owns DNS infrastructure, resolver policy, and upstream filtering. The SOC usually owns alert triage, hunting queries, and case correlation. Endpoint or EDR teams contribute process, parent-child execution, and command-line context that can reveal the initial malware or script initiating the tunnel. Where cloud workloads or remote branches use local resolvers, ownership should also include those platforms so visibility does not stop at the perimeter.

A practical model is to separate control ownership from incident ownership:

• Control owners maintain DNS logging, query retention, and sinkhole or block policy.
• Detection engineers maintain analytics for high-entropy queries, rare domains, abnormal volume, and long subdomain patterns.
• Incident responders decide whether the activity is benign, suspicious, or confirmed compromise.
• Service owners validate business applications that may generate unusual DNS behaviour, such as SD-WAN, security tools, or update channels.

For detection logic, current guidance suggests combining multiple weak indicators rather than relying on a single threshold. That includes NXDOMAIN spikes, unusually long labels, encoded payload patterns, high query rates to rare domains, and endpoint correlation showing a process making repeated DNS requests. MITRE ATT&CK is useful here because DNS tunneling is often part of command-and-control tradecraft, and the technique mapping helps analysts connect an odd DNS pattern to a broader intrusion path. Useful starting points include the MITRE ATT&CK DNS protocol sub-technique and operational logging guidance from CISA Logging Made Easy.

Responsibility also needs to be reflected in escalation. If DNS telemetry is owned by a network team but reviewed by the SOC, then ticket routing, severity criteria, and response timelines must be documented so tunneling cases are not treated as low-priority noise. These controls tend to break down when DNS is outsourced to a provider or split across on-premises, cloud, and branch networks because no single team has full query visibility.

Common Variations and Edge Cases

Tighter DNS monitoring often increases operational overhead, requiring organisations to balance higher-fidelity detection against application compatibility and analyst workload. Best practice is evolving for environments where encrypted DNS, managed resolvers, or cloud-native name services reduce traditional visibility. In those cases, responsibility is still shared, but the evidence sources shift and the blind spots become more important than the alert count.

There is no universal standard for this yet, but organisations should be explicit about edge cases. For example, security tools that legitimately generate high-volume or encoded DNS traffic can look suspicious without allowlisting and context. Similarly, branch offices or SaaS-heavy environments may push DNS resolution outside the reach of the main SOC unless logs are centralised and retained long enough for retrospective hunting. In cloud and zero trust environments, the question is less “who owns DNS?” and more “who owns enough telemetry to prove whether DNS is being abused?”

Identity and privilege can also intersect with the problem. If a compromised endpoint account can launch a process that generates tunneling traffic, then the issue is not only network detection but also endpoint control, least privilege, and rapid containment. For broader control mapping, MITRE ATT&CK helps tie the pattern to adversary behaviour, while CISA threat guidance can support response prioritisation when tunneling is part of a larger intrusion. The right answer is usually a named service owner plus a named detection owner, with the SOC holding the final triage mandate.

Related resources from NHI Mgmt Group

• What breaks when DNS fails in an eCommerce environment?
• How should teams govern DNS access in a multi-team environment?
• Who should own DNS governance in an identity-heavy environment?
• DNS Tunneling