Make bypassing inconvenient.

1. Open Parental Control and turn on Block Bypass Methods. This covers web proxies, VPN provider domains, Tor gateways, encrypted-DNS endpoints, browsers with a built-in VPN or proxy, and Apple's Private Relay hostnames.
2. In the same tab, turn on the Porn category and SafeSearch.
3. Open Security and turn on Block Newly Registered Domains. Relay and mirror sites cycle through fresh domains faster than any curated list can track them, so blocking domains under 30 days old catches what the proxy list misses.
4. Turn on Block Dynamic DNS Hostnames and Block Parked Domains in the same tab.
5. Turn on Block Top-Level Domains and select the high-abuse TLDs you have no reason to visit.

Newly-registered-domain blocking will occasionally catch a legitimate new service. That friction is the point, and the blocked lookup still appears in the log, so the trusted person can approve it deliberately rather than you routing around it.

1. Use the Family Filter (185.228.168.168 / 185.228.169.168). CleanBrowsing states it blocks proxy and VPN domains used to bypass filtering, in addition to adult content.
2. Do not use the Adult Filter (185.228.168.10) for this purpose. It is the lighter option and explicitly does not block proxies or VPNs.

This distinction is easy to miss because the Adult Filter sounds more targeted. For self-control setups the Family Filter is the stronger choice specifically because of the proxy blocking.

• Cloudflare Gateway has an Anonymizer security category ("sites that allow users to surf the Internet anonymously"), plus New Domains and Newly Seen Domains. The plain 1.1.1.3 resolver has none of this and no dashboard.
• AdGuard DNS has Block newly registered domains, and under Server settings a Block access to iCloud Private Relay toggle and a Firefox canary-domain toggle. A general proxy or anonymizer category could not be confirmed.
• Pi-hole and AdGuard Home depend entirely on the blocklists you add. If you run one of these, add a proxy and VPN blocklist deliberately; the default lists are advertising-focused and will not cover this.

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. Set up filtered DNS has the field-by-field walkthrough, including which generator options are self-defeating.
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 the equivalent pane is System Settings -> General -> Device Management. Older releases put it under Privacy & Security, and some providers' instructions still say System Preferences -> Profiles, which moved.
5. Block account and passcode changes in Screen Time. This adds friction elsewhere, but do not count on it to stop profile removal.
6. Use supervised device management or MDM if you need a profile the daily user cannot remove alone.

On an unsupervised iPhone or iPad, a profile you installed yourself can be deleted from that same pane, and can also simply be switched to Automatic without deleting anything. Screen Time prevents neither, and on iPhone the removal-password payload is supervised-only too. Supervision is the only thing that closes this, and Lock the DNS profile covers what that costs. Mac is a different story and needs no supervision — see Mac friction below.

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

The file already sits in a protected system folder, so on a default Windows install a standard user cannot edit it and an administrator can. That means the protection is already in place and there is only one question that matters.

1. Make the daily account a standard user and let the trusted person hold the administrator password. That is the control. Everything else on this page is detail.
2. Confirm it by signing into the daily account and trying to save a change to the file. It should refuse.
3. Check the permissions rather than assuming them, with icacls C:\Windows\System32\drivers\etc\hosts from any prompt.

This one matters more than anything else on this page, because it fails silently and completely.

Microsoft treats certain hosts-file edits as a threat. Its own description of the behaviour is that when it remediates, it will reset the hosts file to default, removing any existing entries. Not the offending line. All of them. Microsoft also states plainly that the hosts file "is not a supported method of managing network connections to Windows devices".

The trigger is blocking Microsoft's own domains, and the popular ready-made blocklists include them: the widely used unified list contains Microsoft telemetry endpoints along with dozens of entries for other Microsoft properties. So applying one of those lists unmodified is likely to get the whole thing wiped at some point, probably without you noticing.

1. Strip Microsoft-owned domains from the list before you apply it. The main list generator takes a whitelist file, and matching is partial, so a single microsoft.com entry removes that domain and everything under it. Do the same for the other Microsoft properties.
2. Prefer that over adding an antivirus exclusion for the hosts file. An exclusion works, but it removes protection from exactly the file that credential-stealing malware likes to modify, which is a poor trade for this purpose.
3. After any Windows repair, reset, or feature upgrade, check the file is still yours.

