DNS filtering for small business: what it is and why it matters

Most small business security stacks have a firewall, endpoint protection on the workstations, and some form of email filtering. The layer that is missing most often is DNS filtering – which is unfortunate, because it is one of the cheapest, fastest-to-deploy, and highest-leverage controls available to an SMB. A meaningful percentage of phishing clicks, malware infections, and ransomware command-and-control connections start with a DNS lookup, and DNS filtering refuses to resolve the domain before any of that can happen.

This article explains what DNS filtering actually does at the protocol level, why it matters more than its modest reputation suggests, the categories that typically get blocked, the recognizable SMB-grade options (free and commercial), how it fits with the rest of the security stack, the deployment patterns that work and the ones that quietly fail, and the honest read on when to deploy it yourself versus when to hand it to a managed provider.

It is written for SMB owners, office managers, and IT generalists who have heard “you should have DNS filtering” enough times to want to understand it before buying. If you are working through a broader network or security baseline, the upstream reads are business firewall explained: what it does and why you need one and the network security checklist for small business.

Short answer

DNS filtering blocks DNS lookups for known-malicious and high-risk domains before any connection is made. It works by replacing your network’s DNS resolver with a filtering one (free options like Cloudflare 1.1.1.1 for Families or Quad9, commercial options like Cisco Umbrella, DNSFilter, Cloudflare Gateway, or NextDNS), enforcing the resolver at the firewall and DHCP so every device on every VLAN inherits it, and configuring category blocks for malware, phishing, command-and-control, newly-registered domains, and risky categories like anonymous proxies. A free deployment for a single-site office takes 30 minutes. A commercial deployment with reporting and roaming clients takes a half day plus a week of tuning. It catches a meaningful percentage of attacks that nothing else in the stack will see and is worth deploying even at the smallest SMB scale.

DNS filtering at a glance

Question	Short answer
What does it block?	DNS lookups for malware, phishing, C2, newly-registered domains, and policy categories
When does it intercept?	Before any TCP connection is made – the resolver returns NXDOMAIN or a sinkhole IP
What protocol does it run on?	DNS (UDP/TCP 53), DNS-over-HTTPS, DNS-over-TLS
Does it work for off-network devices?	Only with a roaming client or a network-wide tunnel (Cloudflare Gateway, Umbrella roaming, NextDNS app)
Does it inspect packet contents?	No – it only sees the domain being looked up, not the traffic itself
Does it replace a firewall?	No – it is a complementary layer, not a substitute
Does it replace endpoint protection?	No – it cannot catch attacks that bypass DNS or use IP literals
What does it cost at SMB scale?	Free options exist; commercial runs $2-$5 per user per month
How long to deploy?	30 minutes for free, half a day for commercial with reporting
What is the biggest deployment mistake?	Filtering only the corporate VLAN and leaving guest, IoT, and voice on ISP DNS

What DNS filtering actually does at the protocol level

Every internet connection starts with a DNS lookup. When a browser, an application, or a piece of malware wants to reach example.com, the operating system asks a DNS resolver “what is the IP address for example.com?” The resolver returns an IP, the connection is opened, and traffic flows. DNS is the address book that the entire internet uses to translate human-readable names into machine-readable IP addresses.

DNS filtering inserts a check at exactly that step. Instead of using the ISP’s DNS resolver (which answers every query, malicious or not), the network uses a filtering resolver that checks each domain against a threat intelligence database before answering. If the domain is on the block list – known malware infrastructure, known phishing host, known C2 domain, newly-registered suspicious domain – the resolver returns NXDOMAIN (no such domain) or sinkholes the response to a safe page that tells the user the request was blocked.

The crucial detail is that this happens before any connection is made. The malicious server never receives a TCP SYN. The endpoint never sees a malicious payload. The firewall never has to make a decision about the traffic, because the traffic never starts. If a phishing email gets past the email filter and a user clicks the link, DNS filtering can refuse to resolve the phishing site and the attack stops at the resolver. If a piece of malware on a workstation tries to beacon to its command-and-control infrastructure, DNS filtering can refuse to resolve the C2 domain and the malware loses its callback channel.

This is fundamentally different from a firewall, which makes decisions based on IP addresses and ports after the connection has been attempted. It is also fundamentally different from endpoint protection, which has to inspect the malicious payload after it has reached the device. DNS filtering operates at a layer that sits before either of them – cheap to enforce, lightweight to run, and effective even when the rest of the stack has gaps.

