Log DNS queries and responses centrally so investigators can see which hosts resolved which domains and when. Capture enough detail to link clients, query types, response codes and resolver behaviour, then retain records for hunting and incident response. Secure the logs, review them for anomalies, and alert on suspicious domains, tunnelling or repeated lookup failures.
What DNS logging should capture
Good DNS logging starts with record quality, not volume. The most useful logs show who asked, what they asked for, when it happened, which resolver answered, and how the exchange ended. That means query names, query types, response codes, client or source context, and resolver behaviour are captured in a way that investigators can correlate across endpoints, resolvers, and network telemetry.
DNS logs are strongest when they preserve enough context to reconstruct both normal resolution and suspicious edge cases. If your logging collapses repeated failures, strips client identifiers, or omits response detail, you lose the ability to distinguish misconfiguration from brute-force domain discovery, tunnelling, or selective blocking.
For practitioners building or reviewing DNS telemetry, the key question is whether the log can answer an incident-response question later, not whether it can support a dashboard today.
How to centralise and protect DNS telemetry
Centralisation is the difference between operational logging and forensic evidence. Forward DNS logs off the resolver or recursive layer to a hardened logging platform so local compromise, log truncation, or simple retention limits do not erase the trail. DNS Security Guide is a useful broader reference when you are tying logging to resolver security, sinkholing, and DNS tunnelling detection.
Protect the logs with the same seriousness as other security telemetry. Restrict access, preserve integrity, and make sure time synchronisation is reliable enough that DNS events can be compared with endpoint, proxy, and authentication logs without guesswork. If timestamps drift or logs are editable by too many administrators, the data may still exist but no longer support trustable investigations.
Retention should match investigative need, not only storage convenience. Short retention can be enough for routine troubleshooting, but incident response and threat hunting often require a longer view so you can trace slow-moving campaigns, rare lookups, or staging behaviour that does not appear in a narrow time window.
What DNS logs help you detect
DNS logs are particularly valuable because many malicious behaviours leave a name-resolution trail even when other controls miss them. Repeated lookup failures, unusual domain age patterns, high-entropy subdomains, spikes in NXDOMAIN-like behaviour, and short bursts of many distinct domains can all indicate abuse. So can requests to domains that do not match the host’s normal role or geography.
Alerting works best when it is tuned to behaviour, not only static blocklists. Suspicious domains, DNS tunnelling patterns, and resolver anomalies are easier to catch when the logging pipeline can compare current activity with baseline behaviour and flag deviations quickly. DNS logs also help distinguish a real outage from a poisoned, misrouted, or manipulated resolution path.
Well-tuned detection is less about reading every query manually and more about giving analysts enough structured data to pivot from one weird lookup to the broader activity around it.
Risk and Threat Considerations
DNS logging gaps create blind spots in one of the most widely used control planes in the environment. If query detail is incomplete, centrally unavailable, or retained too briefly, investigators may miss command-and-control lookups, data exfiltration over DNS, or simple reconnaissance that never touches higher-layer monitoring.
Failure mechanism: Attackers and misbehaving software can hide in normal resolution traffic, while defenders lose evidence when logs omit source context, response detail, or resolver behaviour, or when local logs are overwritten before review.
Impact: The organisation loses the ability to prove what resolved, from where, and when, which weakens hunting, slows containment, and makes it harder to separate legitimate misconfiguration from malicious activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | DNS logging is audit logging that must be centralised and reviewed. |
| Recommendation — Centralise DNS logs and review them for suspicious resolution patterns. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | DNS logs must be reviewed and alerted on to detect anomalies and attacks. |
| AU-9 — Protection of Audit Information | DNS logs need integrity, access restriction, and secure retention. | |
| Recommendation — Analyze DNS audit records for anomalies and suspicious domains. Protect DNS logs from unauthorized access, alteration, and premature loss. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | DNS telemetry is network monitoring used to detect suspicious resolution activity. |
| DE.CM-07 — Monitoring for unauthorized personnel, connections, devices, and software is performed | DNS logs help identify unauthorized or unusual client lookups and resolver behaviour. | |
| Recommendation — Monitor DNS activity continuously for abnormal patterns and suspicious lookups. Correlate DNS logs with other telemetry to spot unauthorized or unusual activity. | ||
Practitioner Guidance
What to verify: Confirm that every resolver and recursive layer sends logs to a central system, that the recorded fields are sufficient for investigation, and that retention exceeds the longest realistic detection window you expect to support.
Decision rule: If you cannot correlate DNS logs with endpoint or network telemetry by host and time, treat the logging design as incomplete even if the resolver appears to be “logging everything.”
What good looks like: Analysts can trace one suspicious query from client to resolver to response without relying on packet captures, and can quickly tell whether repeated failures are routine noise or part of a broader pattern.
Practitioner takeaway: DNS logging is only useful when it preserves enough context to reconstruct behaviour later, then keeps that evidence available, protected, and searchable when an incident actually happens.