There is a particularly frustrating version of this job: you add a website to the router’s block list, feel relieved for ten minutes, and then someone opens the same site on a phone as if nothing changed. You did not necessarily configure it badly. The router may simply be controlling a smaller part of the journey than its interface suggests.

The useful question is not “Where is the blacklist box?” It is “Which network decision can this router actually enforce?” For most homes that means choosing among a vendor parental-control feature, DNS filtering, or a dedicated DNS sinkhole. Each has a boundary, and knowing the boundary saves an evening of guessing.

First, decide what “blocked” must mean in your home

  • Every device or selected devices: a guest network, work laptop, television, and child’s tablet may need different policies. Prefer a control that can bind rules to a device or profile when exceptions matter.

  • A whole domain or one page: DNS can refuse example.com; it cannot distinguish example.com/games from example.com/home because the path is not part of a DNS lookup.

  • A schedule or a permanent rule: bedtime controls need a reliable clock, time zone, and profile schedule. A plain DNS denylist is usually always on unless another scheduler controls it.

  • Managed or unmanaged devices: a device you administer can be given browser and operating-system policies. A guest device may ignore the router’s DNS and requires network enforcement if the rule must hold.

  • Ordinary deterrence or strong policy: DNS filtering is excellent for reducing distraction, ads, malware domains, and accidental visits. It is not an access-control system against a determined administrator with a VPN or cellular connection.

Three workable paths, from least to most controllable

Use the router’s profiles when they are genuinely domain-aware

Look for parental controls, access control, content filtering, security, or family profiles in the router’s own manual. Model names and firmware revisions matter, so a menu path copied from another brand is more likely to waste your time than help. Confirm whether its rule blocks domain names, broad categories, IP addresses, or only unencrypted URL text.

  1. Update to a vendor-supported firmware release and save or export the current configuration before changing policy.

  2. Give the target device a stable identity using a DHCP reservation where the router supports one. Be aware that modern devices can use randomized Wi-Fi MAC addresses per network.

  3. Create one small test profile, assign one device, and deny a harmless test domain before importing a large list.

  4. Apply or save the policy, renew the device’s connection if required, and clear only its DNS cache or restart its browser.

  5. Test both the root domain and any service hostnames the application actually uses. One visible brand can depend on several domains.

  6. Record the rule, device/profile, date, and rollback location. Then observe whether unrelated sign-in, media, update, or school services break.

Point the home network at a filtering DNS resolver

If the router lets you choose DNS servers for DHCP clients, a filtering resolver can apply a shared denylist without installing software on every device. This is often the most comfortable home setup. It remains a DNS policy: it blocks names, not individual URLs, and clients can bypass it if the network allows alternate encrypted DNS.

  1. Choose a reputable filtering DNS service whose retention, logging, security, availability, and account-recovery policies suit your household.

  2. Write down the current IPv4 and IPv6 DNS addresses before replacing them. If the router has separate WAN and LAN/DHCP DNS fields, follow its manual rather than assuming they are equivalent.

  3. Configure both address families that your network advertises. A client can appear to “escape” when IPv4 is filtered but IPv6 DNS remains unrestricted.

  4. Renew one test client’s DHCP lease or reconnect it, then verify which resolver it actually received before testing a blocked name.

  5. Add domains gradually. Keep an allowlist for false positives and document why each exception exists.

Run Pi-hole when you want a filter you can inspect locally

Pi-hole describes itself as a DNS sinkhole and supports IPv4 and IPv6. It can also provide DHCP when a router will not advertise the desired local resolver. The host needs a stable address—normally a DHCP reservation or deliberate static configuration—because every client must be able to find it consistently.

  1. Prepare a supported always-on host and reserve its LAN address. Decide how DNS will work if that host is offline.

  2. Install from the current official Pi-hole documentation, not an old copied command or unofficial image.

  3. Set the router’s LAN/DHCP DNS option to the Pi-hole address, or use Pi-hole DHCP only after disabling the router’s competing DHCP server.

  4. Cover IPv6 intentionally: advertise the correct local IPv6 resolver or disable IPv6 only if you understand the wider consequences. Do not leave a silent unfiltered resolver path.

  5. Start with a modest list, inspect query and blocking evidence, and allowlist necessary domains instead of disabling the filter whenever one application fails.

  6. Protect the administration interface and query data. DNS history can reveal sensitive household habits even when it cannot reveal an HTTPS page path.

