DNS Security Renewal: Prove the Logs Leave With You
A DNS security service can block bad destinations all year and still leave you short on evidence when an incident happens.
The portal shows charts. The monthly report lists blocked requests. The renewal deck says threat visibility improved. Okay, cool. Can your team get the underlying DNS events into its monitoring stack, connect a request to the device that made it, search far enough back for an investigation, and keep the evidence when the contract ends?
If the answer is unclear, do not treat logging as a feature you already own. Treat it as an unresolved part of the renewal.
Before you sign, run one DNS log from request to archive and prove the data will still be usable when the provider is gone.
Start with the investigation you need to support
Protective DNS is more than a web filter. It can block connections to known or suspected malicious destinations and create a record of DNS requests that helps with threat hunting and incident response.
NIST’s March 2026 Secure Domain Name System Deployment Guide recommends current and historical DNS traffic logging for digital forensics and incident response. It also says DNS logs should be integrated with other system logs so teams can connect DNS activity with cloud workloads, devices, or users. For rapid notification of suspicious queries, NIST recommends sending protective DNS logs to a SIEM or log analysis platform.
That gives buyers a useful starting point, but it does not set one universal retention period or architecture for every company. Your requirements should follow the incidents, legal duties, insurance terms, and business risks you need to support.
Write down what an investigation must answer:
- Which device or user requested the domain?
- What was the domain, query type, response, policy action, and timestamp?
- Was the request allowed, blocked, redirected, or unresolved?
- Which policy, category, or threat signal produced the action?
- Did the same device create related security events?
- How far back can the team search?
If the service cannot support the investigation you expect it to support, the renewal decision is already changing.
Map every DNS path before testing the logs
A clean portal does not prove complete coverage. DNS requests can take different paths based on location, network design, browser settings, VPN state, cloud workloads, and encrypted DNS configuration.
Build a simple path inventory:
| Request source | Expected DNS path | Identity available | Evidence to verify |
|---|---|---|---|
| Office device | Local resolver, security appliance, or cloud resolver | Device, IP, site, user, or network | Test query plus matching event |
| Remote device | Endpoint agent, VPN, or cloud security service | Device and user | Off-network test query |
| Guest network | Segmented guest resolver or policy | Site or guest segment | Labeled guest event |
| Server and cloud workload | Workload resolver or approved forwarder | Workload, account, IP, or subnet | Test from each material environment |
| Mobile device | Managed client, VPN, or mobile security path | User and device where supported | Cellular and Wi-Fi tests |
| Browser or application using encrypted DNS | Approved encrypted resolver or controlled exception | Varies by design | Bypass and policy test |
Do not accept “all DNS is covered” as the answer. Ask the provider to show how each important source reaches the service and what identity survives the trip.
NIST points out that mapping an IP address to a compromised asset requires attributable metadata and a history of address allocation, such as DHCP lease history. That matters because an event tied only to a shared egress IP or a recycled internal address may not tell the analyst which device made the request.
Test from a real office device, a remote device, and at least one important cloud or server environment. Search for each event. Confirm the source, time, action, and policy context. Document anything that bypasses the service or arrives without enough identity to investigate.
Separate portal history from exported evidence
Buyers often hear “we retain your logs” when the vendor means one of several different things:
- Events are visible in a dashboard for a set period
- Reports or an API expose certain records
- Logs stream to the customer’s SIEM or storage
- A provider-managed archive holds data temporarily
- The customer owns a separate archive and its retention policy
Those are different operating models.
Current vendor documentation shows why the distinction matters. Cloudflare documents Gateway DNS activity logs in its dashboard and says customers can change whether all events, only blocked events, or no events are logged. It also notes that the dashboard setting does not change Logpush data. Cisco Umbrella documents log delivery to either a customer-managed or Cisco-managed Amazon S3 bucket. Zscaler documents DNS details in its Insights logs and its Nanolog Streaming Service for sending logs to a SIEM and supporting longer local archival.
These examples are not a product ranking. They show that log selection, dashboard access, streaming, storage ownership, and retention can sit in different parts of the service.
For your current product and license, get written answers:
- Which DNS events are created by default?
- Are allowed requests logged, or only blocked and risky activity?
- Which fields appear in the portal, export, API, and streaming feed?
- What license, connector, storage account, or professional service is required?
- What delay is normal, and can the provider replay missed events?
- What happens during an export failure or SIEM outage?
- Which team owns the destination, credentials, parser, and health monitoring?
- Will dashboard settings, schema changes, or field changes affect the exported feed?
Then compare the answers with the agreement, service description, product documentation, and the configuration running in your environment. Sales language does not beat the actual setup.
Reconcile one event across the full pipeline
A connector marked healthy is not enough. Send a controlled test query through the service and trace it through every layer.
Record the source device and user, request time, domain, query type, resolver, policy decision, raw provider event, delivery time, destination record, parsed fields, and any alert tied to it.
Compare event counts across a sample window. Look for gaps, duplicates, time-zone problems, missing identity, delayed delivery, truncated fields, parsing failures, or policy actions that do not match the destination record.
This is where a lot of logging programs get exposed. The service may create the event correctly while the customer’s S3 permissions expire, the SIEM connector stops polling, a parser update drops fields, or nobody watches ingestion health.
The vendor does not have to own every layer. Someone does.
Set retention from the loss you cannot accept
Ask how far back the team may need to investigate, which DNS data must remain quickly searchable, what can move to lower-cost storage, and which requirements come from regulation, contracts, insurance, or legal counsel.
NIST warns that logging all DNS traffic can consume resources and affect DNS service performance if it is handled poorly. It allows for efficient or selective logging and notes that known secure domains may be removed before SIEM ingestion to reduce volume and cost. NIST also says a complete log should be kept for future forensics, and queries and responses tied to domains classified as malicious or unauthorized should always be logged.
That creates a practical two-tier design for many buyers:
| Data tier | Purpose | Renewal questions |
|---|---|---|
| Searchable security data | Detection, triage, active investigation, and correlation | Which events and fields stay searchable, for how long, and at what cost? |
| Complete forensic archive | Longer lookback and reconstruction when an incident expands | Who owns it, how is it protected, how fast can it be restored, and can the team search it without the provider? |
Price the full path. Include the DNS service tier, log export feature, cloud storage, SIEM ingestion, parsing, searchable retention, archive retrieval, data transfer, monitoring, and staff time. A low service price can become an expensive logging design when every DNS request enters a consumption-priced SIEM.
The broader logging and monitoring guide can help rank log sources by risk. The SIEM evaluation guide covers data-source planning and pricing. For this renewal, keep the focus on whether DNS evidence remains complete enough to investigate.
Put ownership and termination in writing
The contract should identify what happens to your DNS data during the service and after termination.
Confirm:
- Who owns the logs and any derived customer-specific records
- Who controls the storage account, encryption keys, service credentials, and access policy
- How long the provider keeps data in the portal and any managed archive
- Whether deletion pauses are available during an active incident or legal hold
- How much time the customer has to export data after termination
- Which format and delivery method the final export uses
- Whether final export, transition help, or high-volume retrieval costs extra
- When the provider deletes remaining customer data
- How deletion is confirmed
- Which configurations, policy lists, exceptions, and audit records can also be exported
Run the exit before renewal. Export a defined date range, load it into a destination you control, verify the fields, and prove a second administrator can complete the process. If the only working path depends on one vendor administrator, one customer employee, or a key nobody rotates, fix it now.
The SaaS data export test covers broader record portability. DNS evidence needs an additional standard: the export must preserve the source, time, query, response, action, and policy context needed for an investigation.
Use a renew, correct, or compare decision
Renew when coverage is proven, important events carry enough identity, exports arrive reliably, retention matches your requirements, costs are understood, and the organization controls a usable archive or a tested transition path.
Correct the service before signing when the product still fits but some traffic bypasses it, source attribution is weak, allowed-event logging is disabled without a deliberate risk decision, exports are unreliable, or contract language does not match the operating model.
Compare alternatives when the provider cannot supply the events your investigation process needs, makes usable export commercially unreasonable, will not define post-termination access, or expects you to trust a dashboard that your security team cannot independently reconcile.
A DNS security renewal should buy blocking and evidence. If the evidence disappears with the subscription, price that risk before you sign.
If your DNS security, SASE, SIEM, or managed security agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the agreement, renewal proposal, logging documentation, current configuration, SIEM or storage evidence, retention requirements, and a sample export. Catch Advisors will help you decide what to renew, correct, or compare before the notice deadline makes the decision for you.