Android Private DNS vs a VPN: DoT Hostname Versus Tunnel DNS

On Android 9 and later, Settings has a Private DNS row. Automatic tries opportunistic encryption to the network's resolver. Off is clear DNS. Provider hostname is the strict mode people mean when they search this: you type a name such as dns.google or one.one.one.one, and the phone must speak DNS-over-TLS to that host or DNS fails. That is a locked bag to a resolver. The cafe that was going to sniff UDP 53 sees a TLS session to that hostname instead, often on port 853. The resolver still sees the names. That is the trade. You moved the reader from the coffee shop to whoever runs the hostname you typed.

Browser DoH is a cousin, not this row. Firefox encrypting DNS for Firefox does not wrap Chrome, Mail, or the Play updater. Private DNS is OS-shaped. App DNS questions that go through the system stub can ride it. That is the distinction the DoH essay already flagged in one paragraph. This page is that paragraph as a full leftover. Celebrate the size. Then look at sessions. Mail still opens a TCP or QUIC path to a mail IP. Slack still opens a path to Slack. Those paths are not DNS. Private DNS does not wrap them. A system VPN does, from the cafe's chair, when the client is doing its job.

Farms will rank 'Private DNS vs VPN winner' until the cookie dies. There is no winner. There are two envelopes. You can use Private DNS off-VPN to stop clear DNS on a LAN. You can use a VPN to move the hop. You can use both and fight yourself. Crown neither.

Klox's envelope is the truck. WireGuard first. OpenVPN when the AP is rude. DNS through the tunnel is the documented default. I will not invent a consumer UI where you type a DoT hostname. If a white-label brand wanted custom DNS copy, that is a different article and a different chair. You are a consumer. There is no custom DNS SKU in this sentence.

Private DNS hides clear DNS from the local path. The cafe that used to see 'bank.example' on port 53 sees a TLS session to your DoT host instead. On a network that logs classic DNS, that is a real change. On a network that already could not read port 53 because Automatic mode upgraded opportunistically, you may already have a quieter question without naming it. Strict hostname mode is louder as a choice: you picked the reader.

It also hides the shopping list from an ISP that was only watching UDP 53. The ISP can still see you spoke to the DoT host. They can still see you later spoke to website IPs, mail IPs, chat IPs. They often still see SNI. Encrypted Client Hello is uneven. Do not claim the shop sees nothing because Settings has a lock icon on DNS. The win is narrower than the marketing. Narrow can still be worth it when you are off a VPN and the leftover you care about is clear names.

The resolver you typed still gets every question the stub sends. Cloudflare, Google, Quad9, a 'privacy' hostname a blog ranked: that machine is the new reader. Famous is not the same as 'nobody has the list.' You moved the list. Say that. If you are fine with that reader, Private DNS did the job it actually has. If you wanted nobody to have the list, you wanted a different threat model, maybe not a consumer DNS row at all.

I will not rank hostnames. NordVPN's DoH post is a specimen of the genre. Use it as a specimen. Do not import their picker into Klox. We are not a public DoT app. We are a tunnel that already owns names while connected.

Destination IPs of HTTPS. You asked the hostname for a name. You got a number. Chrome connected to the number. That connection is not DNS. TLS wraps the page. RFC 8446. The cafe can still see the number. Often the name in SNI during start. Encrypted Client Hello tries to quiet the name and is uneven. The number remains either way. A VPN hides that number from the cafe by making the interesting hop the VPN server. Private DNS does not.

Mail and Slack are the examples people skip. Their DNS questions can ride Private DNS. Their sessions do not. The cafe still sees you spoke to those IPs. Volume remains. Timing remains. A fat stream to a known CDN IP is a fat stream. DoT does not camouflage it. The DoT session itself is another IP the cafe sees: you talked to a resolver host. That is a smaller map than a shopping list of every site, and a larger map than 'I used a VPN node.' Pick the map you actually wanted.

WebRTC can still volunteer an address. IPv6 can still sneak. Those leftovers are not Private DNS's job. Features lists protections for a connected Klox session. Quote them for Connect. Do not quote them for a Settings hostname. The hostname never claimed the NIC.

Cookies in the browser still exist after DoT and after HTTPS. Our /cookie page is this website. Gmail's cookies are Google's. Neither envelope eats them. If you wanted tracking reduced, that is a different drawer. Tunnel DNS is not an ad blocker. I will not mash Private DNS into a blocklist either.

With Klox connected, the cafe's interesting packet is a blob to a VPN node. Inner website IPs sit behind that blob. Mail and Slack sessions sit behind that blob if they use the default NIC. DNS questions, if they ride the tunnel, sit behind that blob. That is the hop job. It is bigger than Private DNS. It costs a seat, a handshake, sometimes a rude AP that hates UDP. WireGuard first. OpenVPN when that AP is rude. Same DNS story on both protocols if the client is still routing names through the tunnel.

Android implements consumer VPNs through VpnService. Always-on is policy on top of that service. This page is not the Always-on essay. That URL already exists. Here: a connected system VPN is how you wrap the device hop, including DNS through the tunnel on Klox. Private DNS is how you wrap the question to a third party when you are off that hop.

The VPN resolver sees the names. We are a hop operator. On HTTPS sites, we are not the website. Inner TLS still ends at the site. RFC 8446 still applies. People ask whether the VPN can read Gmail. On a normal HTTPS site, the inner lock still faces Gmail. The resolver still saw the name gmail was requested. That is a shopping list at our resolver, not an inbox. If that still bothers you, you wanted a different threat model.