Prove the DNS path before judging the block

Use a domain you intentionally denied and replace the example resolver address below with the LAN address of your router, filter, or Pi-hole. Different filters answer with NXDOMAIN, 0.0.0.0, ::, a local block address, or another documented response, so compare the result with your chosen product’s behavior rather than one universal expected value.

Terminalbash
dig @192.168.1.2 blocked.example A
dig @192.168.1.2 blocked.example AAAA
;; status: NXDOMAIN
;; status: NXDOMAIN

What this controlled query tells you

  • @192.168.1.2 selects one resolver explicitly; replace it with the address you administer rather than copying it literally.

  • A asks for an IPv4 address and AAAA asks for an IPv6 address. Testing both exposes split policy between address families.

  • NXDOMAIN means that resolver reported the name does not exist. Some products intentionally return a sinkhole address instead, which can still represent a successful block.

  • A successful direct query proves the selected resolver’s policy, not that the browser is using that resolver.

  • The example is documentation-reviewed and was not run against the reader’s private network or a real blocked domain.

Terminalbash
dig blocked.example A
dig blocked.example AAAA

The comparison that catches most surprises

  • Without @server, dig follows the operating system’s current resolver configuration. The SERVER line shows where this particular query went.

  • If the direct query is blocked but the default query is not, investigate DHCP, a manually configured resolver, VPN DNS, browser DNS-over-HTTPS, and IPv6 before editing the denylist again.

  • An operating system can use a local stub resolver, so the displayed loopback address may be an intermediary rather than the final upstream service.

  • Cached positive or negative answers can survive a policy change. Reconnect or use the operating system’s documented cache refresh, then retest without indiscriminately resetting network settings.

  • These commands inspect name resolution only. Always test the real application afterward, because apps may cache addresses or use additional hostnames.

Why one device still gets through

  • DNS over HTTPS or DNS over TLS: the browser or operating system sends DNS to another resolver inside encrypted traffic. Firefox documents network signaling and enterprise policy options; use supported controls on devices you manage.

  • A VPN, proxy, or anonymity service: the tunnel can carry both DNS and web traffic beyond the home policy. Router DNS alone does not control the tunnel’s destination traffic.

  • Cellular data or another Wi-Fi network: traffic that never crosses your router cannot be blocked by your router.

  • IPv6 was forgotten: the device may learn an unrestricted IPv6 resolver or connect using an already resolved IPv6 address.

  • Application-specific resolution: some applications use their own resolver, hard-coded endpoints, cached IP addresses, or multiple content domains.

  • Changing device identity: private/randomized MAC addressing may cause a router profile to see the same physical device as a new client.

  • Existing connections and caches: a live encrypted connection or cached DNS answer may continue after the rule is added. Retest with a fresh connection after the relevant cache lifetime.

Make bypass resistance proportional to the need

For ordinary household guardrails, a clear agreement plus filtering DNS is often enough. If the requirement is stronger, use supported router firewall controls to permit DNS only to approved resolvers, manage encrypted-DNS settings on devices you own, restrict VPN installation, and separate guest or child devices into an appropriate network. Test carefully: aggressive port or address blocking can damage legitimate privacy features and still miss services using shared infrastructure.

A rollback you can do while everyone is waiting

  1. Restore the previously recorded DNS servers or disable only the new profile/rule.

  2. Renew the test client’s network configuration and confirm its resolver changed.

  3. Remove a firewall restriction only if it was part of this change; do not factory-reset the router as a first response.

  4. Verify a known-good domain, a previously blocked domain, IPv4 and IPv6, and at least one important household application.

  5. If one legitimate domain caused the incident, restore the filter and add the narrowest documented allowlist entry.

  6. Keep the configuration backup and incident notes somewhere available even when the local DNS server is down.

Useful Lynxbee follow-ups

Primary references