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.
NHIMG editorial — based on content published by Wazuh: detecting DNS tunneling with Wazuh
Questions worth separating out
Q: How should security teams detect DNS tunneling in enterprise networks?
A: Use behavioural correlation rather than single indicators.
Q: Why does DNS tunneling remain effective even when firewalls are in place?
A: Firewalls usually allow DNS because name resolution is required for business operations.
Q: What signals indicate DNS traffic is being used as a covert channel?
A: Look for long pseudo-random labels, repeated queries to the same suspicious domain, deep subdomain nesting, and unusual record types such as TXT or NULL.
Practitioner guidance
- Implement composite DNS detection rules Correlate entropy, subdomain depth, and record type so alerts fire only when at least two tunneling indicators appear together.
- Forward endpoint DNS logs into central detection Use endpoint collection and SIEM parsing to extract query name, source, destination, and DNS type from monitored traffic.
- Baseline normal DNS behaviour by host Measure query frequency, common domains, and record-type distribution per system so anomalies stand out quickly during triage.
What's in the full article
Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step tcpdump monitoring setup on Ubuntu so the DNS traffic capture can be reproduced exactly.
- Full decoder and rule definitions for extracting DNS fields from /var/log/dns_monitoring.log.
- Systemd and logrotate configuration details for keeping the monitoring service running and the log file manageable.
- Example dig test commands that trigger each rule so teams can validate their own detections.
👉 Read Wazuh's guide to detecting DNS tunneling with Wazuh →
DNS tunneling detection: are your network controls catching covert traffic?
Explore further
DNS tunneling is a visibility problem before it is a malware problem. Perimeter controls that allow DNS by default often miss the behavioural change that matters, which is encoded traffic moving inside a trusted protocol. That makes DNS telemetry a governance issue for network security teams, not just an incident-response curiosity. The practical conclusion is that DNS needs content-aware detection, not only transport allow-listing.
A question worth separating out:
Q: Who is responsible when DNS tunneling is missed in an environment?
A: Responsibility is shared across network security, SOC, and endpoint teams, because the failure is usually one of visibility and correlation rather than a single missing control. In practice, leaders should assign ownership for DNS telemetry, detection engineering, and incident triage so tunnelled activity is not treated as a niche network issue.
👉 Read our full editorial: DNS tunneling detection shows why DNS visibility still matters