Why DNS filtering is one of the highest-leverage SMB security controls

Three things make DNS filtering disproportionately valuable for small businesses.

Most attacks start with a DNS lookup. Phishing sites are hosted on domains the user navigates to by clicking a link. Malware downloads come from domains the dropper resolves before fetching the payload. Ransomware C2 infrastructure is reached by domain, not by hardcoded IP. Drive-by browser exploit kits are served from domains. Threat intelligence feeds catch these domains within hours of their first observed use, and once they are on the feed, the DNS filter refuses to resolve them. The same defense applies to every endpoint on the network with zero per-device configuration.

DNS filtering protects devices that nothing else can. The printer in the lobby. The IP camera in the warehouse. The thermostat that is somehow on the corporate network. The conference room TV that auto-updates from somewhere. None of these have an EDR agent. None of these will accept a security policy push. All of them resolve DNS through whatever the DHCP server hands them, and if the DHCP server hands them a filtering resolver, they get the same protection as a managed laptop. This matters because IoT devices are routinely compromised and used as launch points for internal attacks – DNS filtering at the network level catches outbound malicious lookups from those devices even when there is no other agent on them.

It is the cheapest layer in the stack by a wide margin. Free options (Cloudflare 1.1.1.1 for Families, Quad9) cost nothing and deploy in 30 minutes. Commercial options at SMB scale run $2 to $5 per user per month. Compare that to EDR ($5-$15 per endpoint per month), email security ($3-$8 per user per month), or a next-gen firewall ($1,000-$3,000 for the appliance plus annual subscriptions). DNS filtering is the lowest-cost meaningful layer of defense available to a small business. Skipping it because of cost is not a real argument.

What gets blocked

Commercial DNS filtering services categorize domains and let the customer choose which categories to block. The categories that matter for SMB security divide into three groups: must-block, should-block-by-default, and policy-driven.

Must-block (security categories). These exist for one reason – to stop attacks. There is essentially no legitimate business reason to allow them.

• Malware. Domains hosting or distributing malicious software. Blocked everywhere, always.
• Phishing. Domains impersonating banks, payroll services, Microsoft 365 login, DocuSign, and the rest of the standard phishing target list. Blocked everywhere, always.
• Command and control (C2). Domains used by malware to contact its operator. Blocked everywhere, always. This is the category that turns a successful initial compromise into a contained one – if the malware cannot phone home, the attacker cannot drive the rest of the attack.
• Newly registered domains. Domains registered in the last 7 to 30 days. A meaningful percentage of phishing infrastructure uses domains that did not exist last week. Blocking newly-registered domains by default catches phishing campaigns before threat intel feeds have caught up. Whitelist legitimate newly-registered domains as they come up (your marketing team’s new campaign, a new vendor) instead of leaving the category open.
• DNS tunneling and dynamic DNS. Domains used as data exfiltration channels (encoding stolen data into DNS queries) or as moving-target C2 hosts. Block by default.
• Cryptomining. Domains hosting crypto-mining JavaScript or pool endpoints. These steal CPU cycles, hike cloud bills, and sometimes indicate a compromise. Block by default.

Should-block-by-default (policy/security overlap). Categories where blocking provides security and policy benefit, with rare legitimate exceptions.

• Anonymous proxies, Tor exit nodes, VPN-evasion services. These categories exist primarily to evade controls. Block at the office, allow exceptions for documented use cases (security research, legitimate privacy tooling).
• Adult content. Usually blocked for policy reasons (HR liability, professional environment) as much as security reasons.
• Gambling. Same logic – policy more than security, though gambling domains are an above-average vector for malware-laden ads.
• Peer-to-peer file sharing, warez, hacking sites. Above-average malware exposure, no business use, block by default.

Policy-driven (business decision). Categories that some businesses want to block and others want to allow.

• Social media, streaming media, shopping. These have no security justification for blocking – the decision is purely policy. Block social during work hours, allow on the guest VLAN, or do not block at all. None of the answers is wrong; the right answer depends on the workforce and the culture.

A reasonable default block list for a small business security baseline is the entire must-block group plus the should-block-by-default group. Policy categories can be turned on as separate decisions, ideally with leadership approval rather than IT discretion.

How DNS filtering fits in a layered security stack

DNS filtering is one layer in a defense-in-depth stack, not a replacement for any other layer. The honest framing is to understand what each layer catches and what each layer misses.

