DNS tunneling uses DNS for communication rather than ordinary name resolution. Because UDP port 53 is often open, an internal host can carry data through DNS when standard web ports are restricted. The technique can support web access through an egress filter, but it can also provide an out-of-band channel for command-and-control or data exfiltration. section 9.1
Figure 9.1 DNS tunneling infrastructure
A tunneling setup links an internal host to an external system through DNS traffic, illustrating why allowed DNS resolution can become an alternate communication path. section 9.1
Hunt for tunneling by starting with DNS events that preserve queries, record types, and response details. Zeek can capture and summarize DNS requests and responses, providing fields such as query names, query types, and response codes for investigation. section 9.1
A supervised detection workflow separates regular DNS from suspected tunneling:
- Acquire labeled DNS data and define normal and tunneled classes; labels provide the ground truth a model learns to predict. section 9.2
- Keep training features aligned with production features, use recent relevant data, and seek balanced labeled classes. section 9.2.1
- Retain tool-level classes when useful: dns2tcp, dnscapy, iodine, and tuns can have different payload encodings, response sizes, query types, duplication, and throttling. section 9.2.1
- Review non-normal model classifications as leads, then inspect recurring domains, query types, and abnormal query content. section 9.3.6
Investigating microsofts.info
A Random Forest model mapped 3,171 DNS events under microsofts.info to tunneling classes. The events included TXT-record requests and abnormal query content; 63 events for the same domain were mapped as normal. A Whois lookup showed the domain was not owned by Microsoft, making the classification pattern a useful investigation clue rather than proof of a specific tunneling tool. section 9.3.6
