Router DNS Filtering: What It Stops and What It Misses

A post has been making the rounds on LinkedIn recommending that people change their home router DNS to Cloudflare’s 1.1.1.2 and 1.0.0.2 addresses. The author was careful about it, and to his credit he pushed back on the framing himself: this is not free antivirus. He is right on both counts. The advice is sound, and the label people keep attaching to it is wrong.

We sell routers for a living, so this comes up constantly. A customer sets a filtering resolver on a Peplink or a Cradlepoint, tests it against one blocked domain, sees the block page, and concludes the network is protected. Two weeks later a laptop on that network is beaconing to a command and control server, and nobody understands how it got past the filter. The gap between what DNS filtering does and what people think it does is worth closing.

What Actually Happens When You Change Those Two Numbers

Before your browser can connect to anything, it has to turn a name into an address. That lookup goes to a resolver. Change the resolver, and you change who gets to answer that question.

Cloudflare’s filtering resolvers work by refusing to answer honestly. Per Cloudflare’s own documentation, when a queried domain is classified as malicious, Cloudflare returns the address 0.0.0.0 instead of the real address, which prevents your device from connecting to the blocked site. There is no scanning, no signature matching, no inspection of anything. The resolver checks a name against a reputation list and either answers or does not.

There are two tiers. The malware blocking option uses 1.1.1.2 and 1.0.0.2, plus 2606:4700:4700::1112 and 2606:4700:4700::1002 for IPv6. The malware plus adult content option uses 1.1.1.3 and 1.0.0.3, plus 2606:4700:4700::1113 and 2606:4700:4700::1003. Encrypted versions exist too. The DNS over HTTPS endpoint for malware blocking is https://security.cloudflare-dns.com/dns-query, and the DNS over TLS hostname is security.cloudflare-dns.com.

That is the entire mechanism. It is a name filter, and it is exactly one domain wide.

The Numbers Behind the Advice

The case for doing this at all rests on how much of the current threat picture arrives as a link rather than a file.

The Anti-Phishing Working Group recorded 971,181 phishing attacks in the first quarter of 2026, up 13.8 percent from 853,244 in the last quarter of 2025. Across all of 2025 the group observed roughly 3.8 million phishing attacks, slightly above the 3.76 million counted in 2024. That works out to somewhere north of ten thousand observed attacks per day, and those are unique phishing sites, not individual emails.

The sector detail should interest anyone in this industry. APWG contributing member Crane Authentication found that attacks against telecom brands climbed from 5.9 percent of all attacks in the third quarter of 2025 to 33 percent in the first quarter of 2026, making telecom the most attacked category, with URL phishing frequency against the sector up 75 percent since the fourth quarter of 2025. Fake carrier billing pages and spoofed account portals are now a primary lure. Those are domains, and domains are what a resolver can see.

The counterweight is how fast attackers manufacture new ones. Interisle Consulting Group’s analysis found that malicious actors purchased at least 10 percent of all new gTLD domains registered in 2025, with projections suggesting the real share may be closer to 20 percent, drawn from a dataset of more than 26 million unique cybercrime events representing 60 percent annual growth in attacks. A reputation list is always working from behind. A domain registered this morning and burned this afternoon may never get classified at all.

So the honest summary is that DNS filtering catches a large volume of known bad, and structurally cannot catch the freshest bad. Both halves of that sentence matter.

Why the Router Is the Right Place for This

Everything above applies whether you set the resolver on one laptop or on the gateway. Setting it on the gateway is better for reasons that have nothing to do with the filter itself.

Most networks now carry a majority of devices that cannot run endpoint software. Cameras, thermostats, TVs, streaming boxes, digital signage, point of sale terminals, industrial sensors. None of them will ever run an agent. The router is the only control point that touches all of them.

On a cellular router this matters more, not less. A cellular WAN receives its DNS servers from the carrier, so whatever you configure on the LAN side is what determines what your clients actually use. This also works fine behind CGNAT, which trips people up. DNS is an outbound query. It has nothing to do with whether your WAN address is publicly reachable.

Four Ways It Gets Bypassed

This is the part that gets skipped, and it is the reason nobody should call this antivirus.

Direct connections to IP addresses. Malware that already knows where it is going does not ask. If the payload has a hardcoded address, or pulls one from a config file, no lookup ever happens and the resolver never sees it.

Encrypted DNS inside applications. This is the big one. Mozilla states plainly that when DNS over HTTPS is enabled it bypasses the local DNS resolver and defeats policies that organizations rely on to block malware or enable parental controls. Firefox offers a signaling mechanism for this, the canary domain use-application-dns.net, but Mozilla is clear about the limits: the canary domain only applies to users who have DoH enabled as the default option, and does not apply to users who turned it on themselves. Chrome takes a different approach and upgrades to encrypted DNS when your existing resolver supports it, which in Cloudflare’s case preserves the filtering. Firefox’s default does not necessarily do that.

VPN clients. Any VPN that carries DNS inside the tunnel takes the whole question out of the router’s hands.

Already compromised devices. A machine that is infected stays infected. Blocking the domain it wants to reach does not remove anything, and a resolver change is not remediation.

There is a fifth, quieter one. Local caches and hosts files answer before any query leaves the machine. Old cached entries can survive a resolver change for a while, which is why a test appears to fail and then starts working after a flush.

