Protective DNS only protects the queries that actually reach it, and in most organisations a large share of devices, browsers and workloads quietly resolve names somewhere else. A protective DNS (PDNS) service is a recursive resolver that refuses to resolve, or redirects, names and answers that match threat intelligence, and both CISA and the UK NCSC run government PDNS services for exactly that reason. The hard work is not switching the forwarder: it is choosing a provider whose data handling you accept, designing resolver chains that keep internal names working, closing the bypass paths through port 53, port 853 and DNS over HTTPS, and using the logs. This guide covers selection, architecture, bypass control, rollout, logging and measurement for network and security engineers. For the wider DNS picture (DNSSEC, authoritative zones, subdomain takeover) see the DNS Security Guide.
Key takeaways
- PDNS is a service, not a protocol. The NSA and CISA selection guidance defines it as a security service that analyses DNS queries and acts on them, usually with response policy zone (RPZ) style rules on both names and returned IP addresses.
- Coverage is the main metric. Every resolver path that does not end at PDNS (hard-coded resolvers, browser DNS over HTTPS, cloud workloads, unmanaged laptops) is a gap; measure the share of queries PDNS actually sees.
- Bypass control is half the project. Block outbound DNS on 53 and 853 except from your resolvers, disable or redirect application DoH by policy, and give roaming devices a PDNS client.
- Keep internal DNS internal. Forward from your own resolvers to PDNS and keep conditional forwarders for internal and Active Directory zones, rather than pointing clients straight at the provider.
- The logs are as valuable as the blocks. Retained query and block logs let you find infected hosts and search retrospectively when new indicators appear; feed them to the SIEM and staff the alert queue.
What protective DNS stops and what it does not
A PDNS resolver checks each query against deny lists, categories and heuristics, and checks the answers it receives (for example, a benign-looking name that resolves into known malicious address space). It then answers normally, returns NXDOMAIN, or redirects to a block page or sinkhole. The NCSC PDNS stores its rules as an RPZ drawn from commercial, internal and open sources, and the CISA Protective DNS Resolver, the successor to the E3A DNS Sinkhole, filters against unclassified threat intelligence.
| Threat | ATT&CK | What PDNS does | Limit |
|---|---|---|---|
| Phishing links and credential harvesting sites | T1566 Phishing | Blocks known phishing domains and newly registered lookalikes | Misses brand-new domains until feeds catch up; pair with phishing-resistant MFA |
| Malware command and control over DNS | T1071.004 DNS | Blocks or sinkholes known C2 domains and reveals beaconing hosts in logs | Traffic to raw IP addresses never touches DNS |
| Domain generation algorithms | T1568.002 | Some providers detect algorithmically generated names | Detection quality varies widely between providers |
| Fast flux infrastructure | T1568.001 | Answer-side IP and name server reputation checks | Only if the provider inspects answers, not just names |
| DNS tunnelling and exfiltration | T1572, T1048 | Some services flag long or high-entropy labels and unusual query volume | Usually detection, not prevention; tune per environment |
| Attacker-registered domains | T1583.001 | Newly observed or newly registered domain policies | Breaks some legitimate new services; needs an allow list process |
The NSA and CISA guidance is explicit that traffic using IP addresses directly bypasses PDNS and that organisations should not rely on it alone. Treat it as a cheap, broad layer in front of the Secure Web Gateway and Web Filtering Guide controls and endpoint detection, not as a replacement for them.
Service models and how to choose
| Model | Examples | Strengths | Trade-offs |
|---|---|---|---|
| Government PDNS | NCSC PDNS (mandated for UK central government by the Cabinet Office, free and available to other eligible organisations); CISA Protective DNS Resolver (for US federal civilian agencies) | No cost, curated government threat intelligence, block data contributes to national incident response | Eligibility limits; fewer content filtering options; you accept the operator's policies |
| Commercial cloud PDNS | Recursive resolver services sold standalone or inside SSE and SASE platforms | Roaming clients, per group policy, dashboards, APIs, content categories | The provider sees every query; check data residency, retention and secondary use |
| Self-hosted RPZ | BIND, Unbound, PowerDNS Recursor or Windows DNS policies with commercial or open RPZ feeds | Full control and local logs; suits air-gapped or OT networks | You run availability, feed updates and tuning; no roaming coverage without a VPN |
| Hybrid | Internal resolvers with local RPZ forwarding to cloud PDNS | Local policy for internal names plus provider intelligence | Two places to troubleshoot and to log |
Decision guidance:
- Small organisations with a simple network get most of the value by pointing their router or resolver at a PDNS provider and blocking outbound DNS elsewhere; the NCSC notes this is quick and gives immediate benefit.
- Large or hybrid estates need per network and per group policies, cloud workload coverage, a roaming client and SIEM integration, and usually a hybrid design.
- Eligible public bodies should use the government service first; the NCSC says a commercial service should not be considered a substitute where you qualify.
- OT and server segments are often better served by an allow list resolver (D3FEND DNS Allowlisting, D3-DNSAL) than by a deny list service.
Selection criteria
The NSA and CISA sheet "Selecting a Protective DNS Service" compared providers on public information as of February 2021 without testing, so use its criteria rather than its results. The NCSC private sector guidance adds operational and data protection criteria.
| Criterion | What to ask | Why it matters |
|---|---|---|
| Threat coverage | Malware, phishing, DGA detection; answer-side IP checks; newly observed domains | Name-only checks miss fast flux and shared hosting abuse |
| Feed quality | Sources, update frequency, false positive review process | Over-blocking erodes trust and drives users to bypass |
| Policy granularity | Policies by network, group or device; editable allow lists | Developers, OT and executives rarely fit one policy |
| Block response | NXDOMAIN, sinkhole or block page; Extended DNS Error codes | Affects user support and detection (see below) |
| Protocol support | DNSSEC validation, DoH and DoT to the resolver, IPv6 | Without DNSSEC validation the resolver can be fed spoofed answers |
| Roaming and hybrid | Lightweight client for Windows, macOS, iOS, Android; cloud VPC integration | Remote devices are where most bypass happens |
| Logs and API | Query and block logs, retention period, export to SIEM, API | Retrospective search and infected host discovery |
| Data protection | Data location, retention, secondary use, subprocessors | The provider sees all your DNS queries; free services may give few guarantees |
| Resilience | Anycast footprint, SLA, failover behaviour | DNS failure is an outage for everything |
Architecture: resolver chains and block responses
- Forward, do not replace: keep internal recursive resolvers (often the Active Directory DNS servers) as the only resolvers clients use, and set PDNS as their forwarder. Keep conditional forwarders or stub zones for internal domains, private cloud zones and partner zones so internal names never leave the network.
- Preserve client identity: if all queries reach PDNS from two forwarders, the provider's logs show two IP addresses. Either log on your resolvers as well and correlate, or use a provider feature that passes client or site identity. The NCSC advises combining PDNS logs with your own DNS logs. See the DNS Logging and Detection Guide.
- Cloud workloads: point VPC or VNet resolvers at PDNS through the cloud provider's outbound resolver endpoints or DNS firewall features, and block direct internet DNS from subnets.
- Roaming devices: a PDNS client sends queries over encrypted DNS when the device is off network. The NCSC PDNS Roaming client uses DNS over HTTPS on Windows, macOS and iOS. Exclude internal domains so the client hands them to the VPN or local resolver.
- Encrypt the hop to PDNS where the provider supports DoT or DoH, but keep visibility on your own resolvers.
| Block response | User experience | Detection value |
|---|---|---|
| NXDOMAIN | Generic "site not found"; no explanation | Visible only in resolver logs |
| Block page | Explains the block and how to appeal, but HTTPS sites show a certificate error | Connections to the block page identify affected users |
| Sinkhole address | Connection fails or reaches a controlled server | Every connection to the sinkhole is a likely infected or misconfigured host |
| Extended DNS Error (RFC 8914) | Clients that support it can show why: code 15 Blocked (operator policy) or 17 Filtered (client requested) | Helps support teams separate blocks from outages |
Closing the bypass paths
Both the NSA and CISA guidance and the NCSC say the same thing: block outbound DNS that does not go through PDNS, and control encrypted DNS in clients. Enforce it through Group Policy, MDM and application control.
| Bypass path | Control |
|---|---|
| Classic DNS to public resolvers (UDP and TCP 53) | Egress firewall: allow 53 only from your resolvers to PDNS; optionally redirect stray port 53 traffic to your resolvers and alert on the source |
| DNS over TLS (TCP 853) and DNS over QUIC (UDP 853) | Block 853 outbound except to approved resolvers |
| Browser DNS over HTTPS | Browser enterprise policy: Chrome and Edge DnsOverHttpsMode set to off or to a template pointing at your resolver; Firefox DNSOverHTTPS policy; answer the Firefox canary domain use-application-dns.net with NXDOMAIN so default DoH turns off (it does not override a user who enabled DoH) |
| Operating system DoH | Windows Group Policy "Configure DNS over HTTPS (DoH) name resolution" (Computer Configuration, Administrative Templates, Network, DNS Client): Prohibit, or Allow only with your resolver; do not set Require on domain-joined machines, which Microsoft warns against. Apple and mobile DNS settings through MDM profiles |
| Public DoH endpoints | Block known DoH resolver hostnames and addresses at the web proxy or firewall; review categories regularly |
| VPN and tunnelling apps | Application control and egress rules; consumer VPNs carry their own DNS |
| Hard-coded IP connections | Out of PDNS scope: use egress filtering, proxy enforcement and IP reputation |
See the Encrypted DNS Enterprise Guide for encrypted DNS design and the Firewall Management Guide for egress rule governance.
Rolling out protective DNS
- Baseline: enable query logging on internal resolvers for two weeks and capture outbound 53, 853 and known DoH traffic at the firewall. This shows how many devices bypass your resolvers today.
- Choose and contract: run the selection criteria, review the data protection terms and confirm SLA and failover.
- Log-only pilot: forward a pilot site or the IT team's resolvers to PDNS with blocking in monitor or log-only mode where the provider supports it, and review what would have been blocked.
- Allow list and support process: agree who can approve allow list entries, within what time, and how users report a wrong block. Publish the block page text.
- Enforce in rings: enable blocking for IT, then one business unit, then the estate, with a change window and a rollback that is simply switching the forwarder back to the previous upstream.
- Close bypass: roll out browser and OS DoH policies, then egress blocks for 53 and 853 in monitor mode, then enforce. Deploy the roaming client to laptops and mobiles.
- Integrate: stream block and query logs to the SIEM, build alerts and add PDNS blocks as an input to incident triage. See the SIEM Guide.
- Review: monthly false positive review, quarterly coverage review, and an annual provider and feed re-evaluation, which the NCSC recommends.
Logging, detection and measurement
The NSA and CISA guidance notes that historical PDNS logs let you search retrospectively for earlier intrusions once new indicators are published, and that teams should plan for the added alert workload.
- What to log: timestamp, client identity (IP, hostname or device ID), queried name, query type, response code, answer, policy or category matched, and block action. Retain long enough to cover typical dwell time; many teams aim for at least 12 months.
- What to alert on: repeated hits on malware or C2 categories from one host; connections to the sinkhole; DGA detections; spikes in NXDOMAIN; very long labels or TXT query volume (possible tunnelling); queries to public resolvers or DoH endpoints from managed hosts.
- Privacy: DNS logs reveal browsing. Document the purpose, access and retention, and restrict who can search by user. See the DNS Logging and Detection Guide.
Metrics:
- PDNS coverage: share of managed devices whose queries reach PDNS (on network and roaming), target above 95 percent.
- Bypass attempts: number of hosts sending DNS on 53 or 853 to non-approved resolvers, trending to zero.
- Malicious block rate per 1,000 devices, and the share investigated within the SLA.
- False positive rate: allow list requests per month and median time to resolve.
- Mean time from first malicious block to host containment.
Common failure patterns
- Clients pointed straight at the provider: internal and Active Directory names break, teams add exceptions, and eventually PDNS is removed from the worst-affected sites.
- Browsers left on default DoH: a growing share of web lookups go to a public resolver, invisible to both PDNS and your own logs.
- No egress block: malware and developer tools that hard-code a public resolver ignore PDNS entirely.
- Blocks nobody looks at: PDNS stops the C2 lookup but the infected host is never investigated, so the intrusion continues over IP addresses or other channels.
- Logs without client identity: every block in the provider console shows the forwarder IP, so finding the infected host takes hours.
- Cloud and server estates forgotten: workloads use the cloud provider's default resolver straight to the internet, outside policy.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver); SC-22 Architecture and Provisioning for Name/Address Resolution Service | Egress control, validating resolvers and resilient resolver design |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring; AU-2 Event Logging; AU-11 Audit Record Retention | Query logging, alerting and retention |
| NIST CSF 2.0 | PR.IR-01; DE.CM-01; PR.PS-04; DE.AE-02 | Network protection, monitoring and log analysis |
| CIS Controls v8.1 | Safeguard 9.2 Use DNS Filtering Services; Safeguard 8.6 Collect DNS Query Audit Logs | Direct requirement for DNS filtering and logging |
| MITRE D3FEND | D3-DNSDL DNS Denylisting (D3-FRDDL, D3-HDDL, D3-FRIDL); D3-DNSAL DNS Allowlisting | The defensive techniques PDNS implements |
| MITRE ATT&CK | T1071.004, T1568.002, T1568.001, T1572, T1048, T1566, T1583.001 | Techniques PDNS disrupts or detects |
Practitioner checklist
- Measure today's bypass: outbound 53, 853 and DoH traffic from managed devices.
- Check eligibility for a government PDNS service before buying a commercial one.
- Assess providers on threat coverage, answer-side checks, logs and API, DNSSEC validation, roaming support and data protection terms.
- Forward from internal resolvers to PDNS and keep conditional forwarders for internal zones.
- Pilot in log-only mode, agree an allow list process, then enforce in rings with a forwarder rollback.
- Set browser and OS DoH policies, answer the Firefox canary domain, and block outbound 53 and 853 except from approved resolvers.
- Deploy a roaming client to laptops and mobiles and cover cloud workload resolvers.
- Stream query and block logs with client identity to the SIEM and alert on C2, DGA and sinkhole hits.
- Review false positives monthly and providers and feeds annually.
Standards and references
- NSA and CISA: Selecting a Protective DNS Service
- CISA: Protective Domain Name System Resolver
- NCSC: Protective Domain Name Service (PDNS)
- NCSC: Protective DNS for the private sector
- IETF: RFC 8914 Extended DNS Errors
- Microsoft Learn: DNS over HTTPS client support in Windows Server
- Mozilla: Canary domain use-application-dns.net
- MITRE D3FEND: DNS Denylisting
Related NHI Mgmt Group resources: DNS Security Guide · Encrypted DNS Enterprise Guide · DNS Logging and Detection Guide · Secure Web Gateway and Web Filtering Guide