High-Volume DNS Tunneling Alert from Marketing
A SOC receives about 1,800 SIEM alerts per day. The top rule, 'Possible DNS tunneling,' generates 900 alerts from the marketing VLAN 10.20.40.0/24. DNS logs show 14 hosts querying names such as a8f3c1.metrics.example-cdn.com, mostly TXT, every 30-90 seconds, with responses around 300-500 bytes. The domain was registered 11 days ago; its authoritative NS is a large CDN. Marketing recently launched a campaign and says the analytics vendor uses a first-party CNAME to example-cdn.com. The vendor's documentation is not available to the SOC. Other telemetry shows normal HTTPS traffic to the same vendor, no unusual authentication, and no endpoint alerts. The SOC has a 4-hour SLA for high-severity alerts and limited DNS logging retention of 7 days. The CISO wants to reduce alert load without missing real tunneling.
1. Assess the likelihood of DNS tunneling versus legitimate analytics, citing specific indicators.
Read the worked answer
The pattern is ambiguous. TXT queries, 30-90 second intervals, and 300-500 byte responses are consistent with analytics beacons but also with tunneling. The 11-day-old domain is a risk indicator, but it is explained by a new campaign and a CDN-hosted CNAME. The 14 hosts all in one marketing VLAN and the absence of endpoint alerts or unusual authentication argue against active credential theft or malware. A real tunneling detector should focus on high-entropy subdomains, long query labels, many unique subdomains per host, and TXT response payloads that look encoded or compressed. The visible label a8f3c1 is short and low entropy, which is more beacon-like than data-bearing. This is not enough to close the alert, but it shifts the burden toward validation rather than immediate containment.
2. Design a validation plan within the 7-day DNS retention and the 4-hour SLA.
Read the worked answer
Within the SLA, preserve the relevant DNS logs before they age out and enrich the alert with what is available. Pull 7 days of queries for the 14 hosts and compute unique subdomain counts, label length distribution, and entropy per host. Inspect TXT response sizes and whether payloads vary in a way that suggests encoded data. Check passive DNS and the CDN's certificate or SNI for the same domain, and compare destination IPs with marketing's known vendor ranges. Ask marketing for the vendor's expected query pattern and contact the vendor through a known channel, not an address in the suspicious domain. If the pattern remains unexplained, isolate one low-impact host and monitor its DNS and HTTPS behavior while the user continues work on another machine. Document the validation in the ticket so the SLA is met.
3. Recommend a detection and tuning change that reduces alert load while preserving coverage for real tunneling.
Read the worked answer
Do not disable the tunneling rule. Split it into two behaviors. For known analytics domains, create a low-severity informational rule or a suppression scoped to the specific domain, the 14 hosts, and the observed low-entropy label pattern, with a review date. Keep the high-severity rule for high-entropy labels, unusually long queries, high unique-subdomain counts, and TXT responses that exceed a baseline. Add enrichment for domain age, passive DNS, and destination reputation so a new domain with high entropy still pages. Tune the threshold using the 7-day data rather than guessing. Finally, ask marketing to route analytics through a documented first-party domain or proxy so the SOC can allowlist it by name. Measure alert volume after tuning and confirm that a synthetic high-entropy query still triggers.