DNS filtering has moved from a tick-box web policy tool into one of the cheapest, fastest layers of cyber defence a mid-market IT team can deploy. It blocks malicious domains before any connection is made, which means phishing pages do not load, ransomware cannot reach its command server, and employees on a hotel Wi-Fi get the same protection as those in head office. This guide explains how cloud-delivered DNS filtering actually works in 2026, what it stops, where it falls short, and how to evaluate a vendor when you have 200 users, no SOC, and a list of NIS2 controls to satisfy.
What is DNS filtering and how does it work in 2026?
DNS filtering inspects every domain name lookup a device makes and decides, based on policy and threat intelligence, whether to resolve it. Five things to know before you start evaluating:
- It works at the DNS layer, before the connection. A blocked domain never returns an IP address, so the malicious page never loads and the ransomware C2 channel never opens.
- Cloud-delivered DNS filtering replaces on-premise DNS appliances with a global Anycast resolver network. Updates apply to every device the moment a new threat is identified.
- Modern filtering analyses the query itself. Algorithms flag newly registered domains, AI-generated names, and patterns typical of DNS tunnelling.
- Identity-aware platforms attach policy to the user and device, not the IP address. A finance role gets different DNS rules than a contractor on an unmanaged laptop.
- It is one component of a broader security architecture. Cloud-managed SASE platforms like Jimber include DNS filtering as a standard layer, not as a separate licence.
How cloud-delivered DNS filtering actually works
Every time a device tries to reach a website, send an email, sync a SaaS tool, or check in with a software update server, it sends a DNS query first. That query asks a resolver to translate a human-readable name into an IP address. Cloud-delivered DNS filtering sits in that path.
The query path, step by step
When a user types a URL into a browser or an application opens a connection, the device sends the DNS query to the configured resolver. In a cloud-delivered model, that resolver lives in a global Anycast network, which routes the request to the nearest Point of Presence. From there:
- The resolver identifies the source. For office locations, this happens through IP-based identification or an IPsec or GRE tunnel. For mobile and remote users, a lightweight roaming client identifies the device and user.
- The resolver checks the query against policy. Policy combines static block and allow lists, real-time threat intelligence feeds, category rules (gambling, adult, social), and identity context if integrated with the IdP.
- Query-level analysis runs in parallel. The resolver inspects the domain itself: how recently it was registered, the lexical pattern of the name, the entropy of the subdomain, and whether the query type or volume looks abnormal.
- The resolver decides. If clean, it returns the IP. If malicious, it applies sinkholing, returning a controlled IP that points to a block page or quarantine handler. The IT team gets an alert tied to the user, device, and domain.
This whole process adds 5 to 50 milliseconds for users near a Point of Presence, which is imperceptible. Without a nearby PoP, latency can climb above 100 ms and users start noticing.
Threat intelligence and the role of AI
The policy engine is only as good as its data. Modern DNS resolvers process billions of queries per day across their customer base. That scale is the source of their threat intelligence. When a new phishing domain is detected at one customer in Brussels, the block applies to every customer globally within minutes.
This is where cloud-delivered DNS filtering pulls decisively ahead of on-premise filtering. Industry research from 2025 found that the average lifespan of a phishing domain is under four hours. By the time a static block list is updated and pushed to a legacy appliance, the campaign has already moved on. Real-time threat feeds, paired with behavioural analysis, are the only mechanism that keeps pace.
DNS-layer AI in 2026 looks for several things at once. Newly Observed Domains, registered in the last 24 to 72 hours, get extra scrutiny. Domain Generation Algorithm patterns, which produce thousands of nonsensical names per day for ransomware to rotate through, get flagged on lexical features alone. Fast-flux DNS, where the IP behind a malicious name changes every few minutes to evade takedown, gets caught by the rate of change.
Modern SASE platforms, including Jimber, run this analysis at the same PoP that handles SWG, ZTNA, and firewall policy. That means the DNS verdict is shared with the rest of the security stack instantly.
What attack types DNS filtering blocks, and where it stops short
DNS filtering is one of the highest-value security investments per euro for mid-market organisations. The reason is the sheer volume of attacks that depend on a successful DNS lookup.
What it stops
Phishing and credential theft. Phishing remains the dominant entry point for most breaches. ENISA’s 2025 threat landscape report identified phishing as the top initial access vector, and AI-generated lures have raised success rates significantly. Every phishing campaign needs a domain. Block the domain at the DNS layer and the campaign fails before the user can fall for it.
Command-and-control communication. Malware that lands on an endpoint, whether through a phishing attachment or a drive-by download, needs to reach its operator. That communication almost always goes through DNS. Block the C2 domain and the malware sits silent, unable to receive instructions or exfiltrate data.
Domain Generation Algorithm malware. Ransomware families like Conti and its descendants generate thousands of throwaway domains per day. Static lists never catch up. DNS filtering with AI-based DGA detection identifies the lexical pattern and blocks the entire family.
DNS tunnelling for data exfiltration. Some attackers encode stolen data into DNS queries themselves. A query to c2hlbGxvd29ybGQ.attacker.com looks like noise but carries payload data. Cloud DNS filters detect the abnormal volume and record types and shut the channel down.
Newly registered domains in general. Most malicious infrastructure is younger than a week. Blocking or warning on Newly Observed Domains by default catches a large share of campaigns that haven’t been classified yet.
Where DNS filtering falls short
Be honest with your stakeholders about the limits.
- Hard-coded IP addresses. Malware that bypasses DNS entirely and connects directly to an IP address will not be caught at the DNS layer. This is uncommon but it happens.
- Encrypted DNS to rogue resolvers. A user or piece of malware can configure DoH directly to a public resolver and bypass corporate policy. Endpoint controls and firewall rules need to enforce that all DNS traffic goes through the sanctioned resolver.
- Application-layer attacks. SQL injection, cross-site scripting, supply chain compromises in legitimate software. None of these are DNS problems. They need WAF, endpoint controls, and software supply chain management.
- Insider misuse of allowed domains. A user uploading sensitive data to a sanctioned cloud service is invisible to a DNS filter. CASB and DLP handle that layer.
DNS filtering is a foundational layer, not a complete security strategy. Treat it as the first checkpoint in a defence-in-depth architecture.
Cloud-delivered versus legacy on-premise DNS filtering
For most mid-market IT managers in 2026, the comparison is straightforward. Hybrid work, SaaS sprawl, and the speed of modern attacks have made on-premise DNS filtering operationally unworkable for organisations of 50 to 400 users. The table below shows where the gap actually sits.
| Dimension | Legacy on-premise | Cloud-delivered |
|---|---|---|
| Scalability | Hardware-bound, requires re-sizing or stacking | Elastic, scales with users instantly |
| Threat response time | Hours to days, dependent on signature pushes | Minutes, global threat intel applied to all tenants |
| Mobile and remote coverage | Requires VPN backhaul for off-network users | Native via roaming client or DoH |
| Identity integration | Limited to IP and subnet context | Direct IdP integration, per-user and per-group policy |
| Management overhead | Patching, hardware refresh, on-call duty | Vendor-operated, IT defines policy only |
| Cost structure | CapEx-heavy with periodic refresh cycles | Predictable per-user OpEx |
A 200-user organisation running an on-premise resolver typically spends one to two days per quarter on patching, log rotation, and capacity planning. A cloud-delivered alternative reduces that to policy review and incident response. For a small IT team, that is the difference between firefighting and strategic work.
The performance argument is also less clear-cut than vendors used to claim. On-premise resolvers respond in under one millisecond on the LAN. Cloud resolvers add 5 to 50 ms depending on PoP proximity. For European mid-market organisations, what matters is whether your provider has PoPs in Amsterdam, Brussels, Frankfurt, or London. If they do, the latency is invisible. If they do not, users in the Benelux will notice slower page loads.
How to evaluate a DNS filtering solution in 2026
The vendor landscape is crowded. Cisco Umbrella, DNSFilter, Cloudflare Gateway, and a long tail of standalone tools all promise the same outcome. The differences sit in how the policy engine is built, what data is processed, and where it lives. Use the criteria below to filter the noise.
1. AI-driven detection of new and AI-generated domains
Ask the vendor specifically how they detect Domain Generation Algorithm patterns and Newly Observed Domains. The answer should reference behavioural analysis, not just longer block lists. If the only detection mechanism is signature-based feeds, the product will lag behind the campaigns it is supposed to stop. Request data on time-to-block for new threat domains.
2. Identity and device posture integration
A modern DNS filter should pull identity from your IdP (Microsoft Entra ID, Okta, Google Workspace) and apply policy per user and per group. Better still, it should layer in device posture context so that the same user gets a different policy on a managed laptop versus a personal phone. If the vendor still talks primarily in terms of IP-based policy, they are behind the curve.
3. European data residency and jurisdictional clarity
For NIS2 and GDPR, where DNS logs live and who can access them is not optional. US-headquartered vendors fall under the CLOUD Act regardless of where their PoPs sit. A Frankfurt PoP operated by an American provider does not equal European data sovereignty. Evaluate where queries are inspected, where logs are stored, and which legal framework governs access requests. Jimber, headquartered in Belgium, processes traffic and stores logs within EU borders by default.
4. NIS2-aligned logging and audit reporting
Auditors want to see DNS query logs that can be correlated with user identity, device, and outcome. Verify that the vendor offers configurable log retention, SIEM streaming, and audit-ready reports. Ask whether their logging schema supports the evidence requirements outlined in CyberFundamentals (CyFun) at the level your organisation must reach.
5. SASE roadmap and platform fit
DNS filtering as a standalone product is increasingly hard to justify. The market is consolidating around platforms that combine DNS, SWG, CASB, ZTNA, and FWaaS in a single inspection pipeline. If you buy a standalone DNS tool today, will you still want it in two years when your wider security stack moves to SASE? Or are you better off picking a platform that includes DNS as one component from the start?
6. Encrypted DNS support
DNS over HTTPS (DoH) and DNS over TLS (DoT) are the privacy standard in 2026. A vendor that still relies primarily on UDP/53 in plaintext is signalling that their architecture has not kept up. Equally important: verify that the platform can intercept and inspect DoH traffic so that your policy is not bypassed by browsers or applications using their own resolvers.
7. Multi-tenant management for service partners
If your organisation works with an MSP, or if you are an MSP yourself, multi-tenant capability matters. One pane of glass to manage policies across customers, with shared templates and per-tenant isolation, is what makes DNS filtering operationally viable at scale.
DNS filtering as a SASE component versus standalone
The honest framing is that both paths can work, but they suit different stages of organisational maturity.
A standalone DNS filter makes sense when you need a fast, low-cost layer of protection and the rest of your security stack is not yet ready to consolidate. Deployment can be done in a day. The yield in blocked threats per euro spent is hard to beat. For a 50-user company that is still running on a basic firewall plus endpoint AV, adding standalone DNS filtering is a sensible quick win.
DNS filtering as part of a SASE platform makes sense when you are already evaluating how to consolidate firewalls, VPN, web filtering, and access control. Buying a standalone tool now means another vendor, another contract, another console. If you know that you will be moving to a converged architecture within 18 months, the cleaner path is to pick a SASE platform where DNS filtering is included as a layer.
This is where Jimber’s approach exemplifies the converged model. DNS filtering is not a bolt-on. It runs in the same single-pass inspection pipeline as ZTNA, SWG, FWaaS, and SD-WAN, and policies share identity context across all engines. For a small IT team, the operational simplicity of one console, one policy framework, and one logging pipeline matters more than any single feature on a comparison sheet. Jimber’s network isolation platform ties the DNS layer to per-user and per-device policy by default. For agentless devices like printers, IP cameras, and industrial equipment, NIAC hardware extends DNS-aware controls to endpoints that cannot run software agents.
For a deeper architectural view of why DNS sits where it does in a Zero Trust stack, our earlier piece on DNS security in Zero Trust covers the design rationale. This guide focuses on the buyer-evaluation question. The two pieces are complementary.
NIS2 and CyFun implications for DNS-level protection
NIS2 went live in Belgium in October 2024. Essential entities must reach Basic or Important CyberFundamentals verification by 18 April 2026. Important entities can do the same voluntarily. DNS filtering is not named explicitly in Article 21, but it sits squarely inside several of the technical and organisational measures auditors expect to see.
Network security and threat detection. Article 21 requires appropriate measures to manage cyber risks. A documented DNS filtering policy with logging, identity context, and threat intelligence is one of the clearest demonstrations of network-level threat detection at the audit table.
Incident handling and reporting timelines. NIS2 mandates initial incident notification within 24 hours and a detailed assessment within 72. DNS query logs, correlated with user and device, are often the fastest evidence trail when reconstructing how a phishing campaign reached the organisation or how a piece of malware tried to communicate out.
Supply chain security. Article 21 explicitly demands that organisations manage the security of their suppliers. DNS filtering can enforce policy on outbound communication to third-party domains and flag interactions with new or unverified suppliers.
CyFun framework alignment. The CCB’s CyFun framework is the practical translation of NIS2 into Belgian organisational reality. CyFun’s 2025 edition aligns with NIST CSF 2.0 and adds Governance as a sixth function. DNS-level protection touches Identify (visibility into outbound traffic), Protect (blocking malicious domains), and Detect (logging and alerting). At the Important and Essential levels, auditors expect to see these controls operating with identity context and audit-ready evidence.
For financial services entities subject to DORA, the requirements go further. DNS infrastructure integrity, redundancy, and DNSSEC validation are now baseline expectations for critical entities under DORA’s operational resilience pillar.
Frequently asked questions
What is DNS filtering and what does it do?
DNS filtering inspects domain name lookups before they resolve and blocks the ones associated with malicious or unwanted destinations. It stops phishing, ransomware command-and-control traffic, and access to inappropriate content at the network layer, before any connection to the destination is made. In 2026, modern DNS filtering also includes behavioural analysis to catch AI-generated domains and DNS tunnelling.
How does DNS filtering work?
A device sends a DNS query to a resolver. In a cloud-delivered DNS filter, that resolver checks the requested domain against policy, threat intelligence feeds, and behavioural rules. If the domain is malicious or against policy, the resolver returns a sinkhole address instead of the real IP, which prevents the connection. The IT team gets an event log showing which user and device triggered the block.
Is DNS filtering worth it for a mid-market organisation?
Yes. DNS filtering offers one of the highest returns per euro of any security control. It blocks a large share of phishing and ransomware delivery without endpoint agents, without VPN backhaul, and without specialist staff. For an organisation of 50 to 400 users with a small IT team, it is one of the lowest-effort, highest-impact layers to deploy.
What does a DNS filter block that a firewall does not?
A traditional firewall inspects traffic by IP address, port, and protocol. It typically lets DNS traffic through on port 53 with little inspection. A DNS filter inspects the content of the query itself, including the domain name, the type of record requested, and the lookup pattern. That allows it to detect newly registered domains, AI-generated domains, and DNS tunnelling, all of which are invisible to most firewalls.
Will DNS filtering slow down internet performance?
In a cloud-delivered model with a nearby Point of Presence, the added latency is typically 5 to 50 milliseconds, which is invisible to users. If the provider has no PoP in your region, latency can climb past 100 ms and become noticeable. For European organisations, verify that the vendor operates PoPs in Amsterdam, Brussels, Frankfurt, or London before signing.
Can DNS filtering replace my web gateway or firewall?
No. DNS filtering blocks domains at the resolution layer. A Secure Web Gateway inspects the actual HTTP and HTTPS traffic, including TLS-decrypted content, file downloads, and category-based browsing rules. A firewall enforces port and protocol policy. The three layers work together. A unified SASE platform combines them in a single pipeline.
DNS filtering on its own is a quick win. DNS filtering as part of a converged SASE platform is the foundation of a defensible architecture. If your team is evaluating either path, the most useful next step is to map your current DNS coverage against NIS2 and CyFun expectations and see where the gaps sit. Book a demo with Jimber to see how DNS filtering, identity-aware access, and inline isolation work together in one console, with European data residency by default.
