DNS filtering checklist for small teams: the free layer that blocks half the bad days

Every phishing link, every "your-invoice-is-here" domain and every sketchy redirect has to resolve through DNS before anything bad happens. Most small businesses leave that door wide open and spend their whole security budget on the rooms behind it. A filtering resolver — the kind free tiers of Cloudflare Gateway, Quad9 or CleanBrowsing offer — refuses to answer known-malicious and adult domains before the browser ever loads them. It is not antivirus and it will not save someone who pastes their password into a fake login page. But it kills a large share of drive-by and lure-traffic risk in one afternoon, for zero dollars, with no agent to install. This checklist is that afternoon.

1. Pick one filtering resolver and write down why

• Choose the baseline by what you need blocked. Quad9 (9.9.9.9) is a set-and-forget malware blocklist run by a nonprofit; CleanBrowsing's free family filter blocks malware and adult content; Cloudflare Gateway's free tier lets you see and tune the policy. Pick one, write the choice and date in the IT drawer — the same baseline instinct as the annual security review.
• One house resolver, not three. If the office laptop uses one service, the printer another and nobody knows what the router uses, you have three policies and no policy. The rule is the house rule from the WiFi checklist: one owned decision, written down.
• Know what DNS filtering cannot do. It will not block a phishing link on a domain that is five minutes old, and it does nothing for someone on a mobile hotspot. Say so in the note. A control with a known blind spot is honest; a control with a presumed one is a liability.

2. Set it on the router first — that covers guests and IoT for free

• Put the filtering resolver in the router's DHCP settings, not on each device. Every laptop, phone, printer and camera that joins the office network then inherits the policy, including visitor devices you will never manage. Two settings, five minutes, whole-building coverage.
• Then check nothing needed was blocked. Printers, payroll portals and point-of-sale tablets sometimes phone home to domains a family-tier filter hates. Walk the room and use each of them once. What breaks gets an exception in section 6, not a silent rollback to the ISP resolver.
• Leave the ISP resolver as the documented fallback. If the filtering service has an outage, you want a one-line note saying "the old DNS is 203.0.113.1, revert path: router admin, DHCP, DNS", not a support ticket during a payment run.

3. Turn on the category controls the tier already includes

• Enable safe search and restricted mode where the service supports it. CleanBrowsing and Cloudflare's family resolvers can force safe search on major engines and video sites by DNS alone. For an office with a shared front-desk machine, that is a ten-minute toggle that prevents most "I didn't search for that" conversations.
• Block the new-domain window if your tier offers it. Phishing kits burn domains in days. A "block domains registered in the last 7 days" rule (Cloudflare Gateway's free plan includes it) catches the burn-and-replace pattern that static blocklists miss.
• Keep the category list boring. Block malware, phishing, adult and — for most offices — gambling and recently-registered domains. Resist the urge to block shopping or social categories "for productivity": a filter that blocks people's lunch break gets disabled by lunchtime, and a disabled filter protects no one.

4. Test the filter like you would test a fire alarm

• Run a known-bad domain through it. The filter services publish their own test domains (Quad9's isitblocked.org and friends). From a wired office machine, a guest phone and the printer, resolve a test domain and confirm it fails or lands on a block page. A filter nobody has ever tested is a claim, not a control — the same reachability-test logic as the guest network in the WiFi checklist.
• Resolve a benign domain from the same devices. If example.com is fine but the test domain fails, the filter is working. If both fail, you have an outage, not a policy.
• Screenshot the result and date it. This is the quarterly evidence line: "filter tested 12 Sep, block confirmed on office LAN + guest SSID." It answers the customer-security-questionnaire question "do you filter malicious domains?" in one sentence, and feeds the annual review.

5. Handle the laptops that leave the building

• Name the gap out loud: DNS on the router only protects devices on that router. The sales laptop at a conference is on hotel WiFi with default DNS the moment it leaves. The fix in order of preference: install the vendor's lightweight roaming client or an MDM profile that pins the filtering resolver, or at minimum pin the resolver in the OS network settings so it survives network switches.
• Pair the roaming fix with the habits that already exist. Filtered DNS plus the always-on VPN discipline in the remote work checklist closes most of the road-warrior gap; the browser extension audit closes the rest of what a laptop is willing to run.
• Do not let perfect block the free win. If pinning the resolver on every laptop is a two-week project, ship the router change today and put the laptop pinning on the roadmap with an owner. Whole-office coverage this afternoon beats per-device coverage someday.

6. Log the exceptions before they become the back door

• Every exception gets an owner, a domain and a review date. The payroll portal that trips the malware category, the label-printer cloud that needs a whitelist entry — one line each in the same IT-drawer note. An untracked exception is a hole with a steward who forgot it.
• Decide who may change the DNS settings. One name. Router admin access is already restricted by the WiFi checklist — the DNS settings are the most valuable rows in that admin plane, and "everyone with the password" is not an access model.
• Write the break-glass rule. If the filter blocks something a customer demo genuinely needs mid-meeting, the permitted response is a logged exception by the named owner — not a quiet switch of the office resolver back to whatever the ISP defaults to, which is how last year's setup quietly returns.

7. The quarterly five-minute re-check

• Re-run the block test after any router or firmware change. Router replacements, ISP modem swaps and "helpful" office moves are how resolver settings get reset to defaults. The IoT checklist and the firmware pass in the WiFi checklist are the natural moments to re-test.
• Read the filter's status page or dashboard once a quarter. Free tiers still publish incidents. Five minutes skimming "was there an outage that week we blamed the ISP?" turns mystery slowness into a known event.
• Write the three-line pass: resolver, test result, exceptions changed. It slots into the same quarterly folder as the WiFi walk test and the physical security walkthrough, so the whole site layer gets reviewed in one sitting — and it is the cheapest real answer you will ever give an insurer or a customer questionnaire.

DNS filtering for a small team is one free afternoon: choose one filtering resolver and write down why, set it in the router so guests and IoT inherit it, switch on the safe-search and new-domain controls the tier already includes, test the block from a wired machine, a guest phone and the printer, pin the resolver on the laptops that travel, log every exception with an owner, and re-run the five-minute test each quarter after anything touches the router. The Ops Starter Kit ($14) turns the exception log and the quarterly pass into fill-in-the-blank sheets, and the Automation Starter Pack ($19) schedules the recurring checks so the re-test happens without anyone remembering to remember.