Should private DNS mode be on or off?

Private DNS mode: on, with one exception

Turn private DNS mode on, and point it at a resolver hostname you picked yourself. Set it back to Automatic or Off only when the network you are joining has to answer your DNS queries itself: captive portal wifi before you log in, a company or home network that holds internal names, or a VPN that supplies its own resolver.

That is the whole decision. The rest of this guide is the mechanism, because each of those exceptions looks the same from where you are standing: pages do not load, and nothing on the screen mentions DNS. For the background on the protocol behind the switch, what private DNS mode is and which transports it uses covers it, and how a name turns into an address covers the layer underneath.

What the toggle actually does

The control has three positions, and they behave nothing alike.

Off. Queries leave in cleartext over UDP port 53, to whichever resolver DHCP handed you. Anyone on the path reads the names and can rewrite the answers. That includes the café router, the hotel gateway, and your ISP.

Automatic. This is opportunistic DoT (DNS over TLS, which is ordinary DNS carried inside a TLS session on port 853). The device probes the resolver the network gave you on port 853. If the TLS handshake works, queries go encrypted. If it fails, they go out in cleartext on port 53, with nothing on screen to tell you. Opportunistic mode also validates no certificate name, because you never gave it a name to check. So it stops passive reading, and it does not stop a resolver that wants to lie to you.

Private DNS provider hostname. This is strict mode. You type a hostname such as dns.quad9.net, and the device stops using the network's resolver completely. It opens TLS to port 853 on that host and checks the certificate against the hostname you typed. If it cannot get that connection, nothing resolves at all. Strict mode fails closed, which is the property you are paying for: there is no silent downgrade to cleartext.

One detail explains much of the odd behaviour below. The device has to turn your hostname into an address before it can connect to it, and it does that using the network's own resolver. A network that answers every query with its own address can therefore break strict mode at that first bootstrap step, before any TLS is attempted.

Recent Android builds may upgrade a small set of well known hostnames to DNS over HTTPS instead, but plan on port 853 being the one that has to be reachable. Other systems have the same setting under other names: DNSOverTLS=yes in systemd-resolved on Linux, an encrypted DNS profile on iOS and macOS, a DoH setting inside the browser, or a DoT forwarder on the router.

What private DNS protects, and what it does not

Private DNS hides your queries from the network you are sitting on. It does not hide them from the resolver operator. Your query log moves from everyone on this wifi, plus every hop after it to one operator you chose. That is a real improvement, and a narrow one. State it that way when someone tells you encrypted DNS makes you anonymous.

It also does not hide where you went. Once the name resolves, your device opens a connection to an address, and that address is visible to the network. The TLS handshake that follows usually carries the site's name in cleartext in the SNI field (server name indication), so an observer can often still name the site you opened. DNS encryption removes the easiest signal, not the last one.

So "should private DNS be on" is really two questions. Is the transport encrypted: yes, turn it on. Who is on the other end: your call, and that one matters more.

When private DNS mode should be off or automatic

Captive portal wifi that never shows its login page

You join hotel or airport wifi. The phone says connected, no internet, and the login page never appears.

A captive portal works by intercepting DNS on port 53 and answering every name with the portal's own address. That redirect is what puts the login page in front of you. Strict mode refuses to use that resolver, and the portal blocks outbound 853 until you have signed in, so no name resolves at all. Android's own portal detection fetches http://connectivitycheck.gstatic.com/generate_204, and when that probe follows your private DNS setting it fails with everything else, so the phone never concludes that a portal is present and never offers you the sign-in sheet.

What you see: Private DNS server cannot be accessed in the network details, or a saved network listed as connected with no internet.

The fix is to set Automatic or Off, complete the login, then put the hostname back. On stock Android the setting is global, not per network, so nothing puts it back for you. That is the one honest argument for leaving a travel phone on Automatic.

Internal names that only the local resolver knows

This is split horizon: a name that resolves on the local resolver and nowhere else, or that resolves to one address inside the network and a different address outside it. nas.home.arpa and git.corp.example.com are the usual shapes. Strict mode sends that query to your public provider, which returns NXDOMAIN (no such domain) or the public address, so your internal service is unreachable, or reached the long way round over the internet.

These are checks you run yourself on the network in question, and the output depends on your own zones:

dig +short git.corp.example.com @192.168.1.1
dig +short git.corp.example.com @9.9.9.9

Two different addresses, or an answer from the local resolver and an empty answer from the public one, is split horizon confirmed. On a Linux laptop, resolvectl query git.corp.example.com shows which server answered.

You have two ways out. Use Automatic on that network and accept cleartext DNS on a network you already trust with your traffic. Or run a resolver that knows the internal zone, give it a hostname you own and a certificate for it, and point strict mode at that. The second option is why a lot of readers end up running their own resolver on a VPS: a DoT endpoint needs a certificate for a real name, which is what a wildcard certificate issued over the DNS-01 challenge is for.

A VPN or mesh network that already supplies a resolver

If your WireGuard client config carries DNS = 10.8.0.1, or your mesh network has its own internal domain, then the private DNS hostname is competing with it. On Android a hostname in strict mode keeps applying while the tunnel is up, so the resolver your tunnel advertises may never be asked anything. The symptom is specific: the tunnel is healthy, wg show lists a recent handshake, public sites load, and internal names fail while a DNS leak test names your private DNS provider instead of your own server. Tailscale documents the same collision from the other side and asks for private DNS off or automatic on Android before MagicDNS will work.

