BlockMyself
Filtered DNS

Set it up, properly, once.

This is the layer that does the most work on every platform, because it applies to every app rather than one browser, and it keeps a record. The rest of this site tells you to do it. This page is the actual steps, with the settings that matter called out, because several of the defaults are wrong for this purpose.

Every app Works on cellular Keeps a record

Decide who owns the account first

This is the most consequential choice on the page and it is not technical. Everything else can be redone in ten minutes; this one shapes what the setup is for.

The trusted person owns it

They create the account, they hold the password, and they show you the log or, if your provider offers a genuinely read-only role, add you as a viewer. Check what an invite actually grants before adding yourself: if it is edit access, you could weaken the filter, shorten how long records are kept, or delete them, and the arrangement is back to trust rather than design.

You own it

Friendlier, and strictly weaker. You can silently turn off logging, wipe the record, or delete the whole configuration at any point, and nothing tells anyone. This is a filter with a diary, not accountability.

Both are legitimate. Choose deliberately rather than by accident, and say out loud which one you are choosing and why. If you are setting this up alone tonight and will hand it over later, that is fine, but write down that you intend to, because it is the step people quietly skip.

Set up the account

Worked example uses NextDNS, because it is the one option confirmed to do the two things this needs: attribute activity to a device and keep a reviewable log with adjustable retention. Most steps translate to other providers.

  1. Create the account, ideally as the trusted person, and pick a strong password stored in their password manager rather than yours.
  2. Check logging is actually on. Do not assume. In the log settings, confirm both that logging is enabled and that domains are being recorded. There is a privacy option that keeps the log while stripping the domains, which leaves you with a record that something happened and no idea what.
  3. Set retention longer than your check-in interval. Weekly conversations need at least a month, or a missed week erases the evidence. Options run from an hour to two years.
  4. Choose the storage region once, at the start. Changing it later deletes all existing logs.
  5. Turn on the anti-circumvention settings described in Friction: block bypass methods, and block newly registered domains. Without those, a category filter stops the front door only.
  6. If a second person needs visibility, look under Settings -> Access. In every account of it we could find, the invite grants edit access, and we could not confirm that a read-only viewer role exists, so do not add yourself unless you have checked that the invite cannot change settings or logs. Have the trusted person show you the log instead.
The free tier fails silently, and this catches people.

Free accounts cap monthly lookups. Past the cap the service keeps resolving names but stops filtering and stops logging. NextDNS emails the account owner at 250,000 lookups and again at the cap, but nothing changes on the device, and if the trusted person owns the account the email lands with them, not you. One heavily used phone can reach that cap, and you would not notice: sites simply start working again. Agree that the warning email is an action item, or, if you are relying on this for anything that matters, pay the couple of dollars a month. It removes a failure that recurs on a schedule.

iPhone and iPad

Apple devices take a configuration profile. It applies to every app, and because you install it yourself rather than through a management server, it also covers cellular.

Generate the profile, and the settings that matter

Quickest route: use our profile builder, which sets these correctly for you and can also block a list of sites you type in. If you would rather use your provider's own generator, with NextDNS that is apple.nextdns.io. Two fields are shown; the rest are hidden behind More options, and that is where the important ones live.

SettingWhat to doWhy
Profile / configuration IDYour IDWhich configuration the device uses.
Device NameSet itThis is what makes the log readable later. It is baked into the profile, so changing it means reinstalling.
Device ModelOptionalCosmetic. Helpful when several devices share one account.
Excluded Wi-Fi NetworksLeave emptyThis turns filtering off on the networks you name. Putting your home network here is a self-service bypass, and it is the single most self-defeating option on the page.
Excluded DomainsLeave emptyOnly for a genuinely broken work intranet or a local printer.
Trust root certificateLeave offIt removes a certificate warning on blocked pages, at the cost of trusting a third party for all secure connections, and it needs a second manual step. A blunt error on a blocked site is a perfectly clear signal.
Bootstrap IPsOptionalHelps on networks that interfere with the provider. A reliability setting, not a security one.
Prohibit DisablementOnly if supervisedThis is the setting that stops the DNS being switched to Automatic. It requires a supervised device, and on an ordinary phone the profile will simply refuse to install. See Lock the DNS profile.
Sign the profileLeave onA signed profile cannot be edited, so it cannot be quietly altered to point at an unfiltered configuration. This is the most useful hardening available without supervision.
A tamper indicator worth knowing. Because signed profiles cannot be edited, anyone wanting to swap in their own configuration has to install an unsigned one, and iOS marks those Not Signed in red on the install screen. If you ever see that on a device you set up, it was replaced.
Install it
  1. Download the profile in Safari. Other browsers on iPhone do not hand off to Settings reliably. Approve the download when asked.
  2. Open Settings. A Profile Downloaded row appears near the top, above your name.
  3. Tap it, then Install, and enter the device passcode. You will tap Install more than once.
  4. If the row has disappeared, the pending profile is under General -> VPN, DNS & Device Management. Downloaded profiles expire after several minutes, so download it again if needed.

The profile will also contain a short list of exclusions you did not add, covering captive-portal detection and carrier voicemail. Those are there so hotel Wi-Fi sign-in pages and visual voicemail keep working. They are expected, not tampering.