1. Use an actively maintained list. Check the last update date before trusting one; abandoned lists are common and useless here.
2. Pick the variant that matches what you are blocking rather than the largest available. Bigger is not better when every line is maintenance.
3. Apply the Microsoft-domain whitelist from the section above.
4. On Windows, use the list generator's compress option, which puts several domains on each line. Large uncompressed files are reported to slow name resolution.
5. Do not disable the DNS Client service to work around that, which is advice you will find in older guides. It breaks other things. Compression is the supported fix.
6. Schedule the update script rather than doing it by hand, and have it run under an account the daily user does not control.

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 on Windows, set the machine-wide registry keys under HKLM\SOFTWARE\Policies\Mozilla\Firefox. A policies.json file only applies to the one Firefox install it sits beside, so it is bypassed by downloading Firefox again. See Browser policy.
5. Also use URLBlocklist and URLAllowlist policies if you need browser-level allowlisting.
6. Close private browsing while you are here: Chrome IncognitoModeAvailability = 1, Edge InPrivateModeAvailability = 1, Firefox PrivateBrowsingModeAvailability = disallowed, plus BrowserGuestModeEnabled = false and BrowserAddPersonEnabled = false so a fresh profile is not a fresh start.
7. Restart the browser and check its policy page: edge://policy, chrome://policy, or about:policies.

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

1. Understand the edition situation, which changed and is widely misreported. AppLocker now enforces on every edition of Windows 11, including Home. That is a hazard rather than a reassurance: Home has no Local Security Policy editor, so a rule that locks you out of something is considerably harder to undo.
2. Only attempt this if you are comfortable recovering from a bad rule. Microsoft notes that the service AppLocker depends on cannot have its start type reversed with the usual command-line tool, and recommends taking a system backup before changing it.
3. Create rules in audit mode first.
4. Block portable browsers, unknown EXE paths, user-writable app folders, VPN clients, proxy tools, and installer folders.
5. Allow only required browsers and work apps.
6. Switch from audit to enforce only after reviewing logs.
7. 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. Lock the file with sudo chflags uchg /etc/hosts. Setting and clearing that flag both need sudo, so a standard user cannot touch it in either direction.
7. Use a standard account for daily work, with the trusted person holding the admin password.
8. Test from that standard account.

To edit it later, clear the flag first with sudo chflags nouchg /etc/hosts, make the change, then set it again. Note that System Integrity Protection does not protect this file, so the flag and the admin password are doing the work. A customised hosts file survives ordinary macOS updates, but check it again after a major version upgrade.

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.

A Mac is the easiest device to hold a DNS setting on, which is a pleasant change from everything else on this site. Two reasons: macOS shows a profile-installed DNS configuration as read-only text rather than a switch you can flip, and removing a profile or editing DNS servers both require the administrator password.

1. Use a configuration profile from your filtering provider rather than its Mac app. Generate it unsigned if you intend to add removal protection, because a signed profile cannot be edited.
2. Have the trusted person install it through System Settings -> General -> Device Management. It has to be done in the interface; the profiles command-line tool has not been able to install profiles since macOS 11.
3. Make the daily account Standard and confirm there is no second admin account with a password you know. On a Mac this is genuinely load-bearing rather than a formality.
4. Add a profile removal password so the profile cannot be removed even by someone who reaches the admin prompt. Unlike iPhone, this works on an ordinary Mac with no supervision and no MDM.
5. Close the browser gap with browser policy. A standard user can still let Chrome or Firefox resolve names itself and skip the system resolver entirely, and no profile prevents that.

Full detail, including the iPhone side and what to do if you will not supervise, is on Lock the DNS profile.

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

Verify the flag took with lsattr /etc/hosts, which should show i. Only root, or a process holding the matching capability, can set or clear it. The flag needs a filesystem that supports it, which covers the ext and btrfs families and XFS but not most network or overlay mounts. Clear it with sudo chattr -i /etc/hosts before editing, and before a distribution upgrade, since it will otherwise block the package manager from updating the file.

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. DNS-over-QUIC: UDP 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 and UDP port 853 unless you intentionally use DoT or DoQ 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 and DNS-over-QUIC on TCP and UDP port 853 unless they go 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 and DoQ on port 853, TCP and UDP, are blocked or forced to the chosen resolver.
• Mobile data and hotspots are handled separately.