Protective DNS for small business: what it blocks and how to set it up

Key takeaways

• Protective DNS is a recursive resolver that refuses to answer lookups for domains on threat-intelligence lists. The device never learns the address, so the connection never starts.
• It blocks known-bad domains: malware delivery, phishing and command-and-control. It does not inspect traffic, and it misses anything that does not use your resolver.
• The simplest small business setup is at the router: change the DNS servers it hands out, and every device that takes automatic settings is covered.
• Test it on each device: confirm which resolver answers, then confirm a blocked test domain really is blocked.

What is protective DNS?

Every time a device opens a website or an app talks to a server, it first asks a DNS resolver for the address of a name. A protective DNS resolver checks that name against threat intelligence before it answers. If the name is on a block list, it refuses to give the real address.

NIST’s Secure DNS Deployment Guide (SP 800-81r3) describes the usual block response as an answer saying the name does not exist, such as NXDOMAIN. It also notes that the resolver can log queries that trigger a policy, as a sign that a device may be infected. CISA’s description of its own Protective DNS Resolver for US federal agencies lists the other common responses: the service “blocks, redirects, or sinkholes the query response”.

Device asks:  www.example.com      -> not on any list -> normal answer
Device asks:  bad-domain.example   -> matches threat feed
Resolver:     NXDOMAIN, or a block-page / sinkhole address
Resolver:     logs which client asked, the domain and the time
Result:       the connection to the malicious host never starts

For a small business the appeal is coverage. Printers, cameras, tills and smart TVs cannot run security software, but they all use DNS. One change on the network protects them too.

What does protective DNS block, and what does it miss?

It is good at one job: stopping lookups of domains already known to be malicious. It is not a firewall, and it only sees the names your devices send to it.

Protective DNS can help with	Protective DNS cannot help with
Phishing links to domains already on a block list	A brand-new phishing domain no list has seen yet
Malware downloads from known-bad domains	Malware delivered by email attachment or USB stick
An infected device trying to reach a known command-and-control domain	Connections made straight to an IP address, with no DNS lookup
Logging which client asked for a blocked name	Inspecting the content of pages, files or traffic
Every device that uses the resolver, without installing software	Devices, browsers or VPNs that send DNS somewhere else

The last row matters most. A browser with its own DNS over HTTPS (DoH, RFC 8484) setting, an app with a hard-coded resolver, or a VPN can all skip your protective resolver. NIST SP 800-81r3 describes this bypass and suggests blocking outbound plain DNS except from approved resolvers, blocking unapproved DNS over TLS on TCP port 853, and using device management to control which encrypted DNS services devices may use. For the privacy side of that trade-off, see DoH vs DoT.

Where can a small business turn on protective DNS?

There are three places to set it. Most small offices start at the router and add device settings only where they need them.

Where you set it	How it works	Covers	Watch out for
Router (DHCP settings)	The router hands out the protective resolver’s addresses to every device that joins	Every device that takes automatic network settings	Devices with manual DNS settings; the router itself must be kept secure
Router or local resolver forwarding	The router or a small local DNS forwarder sends all lookups upstream to the protective resolver	Everything that uses the router as its DNS server	Logs may show only the router, not each device
Each device	DNS, DoH or DoT settings on the laptop, phone or browser	That device, including when it leaves the office	More devices to set and keep set; staff can change it

Two practical points:

• Logging per device needs separation. If every device sends DNS through the router, the resolver sees one client: the router. To see which device asked for a blocked name, devices need their own DNS path, for example separate VLANs, per-device settings, or a per-device DoH address.
• Fail-open versus fail-closed. NIST SP 800-81r3 notes that a setup that fails open falls back to ordinary, unfiltered resolution when the protective service is unreachable. Ask your provider what happens, and decide which you prefer.

If you use a provider, NCSC’s guidance for private sector organisations gives a short set of criteria: a trusted provider with real DNS and security expertise, that actively blocks the threats protective DNS is meant to catch, and that keeps its deny lists current. Those criteria work outside the UK too. For the UK-specific picture, including who can use NCSC’s own service, see protective DNS for UK small businesses.

What should you ask before choosing a protective DNS service?

