Protective DNS for the Public Sector: A Deployment Guide

Protective DNS for the public sector succeeds when the intended devices use the policy and staff can investigate its decisions without interrupting essential services. Enrolling a council's headquarters resolver leaves important questions unanswered: what happens at a library, on a housing officer's laptop, or when an outsourced application uses its own connection?

For UK and European public institutions, the practical task is to establish coverage, responsibility and continuity. A resolver purchase alone does not establish any of them. This guide proposes a deployment record and acceptance process that a public-sector IT team can adapt with its network provider. The worked example is fictional, and the milestones are suggested engineering controls rather than a statutory checklist.

Define the public services and connections in scope

Start with services whose interruption has a clear consequence for residents or staff. Examples include housing appointments, revenue collection, library lending and workforce authentication. Name a service owner who can explain the dependencies and approve the pilot window. “All council devices” is too vague to test.

For each service, identify the managed endpoints, network locations, application owners and support arrangements. Distinguish staff access to a hosted service from the service provider's own server traffic. Routing employees through a protective resolver does not establish that a SaaS provider's infrastructure follows the same policy.

Use a compact service record:

Service: housing appointment administration
Business owner: named service manager
Population: managed office and field-worker laptops
Included paths: office LAN, approved VPN, home connection
Dependencies: identity service, booking application, document store
Network owner: council team or named managed provider
Acceptance evidence: test record for each connection path
Exclusions: supplier infrastructure not managed by the council

List public-access terminals separately from staff devices. They have different users, recovery procedures and expectations of privacy. An institution can operate several appropriate policies without describing them as one undifferentiated deployment. Preserve that distinction in the coverage report and support instructions.

Check programme eligibility before choosing the delivery model

The NCSC Protective DNS service is a UK recursive DNS protection programme with specific eligibility requirements. Check its current registration guidance for your institution.

UK teams should also check whether their sector or parent organisation has an established route to the service. A school, council and central department need not have the same onboarding process. Where an existing provider administers connectivity, agree who completes registration, configures forwarding and receives operational notifications.

For institutions elsewhere in Europe, record the national authority consulted and any sector-specific service already available. Compare the remaining options against the actual network and procurement requirements. Geography in a product name does not establish where query logs, backups or support access will reside.

Request a written description of those data flows. The public-sector threat-intelligence procurement guide provides a way to turn supplier claims into evidence requests. Treat this as an input to your institution's own review, including information governance and contractual approval.

Measure protective DNS coverage by connection path

An endpoint inventory gives a denominator, but coverage depends on how each endpoint connects. The same laptop can be protected in the office and uncovered after leaving it. A single successful lookup on one desktop is therefore insufficient acceptance evidence.

Build a test record for each relevant combination of device policy and network path. Include wired offices, managed wireless, satellite sites, VPN connections and approved direct internet access. For mobile work, test transitions between paths, not only a device that starts in the expected configuration.

Record the observed resolver route, effective policy and corresponding event in the monitoring system. Use harmless test destinations supplied or approved for that purpose. Do not browse live malicious infrastructure merely to prove that a block works. Retain the time and the expected result so another engineer can repeat the check.

Report three populations separately: tested and covered, configured but unverified, and outside scope. A device that has not connected during the pilot belongs in the second category until evidence supports promotion. Avoid dividing tested devices by an inventory that silently excludes field workers.

For the underlying resolver and feed concepts, see the DNS blocklist guide. Here, the acceptance question is narrower: can this institution demonstrate that its agreed populations use the intended control?

Preserve internal resolution and application dependencies

A public organisation often depends on internal names, directory services and applications shared with other authorities. Document which queries must reach internal resolvers and which are forwarded externally. Test that boundary before changing defaults across the estate.

Do not send internal namespaces to an external service simply because a workstation appears to resolve public websites correctly. Equally, do not assume every application uses the operating system's DNS settings. A managed browser, container or security client can introduce a different path.

Build an application smoke test with service owners. It should include authentication, a normal transaction, document access and any background integration required to complete the task. A landing page loading successfully does not prove that the payment, scheduling or identity component works.

Record caches and policy propagation when comparing results. A cached answer or existing connection can survive a policy change and mislead the test. Use the provider's supported verification procedure rather than making an unplanned estate-wide cache change.

The guide to DNS hardening covers related infrastructure controls. Protective resolution is one layer; it does not replace secure administration of the authoritative DNS that publishes the institution's own domains.

Manage alternative resolvers without confusing encryption and policy

Encrypted DNS protects a transport path; it does not by itself say which security policy the resolver applies. A managed device can use encrypted DNS appropriately, while an unmanaged alternative resolver can take queries outside the institution's intended visibility.

Review operating-system, browser, VPN and security-client policies together. Decide which resolver paths are supported, then test their actual behaviour. Restrict unauthorised alternatives through the controls available in that environment, with documented exceptions where an application has a justified dependency.

