Why GuardianBlock Doesn't Use DNS or VPN Filtering

The answer: GuardianBlock leaves the network stack alone

GuardianBlock does not alter DNS, hosts, VPN, firewall, proxy, routes, adapters, SMB mappings, mapped drives, WSL mounts, or work-network configuration. That is a design boundary, not a compatibility promise for every computer.

That distinction is the point. This is an architecture boundary, not proof that every installation, update, rollback, repair, or uninstall scenario behaves the same on every computer. GuardianBlock's design puts accountability on required-browser policy, signed browser extensions, local device posture, and a Windows service. It does not claim universal traffic filtering. The broader category comparison lives in the DNS/VPN blocker explainer.

“

A smaller enforcement surface can be the honest choice when the network path is outside the job.

DNS and VPN controls sit on the network path

A Windows VPN profile makes routing decisions. Microsoft documents split-tunnel profiles that direct selected routes through the VPN and force-tunnel profiles that change default routes. Microsoft also documents VPN name resolution through the Name Resolution Policy Table, DNS suffixes, interface metrics, and resolver rules. These are useful capabilities, but they belong to the computer's connectivity architecture.

Encrypted DNS shows why the layer needs care. DNS over HTTPS protects DNS transport with HTTPS and TLS. Microsoft's Windows guidance describes its confidentiality and integrity benefits, while the IETF's split-DNS standard describes sending designated names to designated resolvers. A computer using corporate name resolution or a VPN may depend on those choices.

A blocker that creates a VPN profile or takes over DNS therefore participates in routing or name resolution. That can be appropriate for a household filter or a person who wants network-level control. GuardianBlock chose a different mechanism because its product job is voluntary accountability on an enrolled Windows device, not administration of the person's network.

The mechanism also changes the failure model a product must disclose. A problem at the network layer can affect connectivity or name resolution. A gap in GuardianBlock's model is more likely to be a browser outside the managed surface, missing browser policy, stale local state, or a stopped component. The design aims to turn those conditions into honest device posture and accountability signals where evidence permits. It does not erase them.

The narrower job is browser and device-posture accountability

GuardianBlock's design combines required-browser policy, signed extensions, a local Windows service, device-health evidence, and chosen-person approval for sensitive changes. In that design, the browser integration is meant to apply policy on the browser surface, the service is meant to maintain local state and report evidence-qualified health signals, and the accountability relationship is meant to provide decision authority and a response when protection weakens or the device goes quiet.

Those ingredients have different jobs. Machine-level browser policy is the managed installation and configuration surface. A signed extension is designed to apply policy within its browser. The local service is designed to connect signed state, browser integration, and health reporting. Device posture describes whether the evidenced pieces are present and current. In that model, the chosen person uses their own authenticated account and MFA to decide a specific eligible weakening request. They do not hold a reusable password or unlock secret, and GuardianBlock approval does not replace Windows administrator elevation. None of those roles converts the product into a resolver, VPN provider, firewall, proxy, or packet-inspection system.

Browser vendors expose real management controls for that design. Google documents Chrome URL blocklists as basic URL management. Microsoft documents Edge URL policies and force-installed extensions, including browser-specific limitations. Mozilla's current Firefox policy templates document WebsiteFilter and ExtensionSettings, including forced installation and private-browsing configuration. These are managed-browser mechanisms, not control of traffic outside those browser surfaces.

A Windows service is an ordinary operating-system mechanism for background work. In GuardianBlock's design, the local service is designed to connect browser policy, signed local state, and health reporting. The public How GuardianBlock Works page explains how that local device layer fits with chosen-person approval.

What this boundary does not prove

The public no-DNS/VPN/firewall trust page records the design boundary. It describes what GuardianBlock is designed to do, and it should not be read as a compatibility promise for a particular VPN, employer configuration, security product, or local development setup.

• GuardianBlock's design is browser and device-posture based, not universal traffic filtering.
• Chrome, Edge, and Firefox are the supported browsers, and coverage is described browser by browser rather than assumed to be the same everywhere.
• Unsupported and portable browsers remain outside GuardianBlock's blocking scope; visibility and accountability apply where evidence permits.
• GuardianBlock is not treatment, crisis support, financial advice, or a promised recovery outcome.

Those limits are part of the mechanism choice. The Limitations page is the better starting point for browser scope, local-administrator authority, managed-device exclusions, and the non-treatment boundary.

Choose based on the constraint, not the slogan

If you want household-wide router control or network-level filtering, GuardianBlock is not designed to replace that tool. Employer-owned, domain-joined, MDM-managed, shared, or workplace-policy-governed computers are out of scope. GuardianBlock supports personal, unmanaged Windows 11 Home or Pro x64 devices, and installer preflight checks that a device qualifies.

If your concern is voluntary Windows accountability while keeping DNS, VPN, firewall, proxy, routes, adapters, SMB mappings, mapped drives, WSL mounts, and work-network configuration outside the enforcement mechanism, GuardianBlock is designed around that boundary. Evaluate it as narrower browser/device-posture accountability with a chosen person in the loop — not as a filter for the whole network, and not as a compatibility guarantee for every network setup. Judge that boundary by direct evidence, not by architecture shorthand.