Domain Name System logs are records of DNS queries, responses and related resolver activity. They show which hostnames were looked up, when, from where, and what IP addresses or error codes were returned, which helps with troubleshooting, threat hunting and detecting suspicious name resolution patterns.
What DNS logs tell you
DNS logs give you a time-stamped record of name resolution activity, which makes them useful far beyond basic troubleshooting. They show which hostnames were queried, which clients asked, which resolvers answered and whether the lookup succeeded, failed or was redirected. That visibility turns DNS into one of the most practical telemetry sources for understanding normal behaviour and spotting anomalies.
Because DNS is a foundational control plane for almost every networked application, its logs often reveal activity before other telemetry does. A sudden spike in lookups, repeated failed resolutions or unusual domains can signal misconfiguration, malware, tunnelling, command-and-control beacons or data-exfiltration staging. For that reason, DNS logs are often analysed alongside endpoint, proxy and identity telemetry rather than in isolation.
Why DNS logging matters for security
DNS logs are valuable because they capture intent as well as outcome. Even when content is encrypted elsewhere, the request for a domain name can still expose reconnaissance, dependency discovery or malicious infrastructure use. That makes DNS logging a high-value source for threat hunting, incident scoping and baseline analysis.
Good DNS visibility also helps distinguish expected service behaviour from suspicious resolution patterns. Legitimate applications tend to reuse stable names and resolvers, while abuse often shows randomness, high cardinality, rapid subdomain churn or repeated lookups for domains that never resolve successfully. DNS Security Guide is a useful companion when you want the logging view in the context of protective DNS, tunnelling and sinkholing.
DNS logs also support correlation. When analysts can join resolver activity with device, identity or application logs, they can often reconstruct a sequence of events more quickly than from endpoint telemetry alone. Identity Telemetry Requirements helps frame why DNS data is strongest when it is part of a broader investigation dataset.
What to look for in DNS log data
The most useful fields are usually the query name, query type, response code, returned address, timestamp, client IP, resolver identity and any policy action taken. With those fields, defenders can spot patterns such as unusually high NXDOMAIN rates, unexpected lookups from servers that should be quiet, or repeated queries to domain families associated with newly registered or low-reputation infrastructure.
DNS logs are also valuable for spotting operational drift. Misconfigured applications may query nonexistent names, stale internal hostnames or split-horizon zones that no longer match routing reality. Over time, those errors can hide genuine attack activity by creating noise, so logging quality and retention are part of the defensive value of the dataset itself.
For teams that need a broader hunting method, Identity Threat Hunting Guide shows how DNS and other log sources can be turned into repeatable hypotheses rather than one-off investigations. That approach is especially useful when DNS is one of several signals pointing to the same host or session.
How DNS logs are used in investigations
During an investigation, DNS logs often answer three questions quickly: what was being resolved, when did the lookup start and from where did it originate. That makes them useful for scoping affected endpoints, identifying the first time a suspicious domain appeared and checking whether multiple systems contacted the same infrastructure.
They are also important after containment or remediation. If a suspicious domain was already queried, analysts can check whether the behaviour stopped after blocking, whether other hosts followed the same pattern and whether the resolver or client continued to attempt lookups. MITRE D3FEND Guide is helpful here because it connects DNS analysis to defensive techniques such as reputation analysis and protocol anomaly detection.
In practice, DNS logs are strongest when they are retained long enough to support retrospective review. Short retention can leave defenders unable to trace an incident back to its earliest observable network indicators, especially when the compromise is discovered late.
Logging quality and monitoring practices
DNS logging only becomes operationally useful when the organisation can collect it consistently, retain it for a meaningful period and search it at scale. That usually means centralising resolver logs, preserving enough context to tie a query back to a host or user and normalising fields so queries can be compared across environments. Identity detection rule pack can be useful for teams that want to turn telemetry into concrete detections across environments, including resolver-linked activity.
Monitoring should focus on deviations from baseline, not just outright failures. A resolver that suddenly sees a new domain family, an unusual volume of lookups or a shift in query geography may warrant review even if the requests technically succeed. The most effective programmes treat DNS logs as a first-class signal for detection, not just a troubleshooting artifact.
When DNS logs are paired with the right retention, alerting and investigation workflow, they become one of the fastest ways to see suspicious communication patterns before they turn into broader compromise.
Risk and Threat Considerations
DNS logs carry meaningful security value, but they also expose a great deal about internal behaviour. If they are incomplete, short-lived or poorly protected, defenders can miss early indicators of malware, tunnelling, domain generation activity or abusive infrastructure use. They can also lose the timeline needed to prove where suspicious name resolution began.
Failure mechanism: Adversaries often rely on DNS because it is pervasive, difficult to block outright and frequently monitored less rigorously than endpoint or proxy traffic. If logging is sparse or fragmented, the attacker can hide in ordinary resolution noise, use fast-changing domains or leverage compromised hosts to look routine.
Impact: The result can be delayed detection, weak scoping and incomplete post-incident reconstruction. Missed DNS evidence can also prevent teams from identifying other affected systems, which extends dwell time and increases the chance of repeated compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1071.004 — Application Layer Protocol: DNS | DNS logs directly surface abuse of DNS for command and control and other network activity. |
| Recommendation — Map DNS anomalies to T1071.004 and hunt for DNS-based command-and-control patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalous Activity | DNS logs are a core monitoring source for detecting unusual name-resolution behaviour. |
| Recommendation — Use DE.CM-01 to monitor DNS telemetry for anomalous resolution patterns and suspicious traffic. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | DNS logging depends on generating audit records that capture query and response activity. |
| AU-6 — Audit Record Review, Analysis, and Reporting | DNS logs only become useful when reviewed for anomalies, indicators and incident timelines. | |
| Recommendation — Apply AU-12 to ensure DNS infrastructure generates the audit records needed for investigation. Use AU-6 to review DNS logs for suspicious queries, failed lookups and recurring indicators. | ||
| CIS Controls v8 | 8 — Audit Log Management | DNS logs are audit data that must be collected, retained and reviewed centrally. |
| Recommendation — Use CIS-8 to centralise DNS logging, retain it appropriately and review it for threats. | ||
Practitioner Guidance
Why practitioners should care: Treat DNS logging as security telemetry, not just an operations artifact. The value comes from linking resolution data to assets and investigation workflows, so the log source needs ownership, retention and searchability rather than passive storage.
Common misunderstanding: A successful DNS response does not mean the activity was benign. Suspicious domains often resolve successfully, and many malicious campaigns depend on ordinary-looking lookups to reach staging, update or command infrastructure.
Practitioner takeaway: Prioritise DNS fields and retention settings that preserve investigation context, because once the resolution history is gone, much of the fastest path to scoping an incident disappears with it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org