DNS Logging Best Practices and SIEM Integration
DNS logging best practices for security teams: what to capture, where, how long to keep it, and how to stream clean logs into your SIEM, without slowing DNS down.
DNS logs are one of the first places a compromise shows up, which makes logging them well worth getting right for any security or IT team responsible for the network.
Most setups fail in one of two ways: they miss the traffic that matters, or they capture it but never get it into their SIEM in a usable form.
Done well, DNS logging means recording both queries and responses at a point that sees every device, and keeping them only as long as you need. From there, the logs stream to your SIEM in a form it can correlate with the rest of your security events.
TL;DR
- Log both queries and responses, not queries alone, so DNS hijacking and cache poisoning show up
- Capture logs where every device is visible, including roaming users and encrypted DNS
- Keep detailed logs for weeks and aggregated analytics for longer, aligned with your compliance and/or regulatory obligations
- Stream to your SIEM in a structured format it can parse, and let it handle detection
- Log server-side to get full queries and responses without slowing DNS down
The 5 DNS Logging Best Practices
1. Log Queries and Responses, Not Queries Alone
When you enable DNS logging, the extent to which you record DNS queries determines how useful the logs are later. At a minimum, every entry should capture:
- The timestamp
- The client IP or device identity
- The queried domain
- The record type
- The response code
- The resolver's decision, if you filter: allowed, blocked, or redirected
But don't just stop at query logging, since a query log only shows what a host asked for.
A response log shows the answer returned in the DNS message, which matters because, under DNS attacks like hijacking or cache poisoning, the query looks normal while the response directs the host to an attacker-controlled IP address.
Log the full DNS transaction, both query and response, so you can tie a suspicious lookup to the address it resolved to.
Control D logs both automatically. With Full Analytics at maximum granularity, each raw query log records the queried domain, the resolved IP address, the action taken, and other metadata, kept for up to 1 month. See the Analytics docs.
2. Capture Logs Where You Can See Every Device
There are three common places in your DNS infrastructure to capture logs, and each misses something:
- Recursive resolver: sees every query that reaches it, and nothing that does not
- Firewall or DNS forwarder: sees everything routed through that chokepoint, and nothing that takes another path
- The endpoint itself: sees that specific device, wherever it goes
Logging location decides visibility, something network administrators often overlook. Two gaps defeat on-network logging:
- Encrypted DNS: a device using DNS over HTTPS or DNS over TLS sends its DNS requests to a public resolver on port 443 or 853, bypassing your recursive resolver and your firewall rules entirely.
- Roaming users: a laptop on a home network or in a coffee shop never touches your corporate DNS at all.
For example, suppose a remote employee's device is compromised. The malware uses DoH to reach its command-and-control domain. That lookup never crosses your resolver or your firewall, so it never appears in your logs, and a review of recent DNS queries turns up nothing. You believe you have DNS visibility, but you actually have a hole the size of your remote workforce.
To close it, capture logs at the point every device uses, regardless of network: on the device itself or at a resolver those devices are always configured to query.
Control D captures queries at the resolver and through native clients installed on the device, so off-network and roaming machines stay visible under a single policy, giving you a complete view of DNS activity. You can read more about how DNS logging works across devices.
3. Set Retention and Storage Location to Match Your Obligations
Keep logs long enough to investigate an incident and meet the rules that apply to you, and no longer. Holding them longer than that adds regulatory risk without adding much value.
Full detail and long-term trends are worth keeping for different lengths of time:
- Detailed query logs earn their keep for a few weeks, long enough to investigate a specific incident.
- Aggregated analytics stay useful for much longer, for spotting trends and producing reports.
How long you keep either depends on your regulatory and compliance obligations, not a universal number. These matter because DNS logs often contain personal data, such as client IP addresses.
| Framework | What It Cares About for DNS Logs |
|---|---|
| GDPR | A lawful basis for logging personal data such as client IPs, data minimization, a defined retention limit, and control over where data is stored |
| HIPAA | Audit controls and access logging for systems that touch protected health information, with retention of DNS audit logs over a multi-year period |
| PCI DSS | Retention of logs for in-scope systems, with a defined minimum period and recent data kept readily available |
As rough anchors: PCI DSS requires a minimum of one year of log retention, and while HIPAA doesn't specify a DNS-log period, auditors commonly recommend around six years to match the broader policy-retention standard.
Treat these as starting points and confirm the minimum that applies to your industry, since those figures change over time.
A few more choices matter here:
- Storage location: where your logs physically sit can itself be a compliance requirement, so choose the jurisdiction deliberately.
- Access control: access to DNS logs should be restricted to authorized personnel, since the logs reveal what every user looked up.
- Privacy handling: where regulations require it, you can anonymize end-user IP addresses while keeping timestamped domain metadata, so you keep most of what you need to spot threats without holding raw identifiers longer than you should.
Control D handles this split for you. It keeps raw DNS query logs for up to a month and aggregated analytics for up to a year, and lets you store them in 3 default jurisdictions (North America, Europe, and Australia) or a location of your choice.
4. Stream Logs to Your SIEM in a Format It Can Use
DNS data is most useful when it sits next to the rest of your telemetry. Centralizing DNS logs makes them easier to correlate and harder to tamper with, and a SIEM is where that happens. A suspicious lookup can be tied to the endpoint that made it and the subsequent firewall event, then checked against threat intelligence that flags the domain, all on a single timeline.
Forwarding logs in real time via syslog or a webhook in structured JSON format lets your SIEM read the fields directly instead of you having to write and maintain code to parse them.
Control D forwards raw DNS query logs to SIEM tools like Splunk and Elastic as structured JSON, so there is no separate parsing step.
The full log stream should be sent rather than a trimmed-down version. DNS traffic is a high-volume source because the DNS protocol runs in front of almost every connection, which can tempt you to cut it down first. Keep it complete.
Blocking known threats happens at the resolver in real time, so the SIEM does not need a pre-filtered feed. Its role is different: analyzing DNS logs alongside the rest of your telemetry to correlate events and spot patterns like DNS tunneling or repeated lookups to malicious domains.
5. Capture Full Logs Without Slowing DNS Down
The reason many teams log less than they should is performance. On-box logging, whether DNS debug logging or the more detailed DNS analytical logging on Windows Server, writes to a log file on the resolver itself. It thereby adds I/O that can affect DNS server performance, so full query and response logging often gets switched off.
Server-side logging removes that tradeoff. When your resolver provider records logs on its own infrastructure, you get complete queries and responses with no I/O penalty on your resolver and no added latency for end users.
That is what makes the earlier practices affordable: you can log the full transaction, from every device, without choosing between visibility and speed. Control D logs server-side, so full-query fidelity does not slow down end-user queries.
DNS Logging Is Part of Wider DNS Security
Logging tells you what happened, which is useful, but it works best alongside the controls that prevent DNS attacks in the first place.
- Implementing DNSSEC ensures the authenticity of DNS responses
- DNS over HTTPS and DNS over TLS improve privacy, though they may reduce network visibility, the blind spot practice 2 covers.
- Regular auditing of DNS server configurations is necessary for compliance.
For the prevention controls specifically, see our guide to DNS security best practices.
Final Thoughts
Good DNS logging comes down to a few decisions:
- What you capture
- Where you capture it
- How long you keep it
- How it reaches your SIEM
- Doing all of it without slowing DNS down
Get those right, and your DNS logs become one of the earliest warnings you have when something on the network goes wrong.
Control D logs the full DNS transaction server-side: every device, every query and response, streamed to your SIEM as structured JSON, with no I/O penalty on your resolvers. Start a free trial or see plans and pricing.
Frequently Asked Questions (FAQs)
What is DNS logging?
DNS logging is the practice of recording the DNS queries devices make and the responses they receive, then storing them where they're useful, typically streamed to a SIEM for correlation with other security events. Done well, it captures the full query and response transaction from every device, including roaming and encrypted DNS traffic.
Does DNS logging slow down my network?
It depends on where logging happens. On-box query and response logging adds disk I/O that can affect a busy resolver, which is one reason it is often disabled by default. Logging performed server-side by your resolver provider does not add latency to end-user queries.
Do I need to log responses, or are queries enough?
Queries alone tell you what a host asked for. Response logging shows the answer it received, which is what exposes DNS hijacking and cache poisoning. Log both so you can tie a suspicious lookup to the address it resolved to.
How long should I keep DNS logs?
Keep them long enough to investigate an incident and to meet your compliance obligations, and no longer. A common approach is to keep detailed logs for a few weeks and aggregated analytics for longer. As anchors, PCI DSS requires a minimum of one year, and auditors commonly recommend around six years for HIPAA-aligned environments. Confirm the specific minimums that apply to your industry.
Can I log DNS for remote and roaming users?
Only if you capture logs at a point those devices always use. On-network resolver or firewall logging misses devices on other networks or using encrypted DNS. Device-level logging, or a resolver the endpoints always query, closes that gap.
What is the difference between DNS logging and DNS analytics?
Logging is the practice of recording DNS queries and responses correctly and getting them where they are useful. Analytics is what you do with that data afterward: dashboards and reporting. Our DNS analytics guide covers the second half.
