Safeguard 8.6: Collect DNS Query Audit Logs

Safeguard 8.6 requires you to collect and retain DNS query audit logs so you can reconstruct “who asked for what domain, when, and from where” during investigations and threat hunting. Operationalize it by logging DNS queries at your recursive resolvers (or DNS security service), centralizing them in your SIEM, and proving coverage, retention, and review with repeatable evidence. ¹

Key takeaways:

• Capture DNS query logs at the control point (recursive resolver/DNS filtering service), not on random endpoints.
• Centralize, normalize, and retain DNS logs with searchable fields that support investigations.
• Document control operation and recurring evidence capture so you can pass assessments for the safeguard 8.6: collect dns query audit logs requirement. ¹

DNS is one of the highest-signal telemetry sources you can collect without deep packet inspection. It records intent: which host tried to resolve which name, at what time, and through which resolver. That makes DNS query audit logs useful for detecting malware beaconing, command-and-control lookups, typo-squatting access, and policy violations, and for scoping incidents after the fact.

The practical challenge is that DNS logging often ends up fragmented: some logs live on a firewall, some in a cloud DNS service, some nowhere at all because endpoints use encrypted DNS directly to the internet. Safeguard 8.6 pushes you toward a defensible operating model: pick the authoritative control point(s) for DNS resolution, ensure all corporate systems use them, collect query logs consistently, and keep enough context for investigations.

This page translates the safeguard 8.6: collect dns query audit logs requirement into an implementation checklist a Compliance Officer, CCO, or GRC lead can drive with Security Operations and IT. It prioritizes what auditors ask for: clear scope, reliable log sources, retention and access controls, and evidence that the control runs continuously. ¹

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 8.6 implementation expectation (Collect DNS Query Audit Logs).” ¹

Operator interpretation: You must configure your environment so DNS query activity is logged and those logs are available for detection and investigation. In practice, “collect” means:

1. DNS queries flow through managed resolvers or a managed DNS security service,
2. query logs are generated with sufficient fields to attribute activity to a system/user/network segment,
3. logs are centralized and retained, and
4. you can produce evidence that collection is in place and working. ¹

Plain-English interpretation (what the requirement is really asking)

For every DNS lookup that matters to your organization, you should be able to answer:

• Which internal source initiated the lookup (host, IP, device identity, sometimes user)?
• What was queried (FQDN, record type)?
• When it happened (accurate timestamp, time zone handling)?
• What the resolver returned (response code, resolved IPs where available)?
• Which DNS path was used (resolver identity, site/region, policy action)?

If you can’t answer those questions from logs in your central logging platform, you have a control gap, even if “some DNS logs exist somewhere.”

Who it applies to

Entities: Enterprises and technology organizations adopting CIS Controls v8. ¹

Operational contexts where this is in-scope:

• Corporate networks and offices where internal clients use recursive DNS.
• Cloud networks (VPC/VNet) where workloads resolve names for outbound connectivity.
• Remote workforce traffic, if you provide corporate DNS via VPN, secure web gateway, or endpoint DNS agent.
• Third-party managed DNS security providers, if they handle resolution or filtering for you (you still own the evidence and retention story).

Systems typically in scope:

• Recursive resolvers (on-prem DNS servers, DNS forwarders).
• DNS filtering/security platforms (cloud-based resolvers).
• Infrastructure that enforces DNS routing (firewall rules, DHCP options, endpoint configuration, VPN profiles).

What you actually need to do (step-by-step)

Step 1: Define DNS “collection boundaries” (scope and control point)

1. Identify all approved recursive resolvers and DNS security services.
2. Identify where DNS can bypass those resolvers (direct-to-internet UDP/TCP 53, DoH/DoT).
3. Write a short scope statement: “All corporate-managed endpoints and workloads must use approved resolvers X/Y; DNS query logs from those resolvers are centrally collected.” Keep it crisp so an auditor can map it to reality.

Deliverable: A DNS logging scope statement and a resolver inventory tied to network segments and cloud accounts.

