DNS Monitoring: The Cheapest, Highest-Value Detection You're Not Doing

DNS Monitoring: The Cheapest, Highest-Value Detection You're Not Doing

DNS is involved in almost every internet-borne attack. Malware C2 callbacks, data exfiltration via DNS tunneling, phishing redirects, fast-flux botnets, supply-chain DNS hijacking — they all pass through DNS. DNS telemetry is cheap to collect, available in every environment, and produces high-confidence detections.

And most SOCs still don't really analyze it.

Most teams collect DNS server logs because compliance asks for it, then use them only for forensic lookups after an incident. The gap between "collected" and "analyzed in real time for detection" is where this post lives.

Why DNS is such a productive detection surface

Three structural facts about DNS make it a defender's friend:

1. Every internet-borne attack touches DNS. With rare exceptions, malware needs to resolve a domain to find its C2. Phishing pages need to be reachable via DNS. Data exfiltration over DNS tunneling, by definition, generates DNS queries. Even "encrypted" attacks that use HTTPS still need DNS resolution before the connection.

2. DNS traffic patterns are highly structured. Most legitimate enterprise DNS is small, predictable, and dominated by a few hundred domains. Anomalies stand out. A workstation suddenly resolving 10,000 unique random-looking domains an hour is not subtle.

3. DNS telemetry is cheap to retain. Compared to full packet capture, DNS query logs are tiny. 30–90 days of DNS history at full enterprise scale fits in commodity SIEM storage tiers.

The four detection patterns that pay back the investment

Pattern 1 — Algorithmically generated domains (DGAs)

DGA malware (Conficker historically, many ransomware families since) generates pseudo-random domain names to find its C2. The output looks like xkjqwerty1234.com or zh9asdfasdf.net — high entropy, no English-like structure, registered recently.

Detection: Apply entropy and n-gram analysis to resolved domains. Domains with high entropy (above ~3.5 bits per character) and no English-like character distribution are statistical anomalies. Cross-reference with WHOIS age — high-entropy + recent registration is a high-confidence signal.

Pattern 2 — DNS tunneling

DNS tunneling encodes data in DNS query labels and uses query/response pairs as a covert channel. The signature: unusually long subdomain labels, high query volume to a single second-level domain, frequent TXT or NULL record types in environments that shouldn't have them.

Detection: Alert on subdomains over 50 characters, query rates above ~50/minute to a single domain from a single source, or unexpected TXT record patterns. Tools like dnstap and passive DNS sensors give richer signal than DNS server logs alone.

Pattern 3 — Beaconing

Malware C2 typically beacons at a regular interval — every 60 seconds, every 5 minutes, every hour. The interval may have jitter, but the pattern is regular. Combined with destination domains that aren't business-relevant, beaconing is one of the highest-confidence detection signals available.

Detection: Statistical analysis of query intervals per source/destination pair. Periodicity scores above a threshold, especially to non-business domains, trigger investigation.

Pattern 4 — Known-bad domain queries (intelligence-driven)

The simplest pattern, the easiest to operationalize: maintain a current list of known-bad domains and alert on any query to them. This is what threat intelligence feeds are for.

QMasters' DailyIOC publishes ~250K daily indicators including domains under active malicious use. Customers running our managed SIEM service get this enforced as a SIEM correlation rule by default.

The QMasters take: the cheapest, fastest detection capability you can add this quarter is DNS query monitoring against a current threat intelligence feed. It costs almost nothing in compute, the false positive rate is low, and it catches a meaningful fraction of in-progress incidents you'd otherwise miss.

Architectural options

Three places to do DNS monitoring, in increasing order of capability and cost:

Option 1 — DNS server logs to SIEM

Forward your internal DNS server query logs (Windows DNS, BIND, Microsoft DNS) to QRadar, CrowdStrike NextGen SIEM, or wherever your SIEM lives. Enable query logging if it isn't already on (it usually isn't, by default, for performance reasons).

Pros: cheap, every environment has DNS servers.

Cons: only sees queries that go through internal DNS — encrypted DNS (DoH) and direct external DNS use bypass it.

Option 2 — Passive DNS sensor on the network

Place a passive sensor on a network tap or SPAN port that captures actual DNS traffic. Tools like Zeek (formerly Bro), dnstap-enabled resolvers, or commercial passive DNS appliances.

Pros: sees everything traversing the network, not just internal DNS.

Cons: more expensive, doesn't see DoH or DoT either.

Option 3 — DNS Security as a Service

Cisco Umbrella, Cloudflare Gateway, Akamai SIA, Netskope SWG — these solutions act as the DNS resolver for the entire enterprise, give you native detection plus enforcement (block resolution of known-bad domains), and handle the encrypted-DNS problem by being the legitimate resolver path.

Pros: detection + enforcement in one, scales to remote workforce, handles DoH/DoT cleanly.

Cons: licensed per user/device, requires routing all DNS through the service.

For most QMasters customers we recommend a combination: Option 3 for the user-facing endpoint fleet (Netskope is our typical partner here) and Option 1 for server-side workloads where routing through a cloud DNS resolver isn't a fit.

What to do this week if you have nothing today

A 5-step starting list, in order of return-on-effort:

1. Enable DNS query logging on internal DNS servers if it isn't on.
2. Forward those logs to your SIEM with at least 30-day retention.
3. Subscribe a known-bad domain feed to your SIEM as a correlation rule (DailyIOC, AlienVault OTX, Spamhaus DROP, or your existing TI feed).
4. Build alerts for two patterns to start: queries to known-bad domains, and high-entropy domain queries.
5. Add behavioral patterns (tunneling, beaconing) once the baseline is stable.

Step 3 alone catches a meaningful fraction of in-progress incidents in most mid-market environments.

Soft CTA

If your DNS telemetry is collected but not analyzed, request a managed SIEM assessment and we'll show you what 90 days of your DNS logs would have caught against the DailyIOC feed.

FAQ

Q: What kinds of attacks does DNS monitoring catch?

A: Malware command-and-control beaconing, DNS tunneling for data exfiltration, fast-flux botnets, DGA malware, phishing site redirects, shadow IT and unauthorized cloud usage, supply-chain DNS hijacking.

Q: How do I monitor DNS at scale?

A: Three options: native DNS server logs to SIEM (cheapest), passive DNS sensor on the network (richer), or DNS Security as a Service (detection + enforcement in one).

Q: What patterns should I alert on?

A: DGA-style domains, DNS tunneling indicators (long subdomain labels, high query volume), beaconing patterns (regular intervals to non-business domains), and queries to known-bad domains from threat intelligence.

Q: Does encrypted DNS (DoH/DoT) make this irrelevant?

A: Only if you let endpoints use external DoH/DoT resolvers. The right architectural posture is to make your enterprise DNS resolver (or a DNS Security as a Service) the only resolver allowed — block direct DoH/DoT to public services at the firewall.

Talk to QMasters

If DNS is currently a forensic tool rather than a detection surface in your environment, contact our SOC for a 30-minute walkthrough of what changes when it isn't.

Want the bigger picture? Visit QMasters, learn about our SOC team, or take a look at data loss prevention.

---

Author · QMasters SOC Team

Last updated · 2026-01-14

Reading time · 7 min