After an incident, one of the first data sources an investigator wants is DNS query logs. What domains did this host reach out to? When? How often? Did the resolution pattern look like beaconing? Did it query something it had never resolved before? Did anything try to encode data in subdomains?
In most environments, those logs either don’t exist at the level of detail needed, haven’t been retained long enough to cover the intrusion window, or haven’t been connected to anything that could raise an alert while the activity was happening.
That is the DNS visibility gap. It is persistent, it is largely self-inflicted, and it keeps showing up in post-mortems.
What DNS actually tells you
DNS is involved in nearly every network action a host takes. Command-and-control channels resolve domain names. Lateral movement requires name resolution across internal systems. Exfiltration tools use DNS tunneling because DNS traffic is frequently allowed outbound without inspection. Phishing infrastructure registers lookalike domains that resolve for hours before being burned.
DNS query telemetry reveals things that endpoint and firewall logs often miss. Beacon intervals show up as periodic resolution requests with consistent timing. DNS tunneling produces queries with abnormally long subdomain strings or high query rates to a single domain. Internal name resolution patterns expose which systems are communicating and what services they’re reaching. First-seen domain queries flag new infrastructure that appeared during the intrusion window.
None of this requires exotic analysis. Much of it is straightforward frequency analysis, entropy scoring of subdomain strings, and comparison against known-bad domain intelligence feeds. These are detection approaches that work and that security teams in well-resourced environments have been running for years.
The problem is not that DNS detection is unsolved. It is that most environments haven’t bothered to implement it.
Why DNS gets treated as plumbing
DNS infrastructure in most enterprises is owned by networking or platform engineering teams. It is regarded as a utility layer — something that needs to be available, resilient, and fast. Security is not the primary operating concern, and it frequently isn’t a concern at all.
This has practical consequences. Recursive resolvers often log in formats optimized for troubleshooting, not for security analysis. Query logs may be enabled during a problem and then turned off to reduce storage load. Internal DNS traffic — the queries that matter most for lateral movement detection — may never flow through a system that security has access to.
The SIEM receives firewall logs. It receives endpoint telemetry. It receives authentication events. DNS query logs from the internal recursive resolver, if they exist at all, often sit on a server that nobody has connected to anything.
This is an instrumentation decision that reflects organizational priorities. DNS is networking’s problem until something goes wrong. Then it becomes security’s problem, at which point the data doesn’t exist.
The detection value that’s being left on the floor
Consider what an analyst investigating a potential intrusion can do with comprehensive DNS logs versus without them.
With complete DNS telemetry, the investigator can establish a timeline of external contact from a compromised host going back to before the initial alert fired. They can identify C2 infrastructure by looking for domains with low historical resolution frequency, high query intervals, or suspicious registration characteristics. They can trace internal reconnaissance by identifying unusual internal name queries — a workstation that suddenly started resolving names for servers it had never contacted before. They can find DNS tunneling by flagging query volume and entropy anomalies.
Without those logs, the investigator works from endpoint artifacts and firewall flow records, which are blunter instruments. The lateral movement may have happened but there’s nothing in the data that shows the path clearly. The C2 connection may have happened but the only evidence is a firewall allow rule and a resolved IP that may no longer be associated with anything malicious.
The difference between these two investigative positions is enormous. It is the difference between reconstructing what happened from a good evidence set and speculating from fragments.
The organizational resistance
Security teams who try to get DNS logging implemented often encounter the same barriers.
Networking teams see additional logging as operational overhead, not their problem to solve. Platform engineers are concerned about the performance impact on recursive resolvers handling millions of queries per day. Storage costs for full DNS query logs at enterprise scale are non-trivial. Parsing and normalizing DNS logs for SIEM ingestion requires parser development and ongoing maintenance.
These are real concerns, but they are not usually the decision-makers in the conversation. What usually happens is that no one with enough organizational authority treats the detection gap as important enough to push through the friction. DNS logging lands in the backlog behind more visible security investments.
The visibility gap persists not because it is technically hard to close but because the tradeoff hasn’t been made. And the tradeoff doesn’t get made because the cost of the gap is invisible until an incident happens, and by then the data is gone.
What organizations need to do differently
The straightforward path is instrumenting the recursive resolver and forwarding structured DNS query logs to the SIEM with enough context to be useful: timestamp, querying host, queried domain, response type, resolved IP, query frequency.
From that foundation, a few detection categories become viable: beaconing detection based on query interval analysis, DNS tunneling detection based on query length and entropy, first-seen domain alerts against a baseline of historically resolved names, domain generation algorithm (DGA) detection using entropy and n-gram analysis, and matching against threat intelligence feeds for known-malicious domains.
None of this requires building custom tooling. Zeek, for environments with network taps, produces rich DNS logs natively. Recursive resolvers like BIND, Unbound, and Windows DNS Server can all be configured to produce query logs at sufficient granularity. Cloud DNS services — Route 53, Azure DNS, Google Cloud DNS — have logging options that can be routed to centralized security tooling.
The missing piece is almost never the technology. It is the organizational decision to treat DNS as a security data source rather than a networking utility.
Bottom Line
DNS is not exotic telemetry. It is foundational visibility into what every host in the environment is doing at the network layer. Every C2 channel, most lateral movement, and a significant fraction of data exfiltration attempts leave traces there.
Leaving DNS logs unanalyzed is not a gap that stays invisible. It is a gap that shows up in incident timelines, in attribution failures, and in post-mortems where the answer to “how long were they in” is measured in months because the data wasn’t there to say otherwise.
The plumbing metaphor is the problem. Treat it as infrastructure. Then treat the logs as evidence.