DNS Security and Protective DNS Buyer’s Guide: How to Evaluate Protective Resolver Services

Protective DNS is cheap to switch on and easy to buy badly: most failed purchases block too much, log too little, or are quietly bypassed by browsers and roaming laptops. A protective DNS (PDNS) service is a recursive resolver that refuses to resolve domains and addresses its threat intelligence marks as malicious. The NSA and CISA describe it as "a security service, not a protocol", which is why two services that both say "DNS firewall" can behave very differently. This vendor-neutral buyer's guide is for security architects, network teams and SOC leads choosing a cloud PDNS service, a DNS security module inside an SSE or SASE platform, or a self-hosted response policy zone (RPZ) design. For how PDNS works and how to operate it once bought, read the Protective DNS Guide; this page is about choosing.

Key takeaways

• Check whether you qualify for a government service first. UK central government must use the NCSC PDNS service, and the NCSC says a commercial service "shouldn't be considered a substitute" where an organisation qualifies. US federal civilian agencies have the CISA Protective DNS Resolver.
• Buy the logs as much as the blocking. Query logs with client attribution, retention you control and a working SIEM export are what turn a block into an investigation. Score them as heavily as threat coverage.
• Bypass is the main failure mode. The NSA and CISA note that traffic using IP addresses directly skips PDNS entirely, and unmanaged DNS over HTTPS (DoH) skips it too. A service is only as good as your ability to force every device through it.
• The provider sees every query you make. Treat the contract as a data processing agreement: location, retention, secondary use and subprocessors must be written down, not described on a marketing page.
• Measure efficacy on your own traffic. The 2021 NSA and CISA comparison reflects public information as of February 2021, was not tested and is not a recommendation. Run a parallel proof of concept with your own logs and a false positive budget.

Define requirements

Agree these with network, SOC, endpoint, privacy and identity teams before any vendor meeting. NIST SP 800-81 Rev. 3 (Secure Domain Name System Deployment Guide, final, March 2026, superseding SP 800-81-2) frames DNS security as an additional layer within zero trust and defence in depth, which is the right lens: PDNS supplements, and does not replace, web filtering and endpoint controls. See the NIST SP 800-81 Rev. 3 Guide.

• Eligibility: confirm whether a government service applies to you (NCSC PDNS in the UK, the CISA Protective DNS Resolver for US federal civilian agencies). In the EU, the DNS4EU resolver, co-funded by the European Union from 2023 to 2025 and operated by Whalebone, offers protective resolution for individuals, public bodies and companies; check its current terms directly.
• Estate and coverage: sites, egress points, internal resolvers (Windows DNS, BIND, Unbound, DDI appliances), cloud VPCs, OT segments, guest Wi-Fi, and roaming and mobile devices. Each needs a deployment method.
• Policy model: one policy or several (by network, group or device); security categories only, or content categories too; who approves allow list changes.
• Log requirements: which fields you need (timestamp, client IP or device ID, user, query name, type, response, policy hit), retention period, export format and SIEM.
• Data constraints: where query data may be processed and stored, and whether it may be used for anything other than your protection. If you are subject to GDPR, query logs tied to devices or users are likely to be personal data; involve your DPO.
• Availability: what happens to name resolution if the provider fails. DNS failure is an outage for everything.

Size changes the answer. A small organisation with one site can point its router or resolver at a PDNS provider, block outbound DNS elsewhere and gain most of the value in a day; the NCSC describes this as the simple-network option. A large or hybrid estate needs per network policies, a roaming client, cloud workload coverage and a hybrid design with internal resolvers forwarding to the service. OT and server segments are often better served by an allow list resolver (MITRE D3FEND DNS Allowlisting, D3-DNSAL) than by a deny list service (D3-DNSDL).

If you are also buying web filtering, read the SASE and SSE Buyer's Guide first and decide whether DNS security is a module of that purchase or a separate layer. For internal DNS platforms, see the DDI buyer's guide.