Mac

  1. Generate the same profile, with the same settings as above.
  2. Double-click the downloaded file.
  3. Open System Settings -> General -> Device Management, select the profile, and click Install. You will need an administrator password.
  4. Have the trusted person do that step, and install it for the whole machine rather than one user.
Providers' own Mac instructions are frequently out of date and still say to look in System Preferences under Profiles. That pane moved. On macOS 15 and later it is System Settings -> General -> Device Management; on macOS 13 and 14 it is Privacy & Security -> Profiles.

On a Mac the profile is not the lock; the administrator password is. Read the Mac section of Lock the DNS profile before you assume this holds, because an administrator can change DNS servers directly.

Android

There is no profile to install. Android has this built in, and the built-in version is good: it is encrypted, it covers every app, and it works on mobile data as well as Wi-Fi.

  1. Open Settings -> Network & internet -> Private DNS. On Samsung it is under Connections -> More connection settings.
  2. Choose Private DNS provider hostname.
  3. Enter the hostname from your provider's setup page. With NextDNS it is your configuration ID followed by .dns.nextdns.io.
  4. To make the logs readable, prefix a device name: Sams-Phone-abc123.dns.nextdns.io. Letters, numbers and hyphens only, and a space becomes two hyphens.
  5. Save, then confirm it took using the check below.
Be clear-eyed about what this is on Android.

Private DNS is an ordinary setting with no lock. It can be switched off in seconds, there is no signature to check and no warning to notice. Unless the phone is under device-owner management, which is covered on Lock the DNS profile, this is an audit trail rather than a barrier: turning it off is easy, but doing so stops the log, and the gap is visible to whoever reviews it. Agree in advance that a gap is an event, or this layer does nothing at all.

Windows

Two workable options. The important difference is whether it covers the whole machine or one network adapter.

Provider's command-line client, as a service

The better option. It installs as a Windows service, starts automatically, covers every network interface, and is configured to restart itself if the process is killed. Installing or stopping a service needs administrator rights, so a standard user cannot remove it.

Check the desktop app is actually maintained before choosing it instead; at least one major provider's Windows app has not shipped an update in over two years while its command-line tool is updated constantly.

Built-in encrypted DNS

No third-party software. You set the DNS servers for the adapter and give Windows the matching encrypted-DNS address, then optionally require encryption so it fails closed. Changing this needs administrator rights.

The catch is that DNS servers are set per adapter, so a new Wi-Fi dongle, a tethered phone or a VPN adapter falls back to whatever DNS it is handed, unless you also set the machine-wide Group Policy Configure DNS over HTTPS to Require DoH, in which case any adapter pointing at a non-encrypted server simply fails to resolve. Register the provider's encrypted address first with Add-DnsClientDohServerAddress; NextDNS is not on Windows' built-in list, so the encryption option does not appear until you do.

Whichever you choose, the same rule applies as everywhere else on Windows: if your daily account is an administrator, you can undo it. Make yourself a standard user and let the trusted person hold the password, or this is a preference rather than a control. See Lock the DNS profile.

Linux and routers

Linux

Providers with a command-line client install it as a system service that starts at boot. Set it to report device information so the logs are attributable, and to re-apply the system resolver configuration at startup.

If your client offers captive-portal detection, leave it off. Its own documentation warns that the feature can be used to force the client to fall back to unencrypted DNS, which is a documented way around the filter.
Router, and the trap in it

A router covers guests, televisions and anything you cannot configure individually. It does nothing for a phone on mobile data, so treat it as a supplement rather than the main control.

If your router cannot do encrypted DNS, you will be asked to link your home IP address instead, because with plain DNS there is nowhere to put your account identifier and the provider recognises you by address alone.

That link breaks when your home IP changes, and it fails open.

When it breaks, your whole house silently drops to unfiltered and unlogged resolution. Nothing announces it. If you use this, set up the automatic update option your provider offers so the link follows your address, and check it occasionally regardless. For accountability this is the worst failure shape there is: everything appears fine and the record simply stops.

Confirm it is actually working

Two checks, in this order. Do both, on the device itself, not on another one.

  1. Open your provider's test page. With NextDNS, test.nextdns.io. It should report that the device is using the service with your configuration.
  2. Watch yourself appear in the log. Load any ordinary site, then look at the logs and confirm the device shows up under the name you gave it, within seconds.
The second check is the one that catches the clever failure. A test page can report that you are using the service while you are on a different configuration than the one being reviewed, which is what happens if someone sets up a second, unfiltered account. Seeing the right device name in the right log is the only check that confirms the whole chain: filtering, the right configuration, and attribution.
On Apple devices, turn off iCloud Private Relay or test carefully with it on. It routes DNS around a filter set on the router or typed in as a plain server, so filtering and logging stop while everything looks fine. Apple states that an encrypted-DNS profile installed on the device is used instead, so a NextDNS profile should survive it, but the log is the only proof. See Mobile data and hotspots.

What this holds against, and what it does not

Worth reading once so you know what you have built.

If you do this and nothing else, you have a real layer plus a record. That is a much better position than most people who have spent a weekend on this, and it took about twenty minutes.

Where to go next