What Is DNS Filtering? Protective DNS Mechanics & UK Guide

What Is DNS Filtering? Core Resolution Mechanics

DNS filtering operates directly on the mechanism that maps human-readable domain names to numerical IP addresses. When a user enters a URL, clicks a link in an email, or an automated process initiates an external request, the client dispatches a query to its designated recursive resolver. In a standard design, that resolver may query root, top-level domain (TLD) and authoritative name servers, or return a cached answer, to retrieve the corresponding record and return it to the client, allowing the application to initiate a network connection.

Under a DNS filtering or Protective DNS architecture, the recursive resolver intercepts that query and assesses the target domain against a continuously updated repository of policy rules and threat categorisations before answering. If the destination domain is flagged as malicious—such as an active phishing page or a known malware command-and-control (C2) endpoint—the resolver executes a policy action rather than returning the legitimate IP address. Common policy actions include dropping the query entirely (NXDOMAIN) or directing the client to a local sinkhole IP address that serves an administrative block page.

Crucially, this intervention occurs before any session packets are exchanged with the target server. Because the resolver prevents successful name resolution, the client cannot initiate new TCP/TLS sessions to the blocked destination, so it cannot download payloads, run remote scripts, or send credential data to that host. To understand the fundamentals of DNS within wider network infrastructure, organisations must treat the lookup phase as a perimeter boundary that evaluates intent before routing traffic.

• •Resolves domain lookups into policy actions prior to transport-layer connection initiation.
• •Prevents payload retrieval, browser-based credential entry, and background C2 beacons at name resolution.
• •Operates independently of downstream application protocols, covering any network tool that relies on standard DNS resolution.

UK Protective DNS: NCSC Frameworks and Sector Eligibility

In the UK, DNS-level security is anchored nationally by the NCSC's Protective DNS (PDNS) capability. Protective DNS forms part of the NCSC Active Cyber Defence portfolio and is mandated by the Cabinet Office for use across central government departments. The UK government treats PDNS as an essential baseline control designed to safeguard official networks from broad-scale malware distribution and targeted cyber attacks.

Beyond central government departments, the NCSC makes PDNS available to other eligible public and civic institutions, maintaining a process where organisation eligibility is checked continuously. Eligibility criteria have broadened over time to include central government departments, a range of public sector bodies, schools, and pilot programmes in social housing and adult social care.

A designated schools initiative outlines specific eligible entities: local authorities in England managing maintained schools; relevant public sector networks across Scotland, Wales, and Northern Ireland; school internet service providers (ISPs) in England with wide reach; and multi-academy trusts (MATs), academies, or independent schools equipped to implement the service directly. In addition, NCSC pilot frameworks have included UK registered social housing providers and arms-length management organisations (ALMOs), while an adult social care pilot has been renewed into 2026–27, providing a limited allocation of free PDNS licences for private care providers.

Encrypted DNS: Handling DoH, DoT, and Bypass Vectors

While network-level DNS filtering provides broad architectural coverage, the rise of encrypted DNS transport protocols introduces significant evasion paths that IT teams must deliberately mitigate. Traditionally, DNS operates over unencrypted UDP or TCP port 53, enabling network firewalls and local recursive resolvers to transparently monitor, intercept, and enforce policies on every outbound query.

Modern applications and operating systems increasingly support DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). DNS-over-TLS encapsulates DNS queries within standard TLS sessions over dedicated TCP port 853. Because this traffic uses a distinct port, network administrators can reliably block outbound port 853 at the perimeter firewall, forcing standard clients to fall back to the organisation's local, filtered resolver.

DNS-over-HTTPS presents a more complex challenge. DoH encapsulates DNS traffic inside standard HTTPS packets over port 443, making it indistinguishable from routine encrypted web traffic at the layer-4 network boundary. If a browser or local operating system initiates DoH directly to its own external public resolver, the lookup bypasses the corporate resolver entirely. Under these conditions, upstream network filters—such as Cisco Umbrella or network-edge appliances—never receive the query and cannot apply security policies, rendering perimeter DNS filtering ineffective for that application.

To neutralise DoH bypasses on managed endpoints, system administrators must enforce strict browser group policies: in Google Chrome, configure 'DnsOverHttpsMode' to 'off' or pin it to the corporate provider; in Mozilla Firefox, set 'network.trr.mode' to 5 (disabled) or disable DNS-over-HTTPS within network settings; and in Microsoft Edge, ensure 'Use secure DNS' is set to off or pointed exclusively at the internal secure resolver. Beyond DoH, IT teams must recognise other bypass vectors identified in enterprise security analyses, including direct-to-IP connections that skip domain lookups altogether, custom local adapter resolver configurations, and third-party VPN clients that tunnel resolution beyond local network inspection.

UK Market Costs: Commercial Benchmarks and Procurement

For UK commercial enterprises, charities, and organisations outside the scope of NCSC's free PDNS offerings, at typical UK price points of around £0.72–£2.50 per user per month, DNS filtering is a relatively low-cost control within many enterprise cyber‑defence budgets. Pricing structures in the UK market are typically billed on a per-user, per-month subscription model, allowing predictable operational expenditure that scales directly with headcount.