Fixing DNS over a WireGuard tunnel goes through the combinations in detail, and the DNS line in a WireGuard server build shows where the in-tunnel resolver comes from in the first place. If the tunnel will not even connect on that network, private DNS is not your problem: see what to run when your VPN is blocked. On the mesh side, what a mesh network is and is not and sending your traffic out through an exit node on your own VPS both change which resolver should win.

How to tell which one is biting you

Work down this list. Each step is something you run, and the first one that changes the outcome names the cause.

1. Set the toggle to Automatic and retry. If it works, the toggle is the cause and you are choosing between the cases above. If nothing changes, your problem is not DNS.
2. Read the network details on the phone. Private DNS server cannot be accessed means the device could not complete TLS on 853, which points at a portal or a firewall, not at your hostname being wrong.
3. Reach an address instead of a name: ping -c2 1.1.1.1. Replies here with names still failing is the signature of a DNS problem rather than a routing problem.
4. From a laptop on the same wifi, test the port and the resolver directly. nc -vz dns.quad9.net 853 answers whether the network lets you out on 853 at all, and kdig +tls @dns.quad9.net example.com answers whether the resolver itself is responding. kdig comes from the knot-dnsutils package.
5. If the port is open and the resolver answers from the laptop but the phone still fails, check the hostname for a typo. Strict mode validates the certificate against exactly what you typed, so one wrong character fails closed with the same message as a blocked port.

Picking the hostname is the real decision

Strict mode hands one operator every name you look up. So judge a candidate on two things: who runs it and under which country's law, and what they keep. Filtering is a separate axis. Some hostnames drop malware and ad domains for you, which is useful right up to the day it drops something you needed and gives you an NXDOMAIN with no explanation.

As of September 2026 the widely used public endpoints are dns.quad9.net (Quad9, a Swiss foundation, filters known malicious domains), one.one.one.one (Cloudflare), and dns.google. Any of them is a large improvement over cleartext DNS to a hotel router. None of them removes the operator from the picture.

Running your own resolver on a VPS moves that trust to you. Be clear about the trade before you do it. You control the logging policy and you can serve your internal zone, which solves the split horizon case for every network you join. In exchange, your queries now leave one IP address that belongs only to you, so the recursive path and the authoritative servers see a crowd of one instead of your queries mixed into millions. A shared resolver hides you in volume. Your own resolver hides you not at all, while giving you control over the record. Pick the one that matches what you are actually worried about.

Doing it on a laptop or a router

On a systemd box, strict DoT is one drop-in file. Write /etc/systemd/resolved.conf.d/dot.conf:

[Resolve]
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
DNSOverTLS=yes

The text after # is the name the certificate must match, so leaving it off gives you an encrypted session to an unverified server. Apply and check:

sudo systemctl restart systemd-resolved
resolvectl status
resolvectl query example.com

resolvectl status should print +DNSOverTLS in the protocol line and list your servers with their names attached. A query that now takes noticeably longer on the first lookup and then speeds up is normal, because the TLS session is set up once and reused.

Doing it on the router instead covers every device on the LAN, including the ones with no setting of their own, such as a television or a printer. Two limits come with that. The hop from each device to the router stays in cleartext on the LAN, so anyone already on your wifi still sees the names. And the coverage ends at your front door: the phone leaves the house and goes back to whatever the next network hands it. The device setting travels. The router setting does not.

FAQ

Should private DNS be on or off on Android?

On, set to a provider hostname rather than left on Automatic, because Automatic falls back to cleartext port 53 without telling you. Switch it to Automatic only for the specific networks that must resolve names for you: captive portal wifi you have not signed into, a network with internal names, or a VPN whose own resolver you want to use. The setting is global on stock Android, so remember to set it back.

Why does Android say "Private DNS server cannot be accessed"?

The device could not complete a TLS session to port 853 on the hostname you typed, so it refused to resolve anything. The two common causes are a network that blocks outbound 853 (captive portals do this until you log in, and some corporate firewalls do it permanently) and a typo in the hostname, since the certificate has to match what you typed. Test from a laptop on the same network with nc -vz dns.quad9.net 853 to separate the two: a refused or timed out connection is the network, a successful one points at the hostname.

Does private DNS mode hide my browsing from my ISP?

It hides the names you look up from the network you are on, including your ISP, and it moves that visibility to the resolver operator you chose. It does not hide the addresses you then connect to, and the TLS handshake after the lookup usually carries the site name in cleartext in the SNI field. So an observer loses the easiest record of your browsing and keeps a harder one.

Why do internal or VPN names stop resolving when private DNS is on?

Because strict mode sends every query to your chosen public resolver, and that resolver has never heard of nas.home.arpa or your company's internal zone. It answers NXDOMAIN, or it answers with the public address when the name exists in both views. The same thing happens to a VPN that advertises its own resolver, since the private DNS hostname keeps applying while the tunnel is up. Either set the toggle to Automatic on those networks, or run a resolver that serves the internal zone and expose it on 853 with a valid certificate so strict mode can use it everywhere.