Making It Stick on a Business Class Router

Handing out a filtering resolver over DHCP is a suggestion, not a policy. Any device configured with its own DNS servers, and plenty ship that way, will ignore it. Peplink users have been dealing with this for years, most memorably in a well documented community thread about a Roku box that quietly kept talking to Google’s resolvers at 8.8.8.8 despite DNS interception being enabled on the router.

Enforcement takes three moves, and the specifics vary by platform:

1. Intercept port 53. On Peplink this is the DNS proxy and DNS forwarding setting, which redirects lookups to the built in name server regardless of what the client is configured with. Cradlepoint, Teltonika, and Digi platforms all offer equivalent forwarding or redirect behavior. The pfSense documentation describes the same technique as a port forward that makes access to other DNS servers on port 53 impossible.
2. Block the escape routes. Add outbound firewall rules denying traffic to external resolvers on UDP and TCP 53, and on TCP 853 for DNS over TLS. Port 443 DoH cannot be blocked by port, so this is where the canary domain and browser policy come in.
3. Cover IPv6. This is the most common oversight we see. If the router hands out IPv4 filtering resolvers and carrier assigned IPv6 resolvers, dual stack clients will frequently prefer the IPv6 path and your filter simply does not apply. Set both, or turn IPv6 off on the LAN.

Whether you are running a Peplink Balance or MAX, a Cradlepoint endpoint, a Teltonika RUT series unit, a Digi IX or EX gateway, an Inseego modem, a Semtech AirLink router, or a Katalyst Hawk, the concepts are the same even though the menus are not. If you are unsure where the setting lives on your specific model, ask us.

Verify when you are done. Cloudflare publishes two test addresses for exactly this purpose: malware.testcategory.com tests whether known malware domains are blocked, and nudity.testcategory.com tests the adult content and malware tier. Test from a client, not from the router shell, and test from each VLAN.

The Honest Counterpoint

There are real arguments against doing this, and they deserve airing rather than burying.

Miscategorization is not hypothetical. When Cloudflare launched the family tier in 2020, the initial adult content filter blocked LGBTQ resources and sex education sites. Cloudflare’s CEO called it a mistake at the time and attributed it to third party categorization data that had not been fully reviewed. The company now runs an anonymous feedback process for domains that are incorrectly blocked or allowed, but the underlying point stands: you are outsourcing a blocking decision to a categorization vendor you do not control and cannot audit. For the malware only tier at 1.1.1.2 this risk is much smaller than for the content tier at 1.1.1.3.

You get no visibility. The free tier has no dashboard, no logs, and no per client policy. You cannot tell whether it blocked four things last month or four hundred, and you cannot tell which device tried. For a home network that is an acceptable trade. For a business it is a real limitation, and it is the reason paid services like NextDNS, ControlD, or Cloudflare’s own Zero Trust Gateway exist.

It is a dependency. You are making one external service a hard requirement for your network to function. Configure both the primary and secondary addresses, and know how to change it back.

The false confidence problem is the biggest one. A layer that visibly works on the one thing you tested creates a feeling of coverage that outruns the actual coverage. If setting this up makes someone skip patching, skip multi factor authentication, or skip endpoint protection, the filter has done net harm.

And filtering effectiveness varies by provider. Independent comparisons have repeatedly found different block rates across public resolvers, with Quad9 at 9.9.9.9 and 149.112.112.112 frequently scoring well against malware lists. If this layer matters to you, it is worth testing more than one.

None of that makes the advice wrong. It makes it a layer.

Frequently Asked Questions

Will this slow my connection down?
Not meaningfully. The filtering addresses run on the same Cloudflare infrastructure as the standard 1.1.1.1 resolver. In most cases a public resolver is faster than the one your carrier assigned.

Does it work behind CGNAT on a cellular connection?
Yes. DNS lookups are outbound requests. Carrier grade NAT affects inbound reachability and has no bearing on this.

Will it break anything on my network?
Occasionally. Internal hostnames that resolve through a local server need that server left in the path, and a small number of legitimate sites get miscategorized. Know how to revert before you deploy it across a site.

Is it actually free?
Yes, with no account and no device install. Cloudflare has offered it at no charge since 2020.

Do I need the adult content tier?
Only if you want content filtering. If your goal is security, 1.1.1.2 is the tier you want, and it carries far less miscategorization risk.

How do I confirm it is working?
Browse to malware.testcategory.com from a client device. If it loads normally, your filtering is not being applied to that device, and the usual culprits are IPv6, a hardcoded resolver, or browser level encrypted DNS.

5Gstore Take

Set it up. It costs nothing, takes about five minutes, and removes a category of risk from every device on the network including the ones that will never run security software. On a fleet of remote cellular sites, pushed centrally, it is one of the better returns on effort available in networking right now.

Just be precise about what you have built. You have added a filter at the front door that checks names against a list. You have not added antivirus, you have not added endpoint protection, and you have not added anything that helps a machine that is already compromised. Call it what it is, layer other controls behind it, and it earns its place.

If you want help enforcing DNS policy across a Peplink, Cradlepoint, Teltonika, Digi, or Semtech deployment rather than just suggesting it over DHCP, our team does this every week. Get in touch with us and we will walk through the configuration for your specific hardware.

External references: Cloudflare 1.1.1.1 setup documentation and the APWG Phishing Activity Trends Reports