The NCSC guidance on selecting protective DNS discusses deployment and provider assurance for organisations outside its own service eligibility. Use it to frame questions, while preserving the distinction between choosing a service and proving local coverage.

Avoid claiming that a firewall rule blocking ordinary DNS proves complete control. Applications can have independent resolution or connection behaviour. The DNS-over-HTTPS monitoring guide explains why the endpoint and network views must be considered together. Document the remaining gaps instead of presenting a nominal configuration as universal protection.

Run a pilot around public-service transactions

Consider a fictional municipality with a civic office, two libraries and staff who visit residents. Its first pilot includes a small managed-device group at each location and several mobile users. The team keeps the existing protections active while validating the new resolution path.

The acceptance exercise follows normal work: log in, open an authorised appointment, access a required document and submit a permitted test transaction. Use test accounts and non-production records where available. Include the service desk, because its staff will receive the first reports of unexpected blocks.

One library passes the office test but fails after a local connectivity failover. Investigation shows that the secondary connection advertises a different resolver. This is a coverage defect, even if the security dashboard for headquarters looks healthy. The team corrects that path before expanding the pilot.

A mobile laptop also needs evidence after its VPN disconnects. The remedy depends on the approved architecture, such as a managed roaming component or a different connection policy. Record the decision and rerun the relevant tests; do not assume that the office configuration travels with the user.

Expand by supported population once the owner accepts the evidence. Stop an expansion when an essential dependency has no workable support or recovery procedure.

Turn blocks into evidence the service desk can use

A blocked query shows that a policy decision occurred. It does not alone prove that a person clicked a malicious link, that malware ran, or that an attempted attack was prevented. Background activity, retries and cached application behaviour can produce repeated events.

Capture the timestamp, queried name, policy reason, resolver path and an authorised way to identify the affected asset. Preserve the relationship between an event and its source. A translated summary without the original reason can conceal whether the result came from a threat classification or a technical failure.

RFC 8914 defines Extended DNS Errors for communicating additional error context. Support and presentation vary, so ask what your resolver and client actually expose. Do not interpret an undifferentiated resolution error as a confirmed malicious-domain block.

Give the service desk a short triage sequence: establish which service is affected, determine whether the failure is policy-related, collect the minimum useful evidence, and route the case to the correct owner. For threat context, examine source provenance and freshness before escalating a reputation result into a broad restriction.

Keep diagnostic data inside approved channels. Domain histories and endpoint mappings can reveal sensitive working patterns even when no document contents are present.

Give exceptions an owner, scope and expiry

An urgent request to restore a public service deserves a fast review, not an automatic permanent bypass. First establish the failing dependency and whether the block is intentional. A compromised supplier site can also be a genuine business dependency.

Ask the service owner and security responder to agree the narrowest workable action. Limit an exception to the required destination, population and period where the platform supports that granularity. Avoid approving an entire shared hosting domain because one application component is needed.

Keep an exception record:

Affected service and precise dependency:
Evidence supporting the proposed action:
Known uncertainty or conflicting observations:
Approver and implementation owner:
Permitted population and destination scope:
Expiry and scheduled review:
Compensating monitoring:
Test confirming removal:

If the platform cannot enforce the required scope or expiry, name the compensating process and who will perform it. The exception is not self-managing merely because a ticket contains an end date.

Review recurring exceptions with the provider and application owner. Repeatedly extending the same bypass can indicate an unresolved classification problem, an unsupported integration or a dependency that needs a different design.

Decide failure behaviour before the next outage

Agree what happens if the resolver, network path or roaming component becomes unavailable. Availability and protection can fail differently. An alternate resolver may restore connectivity while removing the security policy; an alternate instance of the same service may still depend on the same failing network.

Test the approved recovery path with a bounded exercise and a restoration procedure. Confirm the effective policy after failover, the availability of internal names and the monitoring signal that tells staff the estate is degraded. Two configured addresses do not establish independent resilience.

Service owners should understand any emergency change that reduces protection, the person authorised to approve it and the conditions for restoring the normal path. Keep emergency contact details accessible when the main identity or collaboration service is unavailable.

Include the recovery test in handover to the managed provider. An architecture diagram cannot demonstrate who will answer at the relevant time or whether the current contract includes that action.

Review coverage and unresolved decisions, not a block counter

Use a short operational review: which populations have fresh coverage evidence, which paths remain unverified, which exceptions have expired, and which service-impacting incidents need a design change? Keep those questions attached to named owners.

A high block count can reflect repeated requests from one endpoint. It should trigger analysis rather than an unsupported claim about attacks prevented. The meaningful outcome is a functioning control with understood limits and a response process that preserves public services.

For one approved public domain involved in a block review, use the IsMalicious domain reputation check to collect dated external context. Keep that result alongside local DNS and endpoint evidence. IsMalicious provides threat context; the institution's resolver, network policy and incident process remain responsible for enforcement and the final decision.