Capability areas

Threat detection and feeds

The NSA and CISA comparison sheet "Selecting a Protective DNS Service" (March 2021) lists the capabilities worth asking about: blocking malware and phishing domains, domain generation algorithm (DGA) protection, machine learning or heuristics to augment feeds, content filtering, API access for SIEM integration, a web dashboard, DNSSEC validation, DoH and DoT support, per group or device policy, and hybrid deployment. In ATT&CK terms the service is aimed at command and control over DNS (T1071.004 Application Layer Protocol: DNS), domain generation algorithms (T1568.002) and DNS tunnelling (T1572 Protocol Tunneling), plus phishing and malware delivery domains. A static deny list catches known domains; DGA and tunnelling need behavioural analysis of query patterns, and checking returned IP addresses catches malicious infrastructure behind fresh domains.

Policy and block response

The NCSC lists three block responses: a block page (which may trigger a certificate error), a sinkhole that returns a custom response, and NXDOMAIN, where users see a standard error and do not learn that PDNS blocked the domain. A sinkhole or block page gives you a second log source, because blocked clients try to connect to it. Ask whether the service returns Extended DNS Errors (RFC 8914, Standards Track, October 2020): code 15 Blocked (operator's own policy), 16 Censored (external requirement such as a court order), 17 Filtered (at the client's request) and 18 Prohibited (unauthorised client). EDE lets clients and your help desk tell a block from a broken domain.

Encrypted DNS and bypass control

Ask which client protocols the resolver accepts: DoT (RFC 7858, TCP 853), DoH (RFC 8484, HTTPS on 443) and DNS over QUIC (RFC 9250). Ask whether it supports Discovery of Designated Resolvers (RFC 9462, Standards Track, November 2023), in which clients query _dns.resolver.arpa for SVCB records to upgrade from plain DNS to an encrypted resolver run by the same operator. For bypass, the NCSC recommends blocking outbound DNS on ports 53 and 853 that does not go through your PDNS resolver, disabling DoH in operating systems and browsers or pointing it at the PDNS resolver, and enforcing this through Group Policy, MDM and application allow and deny lists. On Windows the setting is Computer Configuration\Policies\Administrative Templates\Network\DNS Client\Configure DNS over HTTPS (DoH) name resolution with Allow, Prohibit or Require; Microsoft advises against Require DoH on domain-joined machines because the Windows Server DNS service does not accept DoH queries. See the Encrypted DNS Enterprise Guide.

Roaming and workload coverage

The NSA and CISA note that one policy rarely fits a whole enterprise and that lightweight roaming clients give the flexibility. Ask which platforms the client supports, how it handles captive portals, VPN split tunnels and internal domains, whether users with local admin can stop it, and how cloud workloads in VPCs or VNets are covered (resolver forwarding rules, not agents).

Logging, API and integration

The NSA and CISA stress that historical query logs let you search retroactively for indicators of earlier intrusions. NCSC PDNS offers SIEM connectors for Microsoft Sentinel and Splunk; commercial services should match that. Without client attribution the logs are of little use: if all queries arrive from your egress NAT address, the SOC cannot find the infected host. See the DNS Logging and Detection Guide.

Where identity fits

A PDNS service creates non-human identities of its own: API keys for log export and policy automation, enrolment tokens for roaming clients, and site keys or certificates that tie your networks to your policy. Anyone holding an admin key can add an allow list entry for a command and control domain. Require SSO with MFA for the console, role separation between policy editors and log readers, scoped and expiring API credentials, and an audit trail of every policy change. See the API Key Management Guide.

Evaluation criteria

Weights are a suggested starting point from NHI Mgmt Group, not from a standard; adjust them to your requirements.

Map the purchase to your control frameworks so the business case and audit evidence line up:

Questions to ask vendors

