What Safeguard 8.6 requires for DNS query logs and why it is hard to show
Safeguard 8.6 asks the enterprise to collect DNS query audit logs from enterprise assets where that is appropriate and the asset supports it. If you are an IG2 enterprise preparing for a CIS assessment, the first task is not turning on a resolver log. It is deciding which assets and resolvers fall inside the appropriate-and-supported test, and writing that decision down in a form an assessor can follow. CIS places 8.6 in the Data asset class and the Detect security function, and assigns it to Implementation Groups 2 and 3 only, so an IG1 organization is not measured against it. Its placement in Data reflects that DNS records show which hosts looked up which names, which makes it a record of data flow and communication, while its Detect function reflects its use in finding suspicious lookups after the fact.
The hard part is the judgment in "where appropriate and supported." CIS does not list which resolvers, forwarders or cloud DNS services count, and it does not say how much volume or retention is expected. The CIS Controls Assessment Specification defines what to measure, not how to measure it, and for 8.6 it combines three measures into one metric, DNS configuration coverage. Its stated prerequisites are Safeguard 1.1, the enterprise asset inventory, and Safeguard 4.1, the secure configuration process, because the measurement depends on knowing which assets exist and how they are configured. Start by reconciling your inventory against every DNS source you operate, including internal resolvers, endpoint agents and cloud-managed DNS. Each excluded source needs a documented reason tied to what the platform can do.
Evidence is where most reviews stall. An assessor will want configuration output from each in-scope resolver showing query logging is enabled, a record of the exclusions and the reasoning behind them, and sample log entries that prove collection reaches your log store. For a self-hosted stack, the OPNsense Suricata output in EVE JSON format can record DNS transactions as a separate stream, which is a source to confirm against your own build rather than assume. Ask your implementation partner and your independent assessor to agree on the exclusion record and the sample-retrieval method before the assessment begins, because CIS leaves those choices to you.
Which DNS resolvers, assets and logs fall under Safeguard 8.6
Safeguard 8.6 applies only where DNS query logging is appropriate and supported, so the scope is set by which resolvers exist and which assets can produce the logs. Each card below is a decision or check that changes the measured coverage, and the inventory and secure configuration work behind them determines how defensible those decisions are.
Internal recursive resolvers
Start with the resolvers the enterprise operates itself, such as Active Directory domain controllers running DNS or dedicated recursive servers in data centers. These are usually in scope because they see queries from many assets at once. Confirm which resolver software runs on each, whether query logging can be enabled on it, and where the logs are sent. A resolver that answers queries but cannot log them still needs a documented reason.
Cloud-managed DNS services
Cloud accounts often resolve names through provider-managed resolvers or private zones with their own query logging settings. Each account, VPC or virtual network that resolves internal names should be listed. Confirm whether query logging is enabled per resolver or per network, which account owns the log destination, and whether logs reach the same central store as on-premises resolvers.
Endpoint and forwarder paths
Workstations and servers often send queries directly to a public resolver, a router, or a local stub resolver that forwards upstream. Queries that bypass the enterprise resolver leave no record in the central logs. Map each forwarder hop, decide whether the forwarder or the endpoint is the logging point, and record any path that cannot be logged so the gap is visible to the assessor.
Assets that support query logging
Safeguard 8.6 applies only where the asset supports DNS query logging. A firewall or security appliance that inspects DNS may produce useful records through its own log export, and Suricata's EVE output can write DNS transactions as JSON records for a log management tool. Confirm the exact log fields and export format each asset produces before counting it as covered.
Excluded assets and documented rationale
Some assets will not be appropriate for query logging, such as isolated devices with no DNS function or systems where logging would break a supported application. Each exclusion needs a written rationale, an owner, and a review point, recorded in the audit log management process from Safeguard 8.1. An undocumented exclusion looks the same to an assessor as a missed asset.
Inventory and configuration prerequisites
The CIS assessment specification treats Safeguards 1.1 and 4.1 as prerequisites for measuring Safeguard 8.6. The enterprise asset inventory from 1.1 defines which resolvers and assets exist, and the secure configuration process from 4.1 records which logging settings each asset should have. Without those two records, the three measures for Safeguard 8.6 have no reliable denominator, so coverage cannot be calculated.
How to enable DNS query logging and document the exceptions
This sequence takes an organization from a verified asset inventory to DNS query logs that reach the central store, with every excluded asset recorded and its coverage reviewed on a set schedule.
Confirm the enterprise asset inventory
The IT or security operations lead confirms that the enterprise asset inventory from Safeguard 1.1 is current and lists every DNS resolver, recursive server, forwarder and endpoint class in scope. Assets missing from the inventory cannot be measured later, so gaps are closed here by adding records or confirming retirements. The output is an inventory extract that names each candidate DNS source, its owner and its location. The step is done when the inventory owner signs off that no in-scope resolver is unlisted.
Identify resolvers and endpoints that can log queries
The security engineering team reviews each listed asset to determine whether it can record DNS queries, whether the feature is built in, licensed or requires a separate agent, and which fields it captures, such as client address, query name, record type and response code. Vendor documentation and a test query on a non-production instance confirm the capability rather than assumptions. The output is a capability matrix that marks each asset as supported, supported with a plugin or agent, or not supported. The step closes when every asset has a recorded answer.
Enable query logging with the required fields
The platform team enables DNS query logging on each supported resolver or endpoint according to the secure configuration process from Safeguard 4.1, and sets the fields that the detection and investigation teams have agreed to need. Changes go through the normal change process, and logging levels are checked against available storage and performance headroom. The output is a configuration record for each asset, with the change ticket reference and the date enabled. The step is done when a test query appears in the local log with the agreed fields present.
Route DNS logs to the central store
The logging team forwards DNS query logs from each enabled source to the centralized log platform used for Safeguard 8.9, using a secure transport and the time source established under Safeguard 8.4 so that timestamps correlate with other sources. The output is a list of active log sources in the central platform, with the most recent event time for each. The step closes when a sample query made on each source is searchable centrally within the retention settings defined by the audit log management process.
Document unsupported or inappropriate assets with reasons
The asset owner and the security lead record every in-scope asset that cannot or should not log DNS queries, giving a specific reason such as no native capability, performance impact on a constrained device, or a documented operational restriction. Each exception names a compensating measure, such as logging at the upstream resolver, and an approver. The output is an exception register that the audit log management process references. The step is complete when every asset without a log source has an approved entry with a reason and a compensating measure.
Set a coverage review and record the results
The security governance lead sets a recurring coverage review that compares the asset inventory against the active DNS log sources and the exception register, flagging new assets, failed log sources and expired exceptions. The review cadence is recorded in the audit log management process, and each review produces dated minutes and an updated coverage metric. The output is a coverage report that shows which assets send DNS queries to the central store and which are covered by an approved exception. The step is done when the first review has been completed and filed as evidence.
How an assessor tests the DNS configuration coverage metric
When a cloud or DNS provider runs the resolver, the assessor first asks whether the organization can show that queries from its in-scope assets pass through that resolver and that its logs can be obtained. The assessor usually starts from the enterprise asset inventory (Safeguard 1.1) and the secure configuration process (Safeguard 4.1), then checks which resolver each asset is pointed at. Coverage is judged on configuration evidence, not on the provider's description of its logging.
- Resolver assignment per asset. The assessor compares DHCP scopes, endpoint network settings and virtual network configuration exports against the inventory to confirm each in-scope asset uses the managed resolver.
- Log export settings. Evidence is a dated configuration export or screenshot showing query logging enabled, the log destination and the retention setting, with a named owner.
- Missing assets. Common finding: laptops on home networks, guest Wi-Fi, build agents or containers that use a hard-coded public resolver and never reach the managed service.
- Undocumented exclusions. Common finding: a subnet excluded from logging with no written justification, approval or review date.
- Logs collected but not retained. Common finding: query logs sit in a provider console with a short default window the organization never extended, so the assessor cannot sample an older period.
Before the assessment, confirm with the provider which query logs it keeps, for how long, and whether they can be exported to your log platform in a readable form.
When the organization runs its own resolver, the assessor treats the resolver host as an in-scope enterprise asset and tests its configuration directly. The sampling is more concrete: the assessor can read the resolver's logging settings, confirm that the logs leave the host and check that the forwarding pipeline has not silently stopped. The CIS Controls Assessment Specification for Safeguard 8.6 is the authority on what each measure must show, so confirm the exact wording there before writing procedures.
- Resolver configuration review. The assessor reads the resolver configuration to confirm query logging is enabled and that the log path or output is set, not left at a default that writes nowhere useful.
- Forwarding to a central store. Evidence is a sample of recent DNS records in the SIEM or log platform, matched against records on the resolver host for the same time window.
- Network sensor coverage. Where a network IDS or IPS produces DNS records, for example through Suricata's EVE JSON output with the DNS protocol enabled, the assessor checks that the sensor sees the traffic it is supposed to see.
- Gaps in forwarding. Common finding: logs written locally but never shipped, or a forwarder that failed months ago with no alert.
- Retention on the resolver. Common finding: local log rotation that deletes records faster than the central store collects them.
Before the assessment, run a controlled lookup from a test asset and confirm the record appears in the central store.
When the resolver cannot be controlled, for example on devices that roam between networks, endpoint-level logging is often the only way to record DNS queries. The assessor then samples endpoints rather than resolvers. The sample should reflect the inventory across operating systems, device types and locations, so the assessor checks whether the logging agent is present and reporting on each sampled device.
- Agent coverage against the inventory. The assessor compares the agent's management console or deployment report with the device inventory and looks for enrolled devices that never report.
- Operating system differences. Logging features and configuration methods differ between operating systems, so the assessor expects evidence for each platform in scope rather than one general statement.
- Offline and roaming devices. Common finding: laptops that report only when on the corporate network, leaving DNS activity from remote periods unrecorded.
- Tampering and disabled agents. The assessor asks how the organization detects a stopped or removed agent and whether users can disable it.
- Retention and central collection. Common finding: endpoint logs kept on the device with a short local window, or forwarded to a store that does not hold them for the period the audit log management process requires.
Before the assessment, pull a device report for each platform in scope and reconcile it against the inventory, noting every exclusion with its reason.
Evidence that shows DNS query logging is in place
An assessor testing Safeguard 8.6 needs to see which DNS sources exist, that query logging is switched on for them, and that the logs actually arrive and are kept. The cards below tie each artifact to one link in that chain, so the evidence set can be refreshed between audits instead of rebuilt before them.
Asset inventory extract for DNS sources
Start with an extract from the enterprise asset inventory (Safeguard 1.1) that lists every resolver, forwarder and DNS-serving host, with owner, location and whether it is in scope. This is the denominator for coverage. Check that cloud-managed resolvers and endpoint DNS settings appear, since assessors often find those missing. Store the extract with its generation date and the query used to produce it.
Resolver configuration exports
Export the query logging settings from each in-scope DNS resolver and save them as dated files. The export should show that query logging is enabled and where the log output goes. Compare exports against the secure configuration baseline from Safeguard 4.1, because that baseline is what keeps logging from being disabled silently after a change. Record who approved each exported configuration.
Sample log records with timestamps
Keep representative DNS query records from each source, with the timestamp, client address, queried name and response code visible. Pull samples from different days so the assessor can see continuity rather than a single test entry. Check that timestamps are synchronized with the time sources from Safeguard 8.4, because uncorrelated clocks make the records hard to use in an investigation.
Collection pipeline configuration
Document the path from each resolver to the log store, including forwarders, agents, syslog settings and any parsing rules. Keep the configuration files under version control so each change has an author and a date. Confirm that the pipeline reaches the centralized store described for Safeguard 8.9 and that the retention setting covers at least the period in the audit log management process.
Documented exclusions with approval
Some resolvers or segments may not support query logging, or logging may be unsuitable for privacy or performance reasons. Record each exclusion with the asset, the technical reason, the compensating control, the risk owner's approval and a review date. Assessors look for exclusions that are narrow and approved, and they treat unexplained gaps as failures. Revisit the list whenever the inventory changes.
Coverage reports over time
Produce a recurring report that compares the inventory extract with the sources actually sending logs, then records the percentage of in-scope sources covered. Keeping several periods of reports shows the control operating over time, not only on the day of the assessment. Set a schedule and a named owner for the report, and investigate any source that drops out of the feed.
How DNS query records travel from resolver to log store
A DNS query log is only useful if it arrives intact at a place where someone can search it, so the section of the pipeline that matters most is the path between the client and the log store. A workstation or server sends a query to its configured resolver, which may be an internal recursive resolver, a resolver on a firewall or a resolver run by a cloud provider. The resolver answers the query, and whether that event is written down depends on the resolver's own logging settings. Safeguard 8.6 asks for these query records to be collected where that is appropriate and supported, so the first decision is which resolvers are in scope and whether each one can log queries at all. Confirm that with the product documentation for each resolver you run, because not every resolver logs queries by default.
Once a resolver writes a query record, the record crosses several trust boundaries. The first is the internal resolver itself, where the record is created on a system that the security team may or may not administer. The second is egress, where queries leave the enterprise to an upstream or external resolver, and where a client that bypasses the internal resolver produces no record at all. The third is the cloud logging account, where forwarded records are stored under separate credentials and retention settings. Each boundary needs a named owner and an agreed transport, because a break at any one of them looks identical to silence in the log store. The Assessment Specification treats the DNS configuration as a measured input, so the mapping of clients to resolvers should be documented before logging is judged.
Records can be lost at predictable points: a resolver that drops logs when its disk or buffer fills, a forwarder that restarts without a persistent queue, a network path that blocks the syslog or agent transport, a collector that rejects malformed fields, and a storage tier that expires records earlier than the retention set in Safeguard 8.10 requires. Ask for a test in which a known query is generated from a representative client, traced through the resolver and forwarder, and found in the log store with its timestamp intact, and repeat it after any change to the resolver or network. Where a feed from a security tool such as an intrusion detection system carries DNS records, treat it as a second source to reconcile against the resolver records rather than as a replacement for them.
What meeting Safeguard 8.6 costs in money and effort
This table compares the cost components of collecting DNS query audit logs under Safeguard 8.6, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to build a quote request, because no price or duration for this Safeguard is published in the sources, so the figures you receive must come from your own scope and environment.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it |
|---|---|---|---|
| Logging tool or SIEM licenses | Software vendor or licensor; open-source tools remove this line | Usually recurring, often priced on data volume or events | Daily DNS query volume, number of log sources, retention length |
| Engineering time to enable and parse DNS logs | Internal platform or security engineers, or an implementation partner under a fixed-scope agreement | One-time for initial setup, then recurring for changes | Number of resolvers and DNS platforms, log format differences, parsing rules needed |
| Resolver configuration and asset coverage checks | Internal network or infrastructure team | Recurring as assets change | Size of the asset inventory (Safeguard 1.1) and the secure configuration baseline (Safeguard 4.1) |
| Storage for query volume | Internal infrastructure team, or cloud or data center provider | Recurring | Query volume per resolver, retention period, compression and indexing choices |
| Evidence upkeep | Internal compliance or security team | Recurring, tied to review cycles and audits | Number of measures tracked, frequency of coverage reports, how evidence is stored |
| External review or testing | Independent assessor or consultant, selected by the organization | Periodic | Scope of review, number of resolvers sampled, whether the review covers configuration only or log content |
| Auditor sampling | Independent auditor, paid by the organization under its audit engagement | Periodic, per audit cycle | Number of samples the auditor selects, how easily the organization can produce coverage and retention records |
Who owns the DNS logging work, the partner and the auditor
Your organization owns Safeguard 8.6. That means deciding which enterprise assets are in scope for DNS query logging, where the logs must be stored, who reviews them and how long they are kept. Those decisions tie back to the documented audit log management process (Safeguard 8.1) and to your asset inventory (Safeguard 1.1), because you cannot justify coverage for assets you have not listed. The 'where appropriate and supported' wording leaves room for judgment, so the scope decision and its reasoning must be written down and approved by someone accountable for it.
- Scope decisions: Record which resolvers, endpoints and servers generate DNS queries you log, and which are excluded and why.
- Risk acceptance: Document any asset that cannot produce DNS logs and who accepted that gap.
- Review ownership: Name the people who read DNS logs and the alerts they feed into.
- Retention choices: Set how long DNS records are kept, consistent with Safeguard 8.10 and any legal or contractual duties.
- Sign-off: Keep a dated approval for the scope and configuration baseline.
Check that someone inside the organization can explain every scope exclusion without referring to the partner.
An implementation partner such as DeployOpen prepares the systems, configuration and evidence that support the control. In practice this can include building the log pipeline, configuring DNS resolvers or forwarders to emit query logs, sending those logs to a central store, and assembling evidence packs that show the configuration in place. The partner works from the scope your organization approves and does not decide that scope. A partner also cannot certify the result, and its written deliverables should say so plainly.
- Pipeline build: Configure resolvers, collectors and storage in your own cloud accounts, data centers or air-gapped network.
- Configuration evidence: Export settings, version records and change history that show logging is enabled.
- Evidence packs: Organize screenshots, configuration files, sample log entries and test results against the measures in the assessment specification.
- Documentation: Write runbooks for operating and verifying the DNS logging path.
- Handover: Train your staff so they can run the pipeline after the engagement ends.
Ask for the written scope, the deliverables list and a statement of what the partner will not do, including issuing any finding.
An independent auditor, assessor or certification body is the only party that tests Safeguard 8.6 for a formal purpose and issues a finding, report or certificate. The auditor measures the control against the CIS Controls Assessment Specification, which defines the inputs, operations and measures for this Safeguard. The auditor will ask to see the asset inventory, the configuration, sample logs and proof that reviews happen, and will test whether the evidence matches what the environment does. Independence is the reason the auditor's conclusion carries weight, so the auditor should not design the pipeline it later tests.
- Independent testing: The auditor samples assets and checks DNS logs directly from the systems or the central store.
- Measures and metric: Findings map to the three measures and the DNS configuration coverage metric in the specification.
- Reporting line: The auditor's report or finding is issued to your organization, not to the partner.
- Conflict of interest: Avoid having the same firm build controls and certify them without disclosure.
- Evidence requests: Expect questions about change control and whether the configuration was in place throughout the period tested.
Confirm with your chosen auditor which framework and report type they will use before the evidence is prepared.
Common gaps that fail a DNS logging review
Most DNS logging failures are not missing tools. They are gaps between where queries are generated, where they are logged, where they are stored and whether anyone checks that the chain still works. Each card below names one gap, why an assessor would question it under Safeguard 8.6 and the check that closes it.
Logging on one resolver only
A central resolver may log every query while laptops, servers and virtual machines send lookups to a second resolver, a public DNS address or directly over DNS over HTTPS. Those queries never reach the log. Safeguard 8.6 asks about enterprise assets where DNS logging is appropriate and supported, so the scope must reflect the real query paths. Check the resolver settings on a sample of endpoints and servers, and confirm that outbound DNS on port 53 is either routed through the logged resolver or blocked elsewhere.
Undocumented exclusions from logging
Teams often exclude noisy hosts, lab subnets or a vendor appliance from DNS logging to save storage, then never record the exclusion. An assessor reviewing the measurement will treat an unexplained gap as an unmanaged asset. Every exclusion should carry a named owner, a reason, an approval date and a review trigger, and it should be recorded in the asset inventory from Safeguard 1.1. Ask for the exclusion list at the start of the review, not during it.
Logs that never reach the central store
A resolver or endpoint agent may write DNS logs to local disk, to a syslog forwarder that silently drops messages, or to a collector that stopped receiving after a certificate change. The logs exist, but the central store Safeguard 8.9 depends on has no record of them. Verify end to end by generating a known test query from a sample of assets and confirming that it appears in the central platform with the expected source host, timestamp and query name.
Retention shorter than the log policy
The audit log management process sets how long DNS logs are kept, and Safeguard 8.10 sets a minimum of 90 days for audit logs. If the resolver rotates files after seven days or the SIEM index expires DNS data early, the configured policy is not what operates. Compare the retention setting on each collector and storage tier against the documented requirement, and keep a dated record of any change. Investigators often need older DNS data than the daily dashboards show.
No evidence of periodic coverage checks
Coverage can drift when new subnets, cloud accounts or endpoint builds appear without DNS logging. The Safeguard 8.6 measure of DNS configuration coverage is only credible if someone repeats it on a schedule and keeps the results. Assessors look for dated coverage reports, the asset counts behind them and the tickets raised for gaps. Set a recurring check, compare its results with the asset inventory, and retain the output as the evidence of ongoing operation.
Questions buyers ask about Safeguard 8.6
Does Safeguard 8.6 apply to every asset in our environment?
No. Safeguard 8.6 asks for DNS query audit logs on enterprise assets where that is appropriate and the asset supports it, so the scope is set by your own asset inventory and risk decisions, not by the Safeguard text alone. Typical candidates are DNS resolvers, internal DNS servers, and endpoints or gateways that can forward or record lookups. Assets that cannot produce DNS query logs are documented as unsupported, with the reason and any compensating source, such as resolver-side logging or network sensor output. The Assessment Specification expects the asset inventory from Safeguard 1.1 and the secure configuration process from Safeguard 4.1 to show which assets are in scope. Confirm your inventory before you agree a scope with anyone.
How long does it take to turn on DNS query logging?
The duration depends on how many resolvers and assets are in scope, how many DNS platforms you run, and whether logs already reach a central store. For a small, single-resolver environment the work is mostly configuration and testing. Larger estates add change approvals, testing for resolver performance, and log pipeline work. No duration is fixed by CIS, so ask for a timeline built from a written scope that lists each resolver, its platform, and the destination for logs. A fixed-scope engagement lets you agree that timeline before work starts.
What drives the cost of DNS query logging, and what should we ask for in a quote?
Cost has one-time parts and recurring parts. One-time costs include discovery of DNS platforms, configuration, testing, documentation, and any pipeline work to get logs into your log management tools. Recurring costs include log storage, the people who review the output, and any support retainer. The main drivers are the number of resolvers, platform variety, log volume, and how much of the storage and review work you already run. In a quote, ask for the scope list of assets, the platforms covered, the log destination, what is delivered as evidence, what is excluded, and which costs recur. DeployOpen does not publish prices. A quote follows from the written scope.
Can our own team enable DNS query logging without an outside partner?
Often yes, if your team already operates the DNS platforms and a log pipeline. The work is largely configuration plus evidence, and a capable internal team can complete it. An outside partner adds value where the team lacks DNS platform experience, where many resolver types must be handled consistently, or where evidence has to be organized for an assessment. Whichever route you take, your organization owns the control. Be clear with your team about who will document the decisions, who will sign off the scope, and who will keep the logging running after go-live.
What does the work need from our internal team?
The work needs named owners on three sides. DNS and network operations staff must provide access to resolvers, change windows, and knowledge of current forwarding paths. Security or log management staff must confirm the destination, retention, and who reviews the output. Compliance or governance staff must agree how the evidence will be kept and which assets are in scope. Plan for these people to review configuration changes and to answer questions about the asset inventory. Ask any partner to list these dependencies in the scope so that gaps are visible early.
How do assessors decide whether DNS logging is 'appropriate and supported'?
An assessor looks for a documented decision for each asset. The question is whether the asset can produce DNS query logs and whether logging on it is suitable for its role. Assessors usually check the asset inventory, the configuration evidence showing logging is on where it is supported, and the documented reasons for any asset where it is not. The CIS Controls Assessment Specification measures DNS configuration coverage through three measures combined into one metric, so coverage across the in-scope population is what counts. Keep the reasoning written down. The judgment belongs to your organization and the independent assessor, not to any implementation partner.
Does DeployOpen issue a certificate for Safeguard 8.6?
No. DeployOpen does not issue audit reports, attestations, or certifications. Our role is to prepare the systems and evidence for DNS query logging, such as configuration, log destinations, and documentation. CIS Controls implementation is not certified by a CIS-run process for individual organizations. If you need an independent view of your implementation, engage an independent assessor or auditor that fits your contractual or regulatory requirement. CIS itself notes that the Controls do not replace any regulatory, compliance, or authorization scheme.
Which open-source platforms can produce DNS query evidence?
Several self-hosted platforms can generate records that support this Safeguard, but the exact DNS query output depends on the product and its configuration. Suricata's EVE output can write JSON records for DNS transactions, which log management tools can ingest. OPNsense runs Suricata for its intrusion detection and can send alerts to syslog in EVE JSON format. Confirm with each vendor whether DNS query logging is available in your version and how to enable it. Do not assume a platform logs every query type until you have tested it in your environment.
How DeployOpen scopes and prepares DNS logging evidence
DeployOpen starts with a fixed-scope written agreement that names which DNS resolvers, forwarders and enterprise assets fall under Safeguard 8.6, which ones are excluded and why. The scoping work is where most of the audit risk is decided. We inventory the resolvers your organization actually uses, including internal recursive servers, endpoint-facing forwarders and any DNS services on cloud or branch networks, and we confirm with your team which of them support query logging. Where a resolver cannot log queries, the written scope records that limitation and the compensating approach agreed with you, so the assessor sees a documented decision rather than a silent gap. Confirm the asset inventory and secure configuration records that feed this step (Safeguards 1.1 and 4.1) before the scope is signed, because the assessment specification treats them as prerequisites.
Once the scope is fixed, the work happens inside your own infrastructure. For self-hosted resolvers, we enable query logging, set where the logs are written, restrict who can read or change the logging configuration, and forward the records to the central log platform your organization uses for Control 8. For network-based sensors, we can deploy the open-source intrusion detection stack described elsewhere on this page, for example OPNsense with Suricata writing EVE JSON, and configure the DNS record type so query data is kept in a structured, searchable form. Each setting is hardened, documented and tested with sample queries so that you can show that a query made on an in-scope asset produces a record with a timestamp and a source. Confirm with your vendor the exact configuration keys and file paths for your product version, since these are not fixed by the researched facts for this page.
At the end of the engagement we assemble an evidence pack for the auditor. It typically contains the signed scope, the resolver and asset list with coverage status, configuration exports with change history, sample log records from each in-scope resolver, the retention and access settings, and the test results that show logging is working. DeployOpen prepares these materials, but it does not issue audit reports, attestations or certifications. Those are issued only by an independent auditor or certification body that you select and pay directly. The fixed scope, deliverables and timeline are agreed in writing before work begins, and we do not publish a price list on this page. Ask for a written quote that lists each resolver, each deliverable and the evidence format, so you can compare it with what your assessor will need.