Layer	What it catches	What it misses
Email security	Phishing emails before delivery, malicious attachments, spoofing	Phishing that gets delivered, malware downloaded from non-email channels
DNS filtering	Lookups for known-malicious domains, C2 callbacks, newly-registered phishing	Attacks using IP literals, DNS-over-HTTPS bypass, novel domains not on feeds
Firewall (NGFW with IPS)	Known attack signatures, exploit attempts, outbound C2 by IP, application-layer threats	Encrypted attack traffic without SSL inspection, novel attacks
Endpoint protection (EDR)	Malicious behavior on the endpoint regardless of how it arrived	Attacks before they reach the endpoint, infrastructure-level threats
MFA + identity controls	Credential theft, account takeover	Session hijacking, MFA fatigue attacks, insider threats

The phishing example walks through how the layers cooperate. An attacker sends a phishing email. Email security blocks 80-90% of phishing attempts before delivery. One gets through. The user clicks the link. DNS filtering refuses to resolve the phishing domain (it is on the feed). Attack stops. If DNS filtering misses it (novel domain, not yet flagged), the firewall’s IPS may catch the malicious page content. If that misses, the endpoint protection should catch the credential-stealing behavior on the device. If that misses, MFA stops the attacker from logging in with the stolen credentials. No single layer is expected to catch 100% – the stack is designed so that the gaps in one layer are covered by another.

DNS filtering is the second-cheapest layer to deploy (after MFA) and one of the broadest in coverage. Removing it from the stack leaves a hole that nothing else covers cleanly – the gap between “email security missed it” and “endpoint protection has to detect malicious behavior after the malware is already running.”

Recognizable DNS filtering options at SMB scale

The market splits into free options, prosumer options, and managed commercial options. All three are legitimate at different price points.

Free options.

• Cloudflare 1.1.1.1 for Families (1.1.1.2, 1.1.1.3). Free public resolver with malware and adult-content filtering. Set as the DNS on the firewall and every device on the network inherits it. Zero reporting, zero category control, but it blocks the must-block list. Acceptable for a 5-person office that wants to add a layer without a budget.
• Quad9 (9.9.9.9). Free public resolver with malware and phishing filtering backed by IBM threat intelligence. Same deployment model as Cloudflare 1.1.1.1 for Families. No reporting, no customization.
• OpenDNS Home (free tier). Free for personal use, allows basic category control through a web dashboard. Used in some very small SMB deployments, though the free tier is limited to one network with a static IP.

Prosumer options.

• NextDNS. Subscription service ($2-$3 per month per device or per network) with full category control, custom block lists, allow lists, logging, and a roaming client for off-network devices. Aimed at technical SMBs and prosumers. Strong fit for very small businesses where the owner is comfortable in a configuration dashboard.
• ControlD. Similar pricing model to NextDNS. Strong reporting and category control. Smaller customer base but legitimate offering.

Commercial / managed options.

• Cisco Umbrella. The original commercial DNS security product, formerly OpenDNS Umbrella. Strong threat intelligence, robust reporting, roaming clients for Windows/Mac, integrations with the broader Cisco security stack. Typically $2-$5 per user per month at SMB scale. The default choice in many managed-services deployments.
• Cloudflare Gateway (part of Cloudflare Zero Trust). DNS filtering with strong category control, roaming clients, and tight integration with Cloudflare Access for ZTNA. Free tier for up to 50 users on the basic plan, paid tiers from $7 per user per month. Strong fit if you are already using Cloudflare for other services.
• DNSFilter. Specialist DNS filtering provider with strong threat intel and a clean reporting dashboard. $1.50-$3 per user per month depending on tier. Common in MSP-managed deployments.
• Webroot DNS Protection, Akamai ETP, Infoblox. Enterprise-grade options that some MSPs resell into the SMB market. Capable, but usually more product than an SMB needs unless compliance requires the higher tier.

There is no single right answer. For an office with a budget of zero, Cloudflare 1.1.1.1 for Families or Quad9 on the firewall is a real upgrade over ISP DNS. For an office that wants reporting and the ability to investigate “what did this user try to reach last Tuesday,” a paid service is worth the $2-$5 per user. The wrong answer is “we will get to it eventually” – the deployment effort for the free options is too small to justify deferring.

How to deploy DNS filtering correctly

There are four enforcement points to consider, and the right deployment uses all four.