1. Which threat categories do you block by default, and how many of your detections come from your own research versus licensed or open feeds?
2. How do you detect DGA domains and DNS tunnelling, and do you check answer IP addresses as well as queried names?
3. What is your process and target time for reviewing a false positive we report, and can we override a block locally at once?
4. Which block responses can we choose per policy (block page, sinkhole, NXDOMAIN), and do you return RFC 8914 Extended DNS Error codes?
5. Which client platforms does your roaming client support, can a local administrator disable it, and how does it behave with VPNs, captive portals and internal domains?
6. Which protocols does your resolver accept (DoT, DoH, DoQ), do you support RFC 9462 discovery, and do you validate DNSSEC?
7. Do you log every query or only blocks, what fields do you record, how long do you keep them, and can we set retention ourselves?
8. In which countries are queries resolved and logs stored, who are your subprocessors, and do you use our query data for any purpose other than protecting us, including product training or resale?
9. What is your SLA for resolution availability, how is it measured, and what happens to our clients if your service is unreachable?
10. How are console access, roles and API credentials controlled, and is every policy change logged with the actor?

Red flags

• Efficacy claims without method: "blocks 99% of threats" with no test set, date or independent method behind it.
• Block-only logging: the service records blocked queries but not allowed ones, so you cannot search retroactively for a domain that was clean last month and malicious today.
• No client attribution: all logs show your egress IP and the vendor has no forwarder, client or header mechanism to identify the device.
• Vague data terms: data location, retention or secondary use described only on a marketing page, or "anonymised" analytics reserved for any purpose.
• No DNSSEC validation: without it the resolver can be fed spoofed answers, which the NCSC lists as a provider selection criterion.
• Bypass treated as your problem only: no guidance or tooling for DoH, DoT, roaming devices or tamper resistance.
• Shared admin accounts or long-lived unscoped API keys: anyone with the key can allow list attacker infrastructure.

Proof of concept

Run two or three shortlisted services for about four weeks against the same traffic. Keep your current resolver path ready so you can roll back by changing a forwarder or DHCP option.

1. Baseline: export a week of your own resolver logs and record current resolution latency per site and the volume of queries leaving the network on ports 53 and 853 that bypass your resolvers.
2. Shadow mode: forward a copy of queries, or a pilot site's queries, in log-only or monitor mode. Count what each service would have blocked and classify a sample as true or false positives.
3. Replay indicators: test domains from your recent incident reports and current feeds, including recently registered domains; record which services block them and how quickly.
4. Enforce on a pilot ring: the security team and one business unit first, then a site. Measure help desk tickets and time to fix a false positive.
5. Test roaming and bypass: install the client on Windows, macOS and mobile pilot devices; try a browser DoH setting and a public resolver; confirm the firewall and endpoint policies hold.
6. Trace to the SIEM: generate a blocked query from a known laptop and time how long it takes to appear in the SIEM with device and user attribution.
7. Break things: make the primary resolver unreachable from a site and record client behaviour and recovery time.
8. Exit test: export policies, allow lists and logs, and confirm they are usable without the vendor.

Track these measures during the PoC and keep them as KPIs after purchase: share of DNS traffic from managed devices that reaches the service (target close to 100%), blocks per thousand queries by category, false positive rate and median time to reclassify, roaming client coverage across managed endpoints, time from block to SIEM alert, and resolver availability against the SLA.

Standards and references

• NSA and CISA: Selecting a Protective DNS Service
• NCSC: Protective DNS for the private sector
• NCSC: Protective Domain Name Service (PDNS)
• CISA: Protective Domain Name System Resolver
• NIST: SP 800-81 Rev. 3 Secure Domain Name System (DNS) Deployment Guide
• IETF: RFC 8914 Extended DNS Errors
• IETF: RFC 9462 Discovery of Designated Resolvers
• Microsoft Learn: Secure DNS client over HTTPS (DoH)

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Related NHI Mgmt Group resources: Protective DNS Guide · DNS Security Guide · Secure Web Gateway and Web Filtering Guide · DNS Security Checklist