Make bypassing inconvenient.

1. Open Settings -> Wi-Fi.
2. Tap the blue i next to the connected network.
3. Tap Configure DNS.
4. Choose Manual.
5. Remove existing servers you do not want used.
6. Tap Add Server.
7. Enter your chosen resolver, such as 208.67.222.123 and 208.67.220.123 for OpenDNS FamilyShield.
8. Tap Save.
9. Repeat on each Wi-Fi network you use often.
10. Test on Wi-Fi, then test on cellular data. Cellular data will not use the Wi-Fi DNS setting.

1. Choose a DNS provider that offers an iOS, iPadOS, or macOS profile.
2. Install the provider's DNS profile while the trusted person is present.
3. Check Settings -> General -> VPN & Device Management on iPhone or iPad.
4. On Mac, check System Settings -> Privacy & Security -> Profiles if your macOS version shows Profiles there.
5. Block account and passcode changes in Screen Time so profile removal is less casual.
6. Use supervised device management or MDM if you need a profile the daily user cannot remove alone.

For a normal personal device, profiles are friction. For stronger control, supervision or MDM is the more serious Apple path.

1. Open System Settings -> Network.
2. Select Wi-Fi or Ethernet.
3. Click Details.
4. Open DNS.
5. Add your chosen DNS servers.
6. Remove DNS servers you do not want used.
7. Click OK or Done.
8. Open Terminal and run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
9. Test Safari and every other installed browser.

1. Open Settings.
2. Open Network & internet. On Samsung, check Connections -> More connection settings.
3. Tap Private DNS.
4. Choose Private DNS provider hostname.
5. Enter a family-safe hostname, such as family-filter-dns.cleanbrowsing.org.
6. Tap Save.
7. Test on Wi-Fi.
8. Turn Wi-Fi off and test on mobile data.
9. Keep Family Link app-install approval turned on so another DNS or VPN app cannot be casually installed.

1. Uninstall extra browsers, VPNs, proxy apps, and alternate app stores.
2. Disable developer options if they are on.
3. Keep the parent Google Account off the managed phone.
4. Block new app installs through Family Link or the Play Store approval flow.
5. If the phone is rooted, treat local controls as weak. Move enforcement to the router, DNS account, and trusted person.

1. Finish the Chromebook steps in Guardrails.
2. Make sure Guest browsing is off.
3. Make sure sign-in is restricted to the approved accounts.
4. Use Family Link to set Chrome to Try to block explicit sites or Only allow approved sites.
5. Review extensions and remove anything that acts as a proxy, VPN, alternate browser, or remote desktop client.
6. Test by restarting the Chromebook and checking the login screen.

1. Use a managed ChromeOS environment when the personal owner model is not enough.
2. In the admin console, restrict guest mode and restrict which accounts can sign in.
3. Use URL blocklists or allowlists for Chrome.
4. Block unapproved extensions, VPN extensions, proxy extensions, and developer-mode workarounds.
5. Have the trusted person or organization own the admin account.

1. Sign in with an administrator account for setup.
2. Open Settings -> Network & Internet.
3. Open your active Wi-Fi or Ethernet connection.
4. Find DNS server assignment and click Edit.
5. Choose Manual.
6. Turn on IPv4.
7. Enter the preferred and alternate DNS servers.
8. Save.
9. Open Command Prompt and run ipconfig /flushdns.
10. Sign into the standard daily account and test.

1. Sign in as administrator.
2. Open Notepad as administrator.
3. Open C:\Windows\System32\drivers\etc\hosts. Change the file picker from text files to all files if you do not see it.
4. Add one blocked domain per line.
5. Save the file.
6. Run ipconfig /flushdns.
7. Test from the standard daily account.

0.0.0.0 example.com
0.0.0.0 www.example.com

Hosts-file blocking is brittle. It does not cover every subdomain, app, cached connection, VPN, or DNS-over-HTTPS path. Use it as a supplement.

1. Right-click C:\Windows\System32\drivers\etc\hosts.
2. Open Properties -> Security -> Advanced.
3. Confirm the daily account is a standard user.
4. Remove write access for the daily account and ordinary users.
5. Leave write access only for administrators.
6. Keep the administrator password with the trusted person if you are using lockout.
7. Sign into the daily account and confirm the file cannot be edited.

DNS filters can be bypassed when a browser uses its own DNS-over-HTTPS resolver. Managed browser policy is cleaner than telling the user to leave a setting alone.

1. Install Microsoft Edge and Google Chrome policy templates if you use Group Policy.
2. Set Edge policy DnsOverHttpsMode to off.
3. Set Chrome policy DnsOverHttpsMode to off.
4. For Firefox, deploy an enterprise policies.json file that disables and locks DNS-over-HTTPS.
5. Also use URLBlocklist and URLAllowlist policies if you need browser-level allowlisting.
6. Restart the browser and check its policy page: edge://policy, chrome://policy, or about:policies.

{
  "policies": {
    "DNSOverHTTPS": {
      "Enabled": false,
      "Locked": true
    }
  }
}

1. Use this only on supported Windows editions and only if you know how to recover from a bad rule.
2. Create rules in audit mode first.
3. Block portable browsers, unknown EXE paths, user-writable app folders, VPN clients, proxy tools, and installer folders.
4. Allow only required browsers and work apps.
5. Switch from audit to enforce only after reviewing logs.
6. Keep the policy-changing administrator account outside the daily user's control.