1. The firewall. Set the firewall’s upstream DNS to the filtering resolver. This catches every device that uses the firewall’s resolver as a relay, and it is the foundation of network-wide enforcement.

2. DHCP. Configure the DHCP scope on every VLAN – corporate, guest, IoT, voice – to hand out the filtering resolver as the DNS server. This is what makes the filtering inherit to every device that gets an IP from DHCP. The mistake to avoid is filtering only the corporate VLAN and leaving guest and IoT on ISP DNS, because compromised IoT and risky guest devices are exactly the traffic the filter needs to see.

3. Block bypass attempts at the firewall. Some devices and applications hardcode their DNS to 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) and ignore DHCP-assigned DNS. A misconfigured Windows machine, a phone tethered to the WiFi, a Chromecast, a piece of malware deliberately bypassing the local resolver – all common. The fix is a firewall rule that redirects all outbound port 53 traffic to the filtering resolver, regardless of destination. Some firewalls call this DNS hijacking or transparent DNS proxying. It catches devices that try to bypass the resolver and forces them through the filter anyway. Pair it with blocking outbound DoH (DNS-over-HTTPS) endpoints where possible – Cloudflare, Google, and Quad9 publish DoH lists that can be added to the firewall’s blocklist so applications that try to encrypt their DNS to bypass enforcement get blocked.

4. Roaming clients for off-network devices. Laptops that leave the office – which at most SMBs is most of the laptops – need DNS filtering when they are on home networks, hotel WiFi, or coffee shop networks. Commercial DNS filtering services include a small client agent (Umbrella roaming, NextDNS app, Cloudflare WARP) that enforces the filter regardless of network. Deploy the agent through Intune, RMM, or whatever endpoint management is in place. Without the agent, the laptop loses DNS filtering the moment it leaves the office, which is when it is most likely to encounter phishing or drive-by infections.

If only three of the four are in place, the deployment has holes. Filter on the firewall but not on guest DHCP – guest VLAN is unprotected. Filter via DHCP but allow outbound DNS to anywhere – malware on the network can ignore the resolver. Filter at the network but no roaming client – half the workforce is unprotected the moment they leave the building. All four is the standard, not a stretch goal.

What DNS filtering does not catch

It is worth being honest about the gaps so the layer is deployed with realistic expectations, not magical ones.

• Connections to IP addresses directly. If malware skips DNS and connects to an IP literal, DNS filtering has nothing to see. This is uncommon for opportunistic malware (operators want flexibility, which DNS provides) but is real for some targeted attacks.
• DNS-over-HTTPS (DoH) that bypasses the resolver. Browsers (especially Firefox and Chrome) ship with DoH that can route DNS through Cloudflare or Google over HTTPS, ignoring the network’s resolver entirely. Mitigate by blocking outbound to known DoH endpoints at the firewall, by managing browser policy via Intune or AD GPO to disable browser-level DoH, and by enabling DoH-aware filtering at the resolver level on commercial services that support it.
• Novel domains not yet on threat feeds. A brand-new phishing domain registered an hour ago will not be on the feed yet. Newly-registered domain blocking catches a meaningful percentage of these, but not all. Endpoint protection and email filtering carry the rest.
• Encrypted command-and-control over HTTPS to a legitimate-looking domain. If the malware uses a compromised but otherwise reputable hostname for C2, DNS filtering will resolve it normally. The firewall and EDR have to catch the malicious behavior of the connection itself.
• Lateral movement within the network. Once an attacker is inside, internal movements between machines on the same VLAN do not generate external DNS lookups. Network segmentation, endpoint protection, and monitoring handle this layer.

None of these gaps is an argument against DNS filtering. They are reasons DNS filtering is one layer in the stack, not the whole stack.

DNS filtering versus DNS security versus DNSSEC – they are different things

There is some persistent confusion in SMB security conversations between three related but distinct concepts.

DNS filtering is what this article has been describing – blocking lookups for malicious or policy-restricted domains. The mechanism is a resolver that consults a block list and refuses to answer queries for bad domains.

DNS security (DNS-layer threat intelligence) is the broader category that includes DNS filtering plus richer logging, behavioral analytics on DNS patterns (catching DNS tunneling, data exfiltration via DNS), and integrations with the rest of the security stack. Commercial DNS filtering services (Umbrella, Cloudflare Gateway, DNSFilter) all fall into this category. The distinction is mostly marketing – any modern commercial DNS filter is doing DNS security.