Step 2: Force traffic through the logged resolvers

1. Configure DHCP, endpoint management, VPN profiles, and cloud VPC/VNet settings to point to approved resolvers.
2. Add network controls to reduce DNS bypass (at minimum for direct UDP/TCP 53; address DoH/DoT based on your architecture).
3. For remote endpoints, decide: full tunnel (DNS goes through VPN) or endpoint DNS agent that logs centrally.

Audit expectation: You can explain how you prevent or detect systems that do not use the logged DNS path.

Step 3: Enable DNS query logging with the right fields

Turn on query logging at each resolver/control point and confirm you capture:

• Client source IP (or internal device identifier if the platform provides it)
• Queried name (FQDN)
• Query type (A, AAAA, TXT, etc.)
• Timestamp
• Response code / action (allowed, blocked, sinkholed) where available
• Resolver identity (which server/service processed it)

If you use multiple DNS platforms (on-prem + cloud), standardize field names during ingestion so searches work across sources.

Step 4: Centralize logs into your SIEM or log platform

1. Configure log export (syslog, API, streaming) from resolvers/DNS services into your centralized logging system.
2. Normalize parsing (FQDN field, response code field, client IP field).
3. Set access controls: DNS logs can contain sensitive browsing indicators; restrict access to least privilege.

Step 5: Set retention and retrieval requirements you can defend

CIS Safeguard 8.6 does not provide a retention duration in the provided excerpt, so treat retention as a risk decision. Document:

• Your retention period (hot vs archive, if applicable)
• How quickly you can retrieve logs for investigations
• Integrity controls (immutability settings, write-once storage if you use it, or equivalent controls)

Practical tip: Align DNS log retention with your incident response lookback needs and any overlapping internal policy requirements, then make that the single standard you test against.

Step 6: Create “proof of operation” and recurring evidence capture

Assessors rarely fail teams for missing a feature; they fail teams for missing evidence the feature is operating. Put the control on rails:

• Weekly or monthly spot-check searches in the SIEM for each resolver source.
• Alert on logging gaps (no events from resolver X for N hours) with a ticket created in your ITSM system.
• Quarterly access review for DNS logs (who can read them, who can change ingestion).

This directly supports the recommended control to “map 8.6 to documented control operation and recurring evidence capture.” ¹

Required evidence and artifacts to retain

Use this as an evidence checklist for the safeguard 8.6: collect dns query audit logs requirement:

Design evidence (what you intended to build)

• DNS architecture diagram showing approved resolvers and traffic paths
• Resolver/service inventory (name, location, owner, log export method)
• DNS logging standard (fields collected, retention target, access controls)

Operational evidence (what is actually running)

• Screenshots or exports showing query logging enabled on each resolver/service
• SIEM ingestion configuration (connectors, parsers, data mappings)
• Sample DNS log events in the SIEM showing key fields populated (client IP, FQDN, timestamp, action/rcode)
• Logging gap alerts and tickets (show detection and response to missing logs)
• Recurring evidence record (monthly control check results)

Governance evidence (who owns it and how it’s reviewed)

• Control narrative mapped to CIS Safeguard 8.6
• RACI (IT owns resolver config, SecOps owns SIEM, GRC owns testing cadence)
• Exception register entries for segments that cannot route DNS through approved resolvers, with compensating controls and a sunset date

If you manage evidence in Daydream, structure the control record around (a) scope, (b) log sources, (c) retention, and (d) recurring checks so audits become a repeatable export instead of a scramble. ¹

Common exam/audit questions and hangups

Auditors and internal assessors tend to focus on:

• Coverage: “Which networks/endpoints are forced to use your resolvers?”
• Completeness: “Do you log both allowed and blocked queries?”
• Attribution: “Can you tie a query back to an asset owner or device identity?”
• Continuity: “How do you detect when DNS logs stop flowing?”
• Retention: “How long are logs kept, and who approved that decision?”
• Access control: “Who can read DNS logs, and how is access reviewed?”

