Nobody Puts DNS Logs in the SIEM

DNS is the protocol your organization cannot turn off. Every device queries it constantly. Applications, endpoints, servers, printers, security appliances - all of them rely on DNS for basic function. And in most organizations, almost none of those queries are inspected, logged to a security system, or analyzed for anomalies.

This is not a new problem. Researchers published detailed analysis of DNS tunneling and data exfiltration over DNS in the early 2000s. Malware has used DNS for command-and-control for nearly two decades. The techniques are documented, the tools are mature, and the detection approaches are well-understood. Organizations still, on average, have almost no DNS monitoring.

Why DNS Gets Ignored

Part of the answer is volume. A medium-sized organization generates tens of millions of DNS queries per day. The vast majority are noise - browser lookups, CDN traffic, telemetry, operating system calls. The sheer quantity discourages logging it at all, and when teams do log it, they rarely feed it into security monitoring because the per-event enrichment and analysis seems impractical.

The other part is that DNS traffic does not look like a security event. It looks like infrastructure. Firewall teams manage DNS rules, not security operations. The resolver is often managed by the network team. The question of who owns DNS monitoring falls into the same organizational gap where network security and endpoint security responsibility overlap without clear ownership.

The result is a channel that is effectively transparent. Attackers know this. Traffic that would trigger immediate investigation if it appeared on TCP port 443 flows out through DNS unexamined.

What Attackers Do With It

DNS tunneling is the established exfiltration technique. The attacker registers a domain and runs an authoritative nameserver. Malware on your network encodes data in DNS query hostnames - long, base64-encoded subdomains that resolve to the attacker's server. The server sees each query, decodes the encoded segment in the subdomain, and assembles it into the exfiltrated data stream. Responses encode data going the other direction. The entire bidirectional channel sits inside DNS queries and responses, which most firewalls pass without inspection.

The encoded subdomains are detectable. They are long - often 50 to 100 characters per subdomain label. They have high entropy, looking like random strings rather than meaningful names. They occur in high volume to the same parent domain. None of this looks like typical DNS traffic. It looks exactly like what it is, to anyone who is looking.

Command-and-control over DNS is a variation used by malware that wants to avoid maintaining direct IP connections. The malware issues periodic DNS queries to discover the current location of its command server, using TXT records or IP addresses embedded in A record responses as the communication mechanism. The malware never establishes a persistent TCP connection that endpoint or network detection might flag. Its only external behavior is DNS queries that look superficially like ordinary name resolution.

DNS hijacking operates at a different layer. An attacker who compromises your domain registrar account or your DNS hosting provider can modify your authoritative records. Email gets redirected to servers they control. Users attempting to reach your applications get served convincing replicas of those applications, credentials harvested, sessions captured. This attack happens entirely above your network perimeter. Your perimeter controls assume DNS is resolving correctly and are irrelevant once the records themselves are wrong.

What Detection Actually Looks Like

The detection categories that produce signal without drowning in noise:

Queries to newly registered domains. Threat actors register domains close to the time of use. First-seen domain queries - domains appearing in your logs for the first time within a few weeks of their registration date - are worth correlating against other signals. This is not a stand-alone alert, but it narrows investigation scope meaningfully.

Long subdomain labels. Legitimate CDNs and analytics platforms produce some long random subdomains, but there is a distinguishable pattern to tunneling payloads - high entropy, consistent length, repetitive structure. A threshold of roughly 40 characters in a subdomain label flags most tunneling with manageable false positive rates, especially combined with client identity and query volume.

Anomalous query rates. DNS tunneling is data-intensive. Moving meaningful exfiltration volume requires many queries per minute to the same parent domain. A workstation issuing several hundred queries per minute to an external domain it had not previously contacted is not background noise.

Unusual record types. TXT and NULL record queries from workstations - rather than from mail infrastructure - are uncommon in legitimate operations and common in DNS-based C2. Tracking which clients query TXT records against external domains identifies a small set of interesting endpoints.

The Registrar Attack Surface

DNS hijacking risk exists at the registrar, not just on the network. Most organizations have not applied meaningful access controls to registrar accounts that represent the keys to their entire domain infrastructure.

Registry lock prevents automated modifications to domain records without out-of-band confirmation. Most registrars offer it for domains that should be stable. Most organizations have not enabled it because the registrar account security posture has never been reviewed.

MFA on registrar accounts is a baseline requirement that a meaningful portion of organizations have not implemented. The registrar account has access to redirect every service on your domain. It warrants the same treatment as production infrastructure access - which is to say, considerably more scrutiny than it typically receives.

DNSSEC provides cryptographic verification of DNS responses, making record tampering detectable by resolvers that validate signatures. Adoption is low because the operational complexity is real and the benefit is not user-visible. For organizations where DNS hijacking represents a specific threat - financial services, healthcare, any organization with high-value authentication endpoints - DNSSEC is the right investment.

The Practical Starting Point

The starting point is logging, not analysis. Enable query logging on your internal DNS resolvers. Route those logs to wherever your security team can see them. Even without sophisticated detection logic, having the logs available shortens investigation time substantially when an incident surfaces - you can answer "was this endpoint querying unusual domains in the weeks before we noticed the compromise?" instead of not knowing.

The attacker assumption is correct: your DNS is unmonitored. The question is whether to leave that assumption valid.