Whether you use a free public resolver, a configurable service or one built for you, the same questions apply. They turn the NCSC criteria and the NIST guidance above into things you can check.

Question	Why it matters
Where do the block lists come from, and how often are they updated?	A static list misses new threats. NCSC’s criteria call for deny lists that are kept current.
What does a blocked lookup return: NXDOMAIN, a block page, or an Extended DNS Error?	It decides what staff see, and how you test and troubleshoot a block.
Can you see which client asked for a blocked name, and export the logs?	Blocks are a clue that a device may be infected. NIST recommends feeding those logs into your wider security monitoring.
Does it check all record types, not only A and AAAA?	NIST SP 800-81r3 says a protective DNS service should be able to analyse all record types, such as MX and TXT.
What happens if the service is unreachable?	A fail-open setup quietly falls back to unfiltered DNS; a fail-closed one stops all lookups.
Does it support DNS over HTTPS or DNS over TLS?	Encrypted DNS keeps lookups private between your devices and the resolver.
Can you allow a domain it blocked by mistake?	False positives happen. You need a fast, simple way to unblock a legitimate site.
What does it log, for how long, and where?	DNS logs show which sites people visit. Check the privacy terms against your own obligations.

What mistakes stop protective DNS from working?

Most problems come from a lookup taking a path you did not plan for:

• A second DNS server that is not filtered. If the router hands out the protective resolver plus an ordinary public resolver as a backup, devices may use the backup and skip the filter. List only protective resolvers.
• The router’s own settings drift back. A firmware update, a factory reset, or a new router from your internet provider can restore the default DNS servers. Re-check after any change.
• Guest Wi-Fi and secondary networks. A separate guest network or a second router often has its own DNS settings. Set or check each one.
• Browsers and VPNs. Encrypted DNS in a browser, or a VPN client, sends lookups to its own resolver. Check them on staff laptops, as described above.
• No one reads the blocks. A blocked lookup from the same device every few minutes can mean malware is trying to call home. Someone should look at the logs, even once a week.

How do you test that protective DNS is working?

Test on each kind of device and each network you care about: office wired, office Wi-Fi, and any VPN.

1. Find the resolver that answers. Run nslookup example.com and read the Server: line, or dig example.com and read the SERVER: line. It should be the protective resolver, or your router if the router forwards to it. AdminKit’s DNS resolver test walks through this check.
2. Look up a blocked test domain. Many providers document a test domain that is always blocked; check your provider’s setup page. Look it up and expect NXDOMAIN, a block-page address, or no answer. Use only the provider’s documented test domain; do not visit real malicious sites to test.
3. Read the reason code if there is one. Some resolvers attach an Extended DNS Error to a blocked answer. RFC 8914 defines codes such as 15 (Blocked), 16 (Censored), 17 (Filtered) and 18 (Prohibited). dig shows it as an EDE: line.
4. Compare with an outside view. Look the same name up in AdminKit’s DNS lookup, which queries a public resolver, not yours. If it resolves there but not on your network, your resolver is doing the blocking.
5. Check normal names still work. Open a few sites staff use every day. A protective resolver that blocks legitimate names gets switched off quickly.

Example dig output for a blocked name (illustrative, documentation addresses):

$ dig blocked-test.example

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4242
;; OPT PSEUDOSECTION:
; EDE: 15 (Blocked)
...
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)

If the SERVER is not the resolver you expect, something else is answering. Is my router’s DNS hijacked? covers the case where the router setting itself has been changed.

How does protective DNS fit a small business network checklist?

Protective DNS is one item in a wider routine. AdminKit’s network hygiene checklist for small business starts from what the internet can reach on your network, and includes checking the router’s DNS setting. Protective DNS covers the other direction: what your devices try to reach.

Netbase also builds and runs AdminKit Protective DNS for shops, offices and small industrial sites as a scoped engagement; talk to our team if you want that. To see how it compares with self-serve services, read AdminKit vs NextDNS and Control D. This guide is part of AdminKit’s DNS cluster, which groups the DNS guides, glossary terms and tools in one place.

Open the AdminKit tools to check which resolver your devices use and what a domain resolves to: the DNS checks are free, read only public DNS and need no account.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.