DNSSEC is a completely different thing. It is a cryptographic mechanism that lets a DNS resolver verify that the answer it received from an authoritative server has not been tampered with in transit. DNSSEC protects against DNS cache poisoning and on-path attacks against the DNS protocol itself. It does not block malicious domains – a DNSSEC-signed phishing site resolves cleanly, because the signature only proves the answer is authentic, not that the domain is safe. DNSSEC and DNS filtering solve different problems, and a well-run network does both: DNSSEC validation at the resolver, and threat-based filtering on top.

If a vendor or a colleague conflates these, it is worth slowing the conversation down and clarifying which one is being discussed before making decisions.

How DNS filtering interacts with the rest of the network

DNS filtering does not exist in isolation. It interacts with several other network components, and the interactions matter for getting a clean deployment.

With the firewall. DNS filtering and the firewall complement each other. The firewall sees IP-level traffic; the DNS filter sees domain-level intent. A firewall log entry that says “blocked outbound to 203.0.113.45” is harder to act on than a DNS filter log entry that says “blocked DNS query for malicious-c2.example.com from 10.10.20.42.” Many commercial firewalls now include DNS filtering as a built-in feature (Fortinet, SonicWall, Meraki, Sophos) – if that feature is licensed, that is a valid deployment path. Standalone DNS filtering services give richer logging and roaming-client support.

With network monitoring. DNS filtering logs are some of the highest-signal data in the security stack. A spike in blocked queries from a single host is a strong indicator that the host is compromised – the malware is trying to phone home and failing. Network monitoring should ingest DNS filtering logs as one of its primary inputs. The depth on monitoring stack design is in network monitoring for small business: what to watch and how.

With endpoint detection and response (EDR). EDR catches malicious behavior on the device; DNS filtering catches the network-layer signal of the same compromise. Correlating EDR alerts with DNS filtering logs gives a much richer picture of what an incident looked like than either log source alone. The depth on EDR is in endpoint detection and response: what it is and how MSPs use it.

With guest WiFi and IoT segmentation. DNS filtering deployed at the firewall and on guest/IoT DHCP scopes is what makes those VLANs safe to operate. A guest VLAN that lets visitors freely resolve malicious domains is doing less work than it should. The depth on guest WiFi setup is in how to set up a guest WiFi network for your business, and on broader segmentation in VLANs explained for small business.

With email security. DNS filtering is the second line of defense for phishing. Email security catches phishing before delivery; DNS filtering catches the link click if delivery happens. Both layers are necessary because neither is complete – the layered model is covered in phishing attack prevention for small business: what actually works.

When to deploy yourself versus when to hand it to a managed provider

DNS filtering is one of the more DIY-friendly security controls. The decision to manage it in-house versus through an MSP depends on three factors.

Factor	Self-manage is reasonable when	Managed pays off when
Tooling familiarity	Someone in-house is comfortable with the firewall and DHCP configuration	No one wants to own DNS filtering as their day job
Reporting needs	A monthly check of the dashboard is enough	Compliance requires documented review, alerting, and tuning
Roaming clients	Endpoint management already exists and can push the agent	No endpoint management or no time to maintain it
Tuning workload	Initial setup plus quarterly review is the scope	Need someone to handle false-positive whitelisting requests within hours
Integration with other layers	DNS filtering will run as a standalone control	DNS filtering needs to feed monitoring + EDR + SIEM correlation
24/7 alerting	Acceptable to find out about blocked malicious queries during business hours	Want someone to call when a spike of blocked C2 queries hits at 3 AM

For a 5-15 person office with no compliance requirements, self-managing free or low-cost DNS filtering on the firewall and on DHCP is entirely reasonable. For a 25-100 person office with compliance overlay (HIPAA, PCI, CMMC, cyber insurance requirements), or a workforce that is mostly remote and needs roaming-client coverage, managed DNS filtering as part of a broader managed security service usually pays for itself.

The middle case – 15-25 person office, hybrid workforce, no compliance overlay – is a judgment call. Many in this range start self-managed and hand off when the maintenance burden (roaming clients, allow-list requests, log review) hits the threshold of “this is taking real time every week.” There is no shame in either path; what matters is that the layer is actually in place.

Common DNS filtering mistakes

The deployment fails the same way in most environments. These are the ten that show up repeatedly.