Procurement through the UK Government Digital Marketplace G-Cloud 14 framework provides clear pricing visibility for protective DNS and content filtering. One verified service listing shows a price point of £0.72 per user per month, with educational sector discounts available to lower the cost floor further for learning institutions.

Independent UK commercial vendors offer tiered structures based on feature requirements and policy granularity. Commercial pricing data from one UK provider, NetGuard, illustrates a tiered structure with entry-level DNS filtering at £1.00 per user per month, a mid-tier at £1.80, and £2.50 per user per month for a higher-tier configuration. Even at the top commercial tier in the example pricing, maintaining a baseline DNS protection layer is typically significantly cheaper than full‑stack Secure Web Gateway (SWG) or advanced endpoint security suites, offering high barrier-to-entry protection for resource-constrained UK IT departments looking to implement robust ransomware protection.

The Technical Limits of DNS-Based Security

To deploy DNS filtering effectively, engineering teams must maintain complete clarity regarding what the mechanism can and cannot accomplish. DNS filtering is fundamentally a name resolution gatekeeper; it does not perform deep packet inspection, TLS decryption, or web content categorisation beyond the domain level.

Because DNS queries only communicate the fully qualified domain name (FQDN), the resolver has zero visibility into specific URL pathways, parameters, or page-level payloads. For instance, if an attacker hosts a malicious credential-harvesting form or malicious script on a reputable, shared cloud service, categorising or blocking the entire top-level platform domain via DNS would induce massive operational disruption by disabling legitimate business tooling. A pure DNS‑layer filter cannot allow 'service.example.com/legitimate' while blocking 'service.example.com/malicious-path'; at the DNS layer it must either allow or deny resolution for the entire host.

Furthermore, DNS filtering offers no defensive posture once a connection is established. It cannot scan downloaded executable files for zero-day signatures, block active cross-site scripting (XSS) within a browser session, or identify compromised API tokens transmitted over established HTTPS streams. Consequently, DNS filtering must be understood as an early-stage perimeter filter rather than a standalone replacement for endpoint detection and response (EDR), managed detection capabilities, or browser security controls.

Implementation Guide: Deploying and Securing DNS Controls

A robust deployment of protective DNS requires coordination across network routing, perimeter egress firewalls, and client endpoint configuration. Simply changing the forwarders on an internal Active Directory or local DHCP server is insufficient if clients retain the technical freedom to route queries externally. In smaller or single-router environments where filtering is applied at the router level, because some modern browsers can use DoH, router‑level DNS filtering may not work for that browser unless DoH is disabled or the browser is pointed at a filtered DoH endpoint.

Step one requires configuring all internal recursive resolvers—such as corporate domain controllers or local DNS forwarders—to send their external upstream queries exclusively to the designated protective DNS service IP addresses. Once internal resolution is aligned, administrators must inspect their network boundary.

Step two involves configuring egress firewall rules to restrict outbound traffic. Firewalls should block all outbound UDP and TCP traffic on port 53 originating from general client subnets, ensuring that only authorised internal DNS servers can send lookups to external networks. Concurrently, firewalls must block outbound TCP and UDP on port 853 to prevent clients from establishing autonomous DNS-over-TLS tunnels to third-party public resolvers.

Step three addresses browser-level and mobile bypasses. Through Mobile Device Management (MDM) or Group Policy Objects (GPO), IT administrators must lock down browser configurations. By enforcing policies that set Chrome's 'DnsOverHttpsMode' to off (or current provider), Firefox's 'network.trr.mode' to 5, and locking Edge's 'Use secure DNS' settings to off or the current provider, the organisation ensures that client software respects local network resolver assignments rather than establishing out-of-band encrypted tunnels.

Integration and Decision Framework for UK IT Leaders

When evaluating DNS filtering solutions, UK IT leaders should structure their decision around public sector qualification, operational scale, and endpoint roaming requirements.

Public sector bodies, maintained schools, MATs, and eligible care organisations must first audit their qualification for NCSC Protective DNS. Because PDNS provides free, nationally backed threat protection, verifying eligibility against current Active Cyber Defence criteria should be the first step before evaluating paid alternatives.

For commercial environments or organisations requiring granular policy control, the key technical requirement is roaming endpoint agent support. Agents enforce protective policies on off-network laptops and remote devices, preventing bypasses from unmanaged local resolvers or public Wi-Fi networks.

Sources

Every figure in this article traces to the sources below.

• •NCSC — Protective DNS service details and public sector eligibility
• •NCSC — Active Cyber Defence services eligibility and pilot programmes
• •NCSC — PDNS for Schools deployment scope across UK education
• •Government Digital Marketplace — G-Cloud 14 protective DNS pricing
• •Decryption Digest — Enterprise DNS security and DoH/DoT policy configurations
• •Dope Security — Encrypted DNS bypass mechanics and alternative vectors
• •CyberFOX — Troubleshooting DNS filtering and browser secure DNS settings
• •BroadbandSwitch — UK router-level DNS filtering and browser DoH implications
• •RCPA / NCSC — Adult social care PDNS pilot extension and licence allocation
• •NetGuard — Commercial UK DNS filtering subscription pricing tiers