DNS Logging records DNS queries and responses so defenders can see which names were requested, by which systems, and what answers were returned. It supports threat hunting, malware investigation, and detection of suspicious domains, fast-flux behaviour, or data exfiltration through DNS. Keep logs centralised, time-synchronised, and protected from tampering.
What DNS Logging actually records
DNS logging is strongest when you treat it as protocol telemetry, not just a troubleshooting aid. Each record should tell you what was queried, which resolver or client asked for it, what response came back, and when that exchange occurred. That gives defenders a time-ordered view of name resolution activity, which is often the earliest visible sign of a system reaching out to infrastructure that should not be there.
Because DNS is highly central to normal connectivity, the log value comes from context. A single lookup is rarely meaningful on its own, but patterns of repeated failures, rare domains, fast-changing answers, or unexpected query volumes can expose malware, tunnelling, or command-and-control activity. For a broader view of where DNS fits into defensive visibility, the DNS Security Guide covers logging alongside other DNS defensive controls.
Where DNS logs are collected and how they are used
Most organisations collect DNS logs from recursive resolvers, forwarders, security appliances, or managed DNS services. In practice, the most useful deployment is the one that captures both client-facing lookups and resolver-side answers, because that pairing lets analysts connect a host to the domain it requested and the IP or record data it received. If you only have one side, you usually lose attribution or response context.
Once centralised, DNS logs become a hunt source for security operations. Analysts correlate them with endpoint, proxy, firewall, and authentication logs to answer questions such as which host looked up the suspicious domain first, whether many hosts queried the same pattern, and whether the lookup was followed by a connection attempt. That correlation is what turns DNS from a utility record into a detection layer.
Why DNS logging works best as a detection signal, not a standalone control
DNS logging is valuable because many adversaries need DNS even when they are trying to hide. Malware still has to resolve infrastructure, beaconing often leaves domain churn behind, and data exfiltration through DNS tends to create abnormal query shapes or unusually high volumes. Logging makes those behaviours observable, but it does not block them by itself.
That is why the quality of the log pipeline matters as much as the data itself. Logs need accurate timestamps, retention that matches investigative needs, and access controls that prevent alteration or deletion. Without that, the same dataset that should support investigation can become unreliable evidence or a blind spot during incident response.
Risk and Threat Considerations
DNS logs can reveal both attacker infrastructure and defender blind spots, so their protection matters as much as their collection. If the logs are incomplete, out of sync, or easy to tamper with, you lose the ability to reconstruct early compromise, distinguish benign lookups from malicious ones, and prove where a suspicious domain first appeared.
Failure mechanism: Adversaries and insiders can exploit weak retention, poor time synchronisation, or insufficient write protection to obscure beaconing, hide tunnelling, or erase the trail from a compromised host to an external domain.
Impact: Missed detections, weaker incident reconstruction, and reduced confidence in forensic timelines can delay containment and allow the same infrastructure to be reused elsewhere in the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 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 telemetry that needs collection, retention and protection. |
| Recommendation — Centralise and protect DNS audit logs for hunting and incident reconstruction. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | DNS queries and responses are logged events used for detection and forensics. |
| AU-9 — Protection of Audit Information | DNS logs must be protected from tampering to remain trustworthy evidence. | |
| AU-12 — Audit Record Generation | DNS logging depends on generating the right records at resolver or service level. | |
| Recommendation — Define DNS events to log so detection and investigations have the needed evidence. Restrict and harden DNS log storage so records cannot be altered or deleted. Enable generation of DNS audit records at the systems that observe resolution activity. | ||
Practitioner Guidance
What to verify: Confirm that DNS logs include the query name, source, response, resolver identity, and timestamp, and that the timestamps are aligned across the systems you will correlate during an investigation. If any of those fields are missing, the data may still be useful for trending, but it is weaker for attribution and incident reconstruction.
What good looks like: Centralised DNS logs should be retained long enough to support retroactive hunting, protected from modification, and searchable alongside endpoint and network telemetry. The most useful operational outcome is not raw volume of logs, but the ability to pivot quickly from a suspicious domain to affected hosts and related activity.
Practitioner takeaway: DNS logging is most effective when it is treated as durable investigative evidence and joined with other telemetry, not as a standalone record of lookups.