A bad application-control rule can lock you out of legitimate software. Test with a recovery admin account.

1. Sign into the admin account.
2. Open Terminal.
3. Run sudo nano /etc/hosts.
4. Add blocked domains mapped to 0.0.0.0.
5. Save, then run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
6. Use a standard account for daily work.
7. Test from that standard account.

0.0.0.0 example.com
0.0.0.0 www.example.com

1. Use Screen Time from Guardrails as the base layer.
2. Use a DNS configuration profile from your filtering provider for a stronger DNS layer.
3. Use MDM if you need to enforce profiles, browser settings, or app restrictions.
4. Deploy Chrome, Edge, or Firefox policy files to disable browser DoH and enforce blocklists.
5. Keep the MDM admin, local admin, or profile removal path with the trusted person.

1. Create a daily user that is not in sudo, wheel, or another admin group.
2. Keep the root or admin password with the trusted person.
3. Use the daily user for browsing and normal work.
4. Do not leave an unlocked admin shell, SSH key, password manager, or recovery note available to the daily user.

1. Open a terminal as an admin user.
2. Run nmcli connection show and note the active connection name.
3. Replace CONNECTION_NAME below with the exact connection name.
4. Bring the connection back up.
5. Test with the daily user.

sudo nmcli connection modify "CONNECTION_NAME" ipv4.dns "185.228.168.168 185.228.169.168" ipv4.ignore-auto-dns yes
sudo nmcli connection up "CONNECTION_NAME"

1. As admin, edit /etc/hosts.
2. Add blocked domains mapped to 0.0.0.0.
3. Set the owner to root:root.
4. Set permissions to 0644.
5. If the filesystem supports it, make the file immutable after you finish.
6. Do not give the daily user the root password or sudo access.

sudo nano /etc/hosts
sudo chown root:root /etc/hosts
sudo chmod 0644 /etc/hosts
sudo chattr +i /etc/hosts

Immutable files are a maintenance headache. Record the setup for the trusted person, not for the daily user.

Router enforcement is better, but a local firewall can add friction. Adapt this pattern carefully and test on a local machine, not over SSH.

# Example concept only: allow your chosen DNS, reject other DNS and DoT.
# Adapt for nftables, ufw, firewalld, or your router firewall.
# DNS: TCP/UDP 53. DNS-over-TLS: TCP 853.

1. Allow DNS to your chosen resolver.
2. Reject or drop outbound TCP and UDP port 53 to other addresses.
3. Reject outbound TCP port 853 unless you intentionally use DoT to your chosen resolver.
4. Address IPv6 too, or disable IPv6 only if you understand the side effects.
5. Test browser DNS, package manager DNS, VPN clients, and reboot behavior.

1. For Chrome, put managed policy JSON under /etc/opt/chrome/policies/managed/.
2. For Chromium, check /etc/chromium/policies/managed/.
3. For Firefox, use the distribution or enterprise policy path used by your distro.
4. Disable DNS-over-HTTPS and use URL blocklists or allowlists.
5. Open chrome://policy or about:policies to confirm the policy loaded.

{
  "DnsOverHttpsMode": "off",
  "URLBlocklist": ["*://*.example.com/*"]
}

1. Connect to the home network.
2. Open the router admin page. Common addresses are 192.168.0.1, 192.168.1.1, and 10.0.0.1.
3. Log in as router admin.
4. Find Internet, WAN, DHCP, LAN, or DNS settings.
5. Set primary and secondary DNS to the chosen family-safe resolver.
6. Set IPv6 DNS too if the router and ISP use IPv6.
7. Save and reboot if required.
8. Forget and rejoin Wi-Fi on a test device, or renew DHCP.
9. Test a blocked site.

1. Change the router admin password.
2. Give that password to the trusted person if this is self-lockout.
3. Block or redirect outbound DNS on TCP and UDP port 53 to anything except your chosen resolver.
4. Block outbound DNS-over-TLS on TCP port 853 unless it goes to your chosen resolver.
5. Apply the same rule to IPv6 or clients may bypass over IPv6.
6. Apply the rules to guest networks too.
7. Disable router features that let clients choose their own DNS if available.
8. Test from a normal client, a guest-network client, and a device with a hardcoded DNS server.

DNS-over-HTTPS uses normal HTTPS traffic on port 443, so router DNS rules alone do not reliably catch it. Use browser policy, managed devices, or a filtering service profile for that gap.

1. Choose where filtering will live: a local device like Pi-hole or AdGuard Home, or a cloud service like NextDNS.
2. Point router DHCP DNS to that filter.
3. Set upstream DNS on the filter to your chosen family-safe resolver or the provider's recommended upstream.
4. Use blocklists for categories you actually need. Too many lists create breakage and alert fatigue.
5. Use an allowlist for important sites that break.
6. Have the trusted person own the admin password or provider account.
7. Test logs only if you are comfortable with the privacy tradeoff.

• Router admin password is not known to the daily user.
• Primary and secondary DNS are both family-safe.
• IPv6 DNS is handled.
• Guest network is disabled or filtered.
• Outbound DNS to other resolvers is blocked or redirected.
• DoT on port 853 is blocked or forced to the chosen resolver.
• Mobile data and hotspots are handled separately.