Five devices: phone plus tablet is two seats if both tunnels are up. Private DNS on one Pixel does not cover the laptop. Per device. A tunneled phone does not hide the laptop's clear DNS. Count.

Private DNS plus tunnel DNS is how people get a leak they cannot draw. The stub might still pin the hostname you typed and send DoT off-tunnel. Or it might DoT inside the tunnel to a third party, so the cafe sees a blob but a public resolver still gets the list and your VPN exit IP. Or the OS might ignore both and use the cafe's DHCP DNS. Three owners. One green VPN icon. A leak-test page that disagrees with your feelings.

My rule: while Klox is up, let Klox own names. Set Private DNS to Automatic or Off unless you have measured that the hostname stays inside the tunnel and you like that third-party reader. Most people should not measure. Most people should leave the default. The resolver-hop article already said stop collecting resolvers like vitamins. This page repeats it because Private DNS is how vitamins get installed on a Pixel.

If you are off the VPN, a Private DNS hostname can be a reasonable cafe habit for the question leftover. It still will not hide IPs. If that leftover still bothers you, Connect. Do not 'fix' a VPN by adding a hostname on top without a test. Fix a leak with the leak articles, then stop.

Split tunnel, if you ever punch a hole, makes this worse. Excepted apps may use system DNS. System DNS may be cafe DHCP if Private DNS lost the fight. The hole is a scheduled leak. The hostname will not patch the hole. The split-tunnel English lives elsewhere. Here: do not stack three leftovers and call it defense in depth.

Some networks want their own resolver. Schools filter names. Offices inspect names. They hand you DHCP DNS, or they push a profile, or they break DoT on purpose so filtering still works. Private DNS in strict hostname mode can fail those networks: the phone cannot reach your typed host, or the portal never completes, or an app cannot resolve. That failure is the policy working. It is not a Klox bug.

I will not coach you around that policy. I will not give you a hostname that 'just works on the campus filter.' I will not tell you to pin dns.google so the lab cannot see names. If you do not run the network, you follow the network. If the leftover you wanted was a cafe hop you do run as a guest, Connect after the splash. If the leftover is a managed device, this essay is background. Read the Always-on article if lockdown is the row that is fighting the portal. Different row.

Captive portals hate extra DNS wraps. Hotel lobby, airport, campus guest: complete the splash first. Private DNS strict mode can deadlock the portal the same way a tunnel can. Pause the wrap. Sign in on a boring site. Restore. The cafe habit post owns the timing. Here: a hostname is another wrap that can deadlock. Name it before you blame WireGuard.

Five devices do not share a Private DNS hostname. The Pixel setting is not the iPhone. You will 'fix DNS' on Android and then leak on the laptop. Per device. Download the real client from /download so you are not configuring a cousin app's Secure DNS screen from memory.

Always-on VPN and Block connections without VPN are OS settings on top of a VpnService app. Private DNS is a resolver setting. People turn all three on because a blog said to, then they cannot log into hotel Wi-Fi, and they uninstall. The Always-on essay already covered battery, portals, and five-device households. I will not clone it. I will say: Always-on is a lock on the hop. Private DNS is a lock on the question. Locks stack until a portal needs a key.

If you travel on a phone that should stay tunneled, Always-on can be the right lock, with the block off until you know how to pause for a splash. Private DNS on that same phone, while Klox is up, is the stacking leftover. Prefer one owner. If you only wanted quieter DNS on a phone that will not run a VPN, Private DNS is the smaller envelope. Honest. Small. Not a cape.

Smart Connect, if the app shows the row, is untrusted Wi-Fi. It starts the truck. It does not type a DoT hostname. If the row is missing, you have a Connect button. Use the button. I will not invent a DNS mode so this article matches a competitor's 'Secure DNS' screenshot.

IPv6 can still sneak around a v4-only leftover. WebRTC can still volunteer an address. Features lists protections. Confirm after connect if you like labs. Then stop. Daily hostname experiments are how people forget to live.

Klox is the truck: WireGuard, OpenVPN, OpenConnect, and Shadowsocks, five devices, yearly from $2.83 a month, 7-day first-purchase money-back. DNS through the tunnel. IPv6 and WebRTC called out on Features. Download from /download. Do not sideload a random APK because a listicle hosted one. Do not paste a DoT hostname into Settings because a farm said it was faster. Faster DNS to a public host can be a leak you scheduled.

We are not dns.google. We are not a recursive-resolver brand. Google's Private DNS help is a follow link so you can see the other envelope in someone else's words. Wikipedia's VPN page is the noun for ours. RFC 8446 is still the page lock. Three documents. Three jobs. Keep them in separate drawers.

If you want proof the resolver hop moved, use DNS Leak: Why It Matters and How to Test and the after-connect checklist. This page will not become those procedures. A leak site that still shows your ISP while the UI says connected is the failure mode. A leak site that shows a public DoT host while you wanted tunnel DNS is the stacking mode. A leak site that shows the VPN is the hop you paid for. Do it once on a network you control. Then stop.

Yearly from $2.83 a month is not a resolver ranking. Seven days on first purchase if the apps will not own DNS and you are inside the clock. /refund. Store purchases follow the store. This page will not turn into a billing sermon. It will also not turn into a custom-DNS roadmap. Absence of a picker is the product. Practice once on a guest SSID. Then use it.