Hangup: encrypted DNS bypass. If endpoints can use DoH directly, you might still have DNS logs at the endpoint security layer, but you must document that as your collection point and show consistent centralization.

Frequent implementation mistakes (and how to avoid them)

1. Logging only at the firewall, not at the resolver. Firewalls may see port 53 but miss resolver context and responses. Fix: treat recursive resolvers/DNS security services as the authoritative log source.

2. No central searchability. Logs exist on a DNS server but are not in the SIEM. Fix: centralize and normalize fields so IR can query by host, user, domain, and time window.

3. Partial scope with no exceptions process. Teams forget cloud workloads, OT segments, or remote users. Fix: define scope and maintain an exception register with owners and compensating controls.

4. No monitoring for ingestion breaks. A connector fails and nobody notices until an incident. Fix: alert on log-source silence and require ticketed resolution.

5. No evidence rhythm. The control works, but you can’t prove it over time. Fix: recurring evidence capture with a lightweight monthly test script and saved results.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard. Treat this as a practical security control that often becomes indirectly enforceable through broader obligations (incident response readiness, security monitoring, and auditability) in your own regulatory perimeter. Your risk is operational: without DNS query logs, investigations take longer, scope is less reliable, and detection coverage for common threat behaviors drops. ¹

Practical 30/60/90-day execution plan

Because the provided sources do not specify implementation timelines, use a pragmatic phased plan.

First 30 days (stabilize scope and sources)

• Name an owner for DNS logging (one throat to choke across IT + SecOps).
• Inventory resolvers and DNS services; confirm which ones can generate query logs.
• Decide the “approved resolver” list and document the scope statement.
• Prove ingestion for at least one major environment (corporate HQ, primary cloud account, or DNS security provider) into the SIEM with searchable fields.

Day 31–60 (expand coverage and add controls)

• Route remaining segments through approved resolvers (branch offices, additional cloud networks, remote access patterns).
• Implement log continuity monitoring (alert when a resolver stops sending logs).
• Define retention and access controls, and document the decision in your control narrative.
• Run your first formal control test and store evidence.

Day 61–90 (audit-proofing and operational maturity)

• Close remaining exceptions or document compensating controls with deadlines.
• Add IR playbook steps that explicitly call for DNS log review and the queries analysts should run.
• Establish a recurring evidence capture schedule and assign it in your compliance calendar.
• In Daydream (or your GRC system), finalize the control mapping for Safeguard 8.6 with attached artifacts and a repeatable test procedure. ¹

Frequently Asked Questions

Do we meet Safeguard 8.6 if we only keep DNS logs in our DNS provider’s console?

You can start there, but assessors usually expect centralized access for investigations and continuity monitoring. Export logs to your SIEM or log platform and retain evidence of ongoing collection. ¹

Are endpoint DNS logs acceptable if we can’t force all traffic through a recursive resolver?

Yes, if endpoint telemetry is your true control point and it captures query details consistently across the in-scope fleet. Document the architecture choice, scope boundaries, and how you prove completeness and retention. ¹

What fields must be in a DNS query audit log?

Capture client identifier (at least source IP), queried name, timestamp, and enough resolver context to reconstruct what happened. Add action/response code and resolver identity where your platform supports it. ¹

How do we handle encrypted DNS (DoH/DoT)?

Decide whether you will block/bypass unmanaged DoH/DoT, route it through managed resolvers, or collect equivalent logs at the endpoint agent layer. Whatever you choose, document it and show evidence that the chosen logging source is complete for the stated scope.

Who should own this control: IT or Security?

IT typically owns resolver configuration and traffic steering; Security owns SIEM ingestion, detections, and investigations. GRC owns the control narrative, testing cadence, and evidence retention.

What’s the minimum evidence an auditor will accept for 8.6?

A documented control description, proof that query logging is enabled on in-scope resolvers/services, sample events in the SIEM showing required fields, and records of recurring checks that logs continue to flow. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8