The short version
Every time a device on your network tries to reach a website, email server, or cloud service, it first asks "what's the IP address for that domain?" That question is a DNS lookup. DNS filtering intercepts that lookup and decides whether to answer it. If the destination is on a list of known-malicious or policy-blocked categories, the filter returns a block-page response instead of the real IP — and the malicious connection never happens.
The malicious site doesn't get the chance to load the credential-harvesting form, the ransomware dropper, the cryptojacker, the C2 channel. The attack stops at the front door.
Why it's so effective
Almost every modern attack involves a domain at some point. Phishing pages live on domains. Ransomware command-and-control runs through domains. Credential stuffing scripts callback to domains. Malware updates pull from domains. Block the lookup and you've cut the attacker's network leg out.
Threat-intelligence feeds catalogue new malicious domains within minutes to hours of registration. Business DNS filters subscribe to those feeds and update their block lists in close-to-real-time. The result: the phishing email that lands at 9:14 AM has a malicious link that stops resolving at 9:32 AM, before most of the recipients have clicked.
What it covers
- Known-malicious domains — phishing, malware C2, exploit kits, scam infrastructure.
- Category-based policy — block adult content, gambling, file-sharing, social media on company devices if you want; allow per role or per device exception.
- Newly-registered domains — many attacks use domains registered hours before use. A "block domains less than 30 days old" rule catches a meaningful slice.
- Typosquats — mocrosoft.com, paypa1.com, your-bank-com.support. Threat feeds catalogue these.
- DNS-tunneling exfiltration — attackers sometimes hide data theft inside DNS queries themselves. Modern filters detect the pattern.
What it doesn't cover
- Direct-IP attacks. If an attacker sends malware that connects to a raw IP address (no domain), DNS filtering doesn't see it. Rare for legitimate-looking attacks; common in already-on-endpoint malware.
- Encrypted DNS bypass. Browsers and apps can route DNS through HTTPS (DoH) to bypass local DNS resolution. Modern enterprise filters block DoH or enforce policy via an endpoint agent.
- Compromise after the connection. Once the connection completes (legitimate site, then malicious behavior), DNS filtering is done; EDR takes over.
- Insider threat. A user who's been told what to type still gets through.
Network-only vs. endpoint-agent deployment
Two common deployment patterns:
Network-only
The office network's router or firewall is configured to send DNS queries to the filter. Easy to deploy — one change at the router. Coverage gap: the laptop that goes home or to a coffee shop isn't protected. Adequate for a single-office business with desktops only.
Endpoint-agent
A small agent on every device enforces DNS filtering everywhere — office, home, coffee shop, hotel. Better coverage, slightly more deployment work. The right deployment for any business with laptops or remote workers.
Most modern business DNS filters (NextDNS for business, Cisco Umbrella, DNSFilter, ControlD) support both. The endpoint-agent mode is the standard for laptop fleets in 2026.
How it fits the rest of the stack
DNS filtering is one layer of defense-in-depth:
- Email security — catches the phishing email at the gateway.
- DNS filtering — catches the phishing link if the user clicks.
- Web isolation / browser security — catches the attempted exploit if the site loads.
- EDR — catches the malware behavior if anything landed on the device (see what is EDR?).
- MFA — catches the credential abuse if a password did leak (see what MFA actually buys you).
Any one of those alone is brittle. Together, they're hard to get past.
Why cyber insurance asks about it
Cyber carriers in 2026 increasingly ask about DNS filtering on the renewal application. It's cheap (a few dollars per device per month), low-friction (no user training, no behavior change), and statistically significant in claims data. A "yes" on DNS filtering moves the needle on the application even if no other change is made.
How a Micro-IT plan covers DNS filtering
Every Micro-IT client environment ships with NextDNS-based DNS filtering on every endpoint via the Managed Endpoint plan. Deployment is the endpoint-agent mode — coverage on the device wherever it goes. The policy is category-tuned per vertical (a clinic has a different default profile than a construction office), and reporting flows into the same monthly review as the rest of the stack. See Managed Endpoint for the included features, or the security page for the eleven-vendor, seven-layer stack.
How DNS filtering works, step by step
The mechanics are simple once you follow the path of a single request.
- The device asks for a domain. You click a link or an app reaches out. Before any data moves, the device asks a recursive resolver: "what is the IP address for this domain?"
- The filtering resolver checks the domain. Instead of a plain resolver, the request goes to a filtering resolver. It compares the domain against threat-intelligence feeds (known phishing, malware, and command-and-control infrastructure) and against your category policy (adult content, gambling, file-sharing, and so on).
- The resolver decides. If the domain is clean and allowed, it returns the real IP address and the connection proceeds normally. If the domain is malicious or blocked by policy, it refuses or sinkholes the answer — pointing the device to a harmless address — or returns the IP of a block page that tells the user why the site was stopped.
All of this happens in the lookup step, before the browser opens a single connection to the destination. That is why DNS filtering stops an attack at the front door rather than cleaning up after it. Implementing it means pointing your devices at a filtering resolver and setting the policy — the decision logic lives at the resolver, not on each machine.
DNS filtering vs. web and URL filtering
These controls work at different layers, and the names get used loosely. The short version: DNS filtering decides whether a connection is allowed to open at all; web and URL filtering inspect what travels over a connection once it is open.
- DNS filtering blocks at the domain level. It is fast and lightweight because it acts on the lookup — the smallest, earliest part of the request — and it catches the connection before it opens. It does not see the full web address path or the page contents.
- Web, URL, and "advanced URL filtering" use a proxy that sits in the traffic path. It can read the full path of a URL, inspect page content, and allow one page on a domain while blocking another. That granularity costs more processing and usually requires decrypting traffic, which is heavier to run.
They are not competitors. DNS filtering is the cheap, broad first layer that stops most known-bad domains for every device. URL filtering is the precise second layer for businesses that need page-level control or content inspection. Many environments run both: DNS filtering everywhere, URL filtering where the extra granularity earns its cost.
Rolling it out (and why it won't slow you down)
Enabling DNS filtering is a small project, not a migration. The practical steps:
- Choose a filtering resolver. A business DNS filtering service (NextDNS for business, Cisco Umbrella, DNSFilter, ControlD) gives you threat intelligence, category policy, and reporting.
- Point your DNS to it. Network-only deployment changes one setting at the router or firewall. Endpoint-agent deployment installs a small agent on each device so the policy follows laptops off the office network.
- Set category policy. Start with malicious and high-risk categories blocked for everyone, then tune by role or device.
- Plan for false positives. A legitimate site will occasionally land in a blocked category. An allowlist and a clear way for users to request an exception keeps this from becoming friction.
Does DNS filtering slow down your internet? No. It does not touch bandwidth — it only answers the address-lookup question, which is tiny. In practice it can make browsing feel faster, because the filtering resolver caches answers: once any device looks up a domain, the next lookup is near-instant. The added security comes with no real performance cost.