1. Deploying on the corporate VLAN only. Guest, IoT, voice, printers, and the camera system all stay on ISP DNS. Compromised devices on those VLANs get a free pass to call home. Fix: hand out the filtering resolver on every DHCP scope.

1. Not blocking outbound port 53 to anywhere except the resolver. Without the redirect rule, any device hardcoded to a different DNS (a misconfigured laptop, a curious user, a piece of malware) bypasses the filter. Fix: NAT or redirect all outbound DNS at the firewall to the filtering resolver.

1. Ignoring DNS-over-HTTPS. Modern browsers route DNS over HTTPS to Cloudflare or Google by default, completely bypassing the network resolver. Fix: disable browser DoH via group policy / Intune for managed devices, block outbound to known DoH endpoints at the firewall, and use a commercial filter that supports DoH-aware enforcement.

1. No roaming clients on laptops. The moment a laptop leaves the office, it is on whatever DNS the home router hands it. Often this is where the compromise happens. Fix: deploy a roaming client on every managed laptop via endpoint management.

1. Categories that should be blocked left allowed. Cryptomining, anonymous proxies, newly-registered domains, peer-to-peer – common defaults to leave on. Each one is an unnecessary risk. Fix: enable the security baseline categories at deployment and review quarterly.

1. No logging or no log review. A DNS filter that blocks queries silently is a half-deployed control. The logs tell you which hosts are infected and which users are stumbling into phishing links. Fix: route logs to a central destination (SIEM, syslog server, or the commercial service’s dashboard) and review weekly at minimum.

1. No allow-list process. Legitimate domains get false-positive blocked sometimes (a marketing team’s newly-registered campaign domain, a vendor’s legitimate but obscure URL). Without a clear process to request and approve allow-list additions, users start ignoring blocks or bypassing the filter. Fix: define a 24-hour SLA on allow-list reviews and assign an owner.

1. Filtering the DNS but not the rest of the stack. DNS filtering alone is not a security strategy. Without firewall, endpoint protection, email security, and MFA in place, the filter catches some attacks but leaves the rest of the stack exposed. Fix: deploy DNS filtering as a layer, not as a substitute.

1. No documentation of which resolver is in use and why. Three years later, no one remembers whether the filter is Cloudflare’s free service, the firewall’s built-in filtering, or a managed service – and the renewal date is unknown. Fix: document the resolver, the categories enabled, the renewal date, and the owner.

1. Treating it as a one-time deployment. Categories change, new attack patterns emerge, false-positive whitelists need pruning, the threat-feed quality of the chosen vendor drifts. Fix: a quarterly 30-minute review covering category settings, allow-list cleanup, and top-blocked-host investigation.

Time to value

DNS filtering produces results faster than any other security control because the blocking is immediate.

Outcome	Typical time
First malicious queries blocked	Day one (the logs start filling within hours)
First compromised host identified via blocked C2	Within first week to first month
First phishing link click blocked	Within first month
Reduction in measurable phishing-related incidents	1-3 months
Audit and compliance evidence collected	Within first quarter
Mature category tuning and clean allow list	3-6 months
Integrated with monitoring + EDR + SIEM for correlation	6-12 months at the longer end

The cheap wins arrive in the first week. The mature deployment – tuned, correlated, integrated with the rest of the stack – is a quarter or two of intentional work. The free version on the firewall produces 80% of the value in 30 minutes.

How DNS filtering fits with the rest of the network

DNS filtering is one of the controls that ties the network and security stacks together. Pairings worth understanding:

• With the network security checklist – DNS filtering is checklist item 13 of the practical security baseline.
• With the business firewall – many SMB firewalls include DNS filtering as a licensed feature.
• With the firewall setup – DNS filtering is one of the four outbound controls in the firewall baseline.
• With guest WiFi setup – guest VLAN DNS should run through the filter.
• With VLANs – every VLAN’s DHCP scope hands out the filter, including IoT and voice.
• With phishing prevention – DNS filtering is the second line of defense after email security.
• With endpoint detection and response – DNS filtering and EDR catch the same compromises at different layers, and correlation between them gives better visibility than either alone.
• With network monitoring – DNS filtering logs are some of the highest-signal data the monitoring stack ingests.
• With HIPAA cybersecurity requirements – DNS filtering is a reasonable component of the technical safeguards documented for HIPAA Security Rule compliance.

How Sequentur can help

If you want help selecting, deploying, or operating DNS filtering as part of a managed network or security service, schedule a call.