Why GuardianBlock Doesn't Use DNS or VPN Filtering

GuardianBlock is not trying to be a network appliance

GuardianBlock deliberately avoids the DNS and VPN route. It is designed not to alter DNS, hosts, VPN, firewall, proxy, routes, adapters, SMB mappings, mapped drives, WSL mounts, or work-network configuration. That is not because DNS and VPN filtering are fake tools. It is because they solve a different problem.

A network filter tries to sit on the network path. GuardianBlock is built as adult accountability software for a personal Windows computer: supported browser policy, signed browser extensions, a local Windows service, protection health, and a trusted person in the loop. The broader category comparison lives in the existing DNS/VPN blocker explainer; this article is about why GuardianBlock made its own narrower choice.

“

Not broader than DNS. Better suited to a different constraint.

DNS and VPN are real network plumbing

A VPN is not just a privacy badge or a blocker toggle. Microsoft's Windows VPN documentation describes the routing decision directly: a profile can send all traffic through the VPN, or only selected traffic through the VPN, depending on force-tunnel or split-tunnel configuration. That choice affects how traffic leaves the machine.

Name resolution is its own layer. Microsoft's VPN name-resolution documentation describes NRPT rules, DNS suffixes, interface metrics, and timeout behavior. The IETF's split-DNS standard describes the common enterprise pattern: internal names can go to internal resolvers while other names use other resolvers. That is useful. It is also exactly why DNS is not a harmless little setting when a computer depends on work resources.

Encrypted DNS has the same double edge. DNS over HTTPS protects DNS traffic with HTTPS and TLS. Microsoft and NSA guidance describe the security and privacy benefit, but also the enterprise reality: DNS policy moves to the resolvers and configuration that are allowed to see and answer those encrypted queries. If your workplace has a designated resolver, split DNS, or monitoring requirement, a personal blocker should not casually replace that architecture.

The actual advantage is fewer collision points

This is the real case for GuardianBlock's design: if the thing you cannot risk touching is the network layer, then a product that stays away from that layer is a better fit for that constraint.

Maybe your personal laptop also connects to a corporate VPN. Maybe your work tools depend on internal names, mapped drives, SMB shares, proxy behavior, WSL, or a local development environment. Maybe you are not allowed to install anything that creates a VPN profile or changes DNS. For that person, the question is not which blocker sounds toughest. The question is which blocker changes surfaces the rest of your life already depends on.

GuardianBlock's answer is to leave that plumbing alone. The public no-DNS/VPN/firewall trust page is intentionally evidence-gated because the stronger lifecycle claim still needs clean Windows 11 Home and Pro evidence. But the product boundary is clear: the design is not to become your resolver, your VPN, your firewall, your proxy, or your route table.

What replaces the network layer

The replacement is not magic. It is a different stack. Browser vendors provide managed-browser controls for URL policy and extension deployment. Google describes Chrome URL blocklists and allowlists as basic URL management. Microsoft documents Edge URL policies and force-installed extensions. Mozilla documents Firefox enterprise policies such as WebsiteFilter and extension settings.

Those controls matter because GuardianBlock's early-access target is supported Windows browsers, not every packet on the machine. A local Windows service can run in the background, maintain local device state, and report health signals. Browser integrations can receive policy from that local service. Guardian accountability can make sensitive changes visible instead of pretending the protected adult is in a sealed technical box.

That is the product shape described on How GuardianBlock Works: a local Windows app, supported browser integrations, and an accountability partner who authorizes sensitive changes. It is a narrower architecture than DNS filtering, but narrower is the point when the network layer is the thing you are trying not to disturb.

The tradeoff we will not hide

Avoiding DNS and VPN filtering does not make blocking stronger by itself. It makes the enforcement surface different.

• A DNS or VPN filter may see broader network paths when that is the right tool and the right person controls it.
• GuardianBlock's early-access blocking scope is browser and device-posture based, not system-wide traffic filtering.
• Unsupported and portable browsers remain outside early-access blocking scope, with device-health and guardian visibility only where feasible and proven.
• A local Windows administrator can ultimately remove or work around installed software; GuardianBlock treats that as a health and accountability problem, not an impossible-lock problem.
• No software layer is treatment, crisis support, financial advice, or a recovery outcome.

Those limits are not fine print. They are the architecture. The Limitations page says the quiet part plainly because this category has too many impossible promises already.

Who this is for

GuardianBlock's design makes the most sense when the protected adult wants a voluntary accountability layer on a personal unmanaged Windows machine, and when the network layer is the wrong place to fight.

• If you need household-wide router filtering, GuardianBlock is not trying to be that appliance.
• If your device is employer-owned or managed, the right answer is permission, not a clever workaround.
• If your main constraint is that DNS, VPN, firewall, proxy, routes, mapped drives, SMB, WSL, or local development tools must be left alone, GuardianBlock's architecture is pointed at that constraint.
• If your risk is using unsupported browsers or retaining local administrator power, read the limits first and set up the accountability relationship honestly.

So yes: for people who cannot use DNS or VPN blockers because those layers collide with work or other legitimate tools, GuardianBlock's approach is a good idea. Not because it is broader. Because it is more honest about what it is trying to be: accountable Windows friction for the person who opted in, not ownership of the whole network.