Switch on DNS over HTTPS in Chrome and the obvious conclusion is that Airtel or Jio can no longer see what you browse. That reading follows directly from how the feature is described, and it is wrong in a way that matters. The second surprise usually arrives at home: turn on Private DNS in Android settings, walk back into a flat where a Pi-hole does the filtering, and ads reappear across every app, because the phone has stopped asking the Pi-hole anything at all. Both features are behaving exactly as designed. Encrypted DNS is genuinely worth turning on, and it is also the most over-claimed privacy setting on a modern device, which is an awkward pair of facts to hold at once. So here is what it actually encrypts, who can still tell which sites you visit afterwards, and the three places where switching it on changes something real.
what a plain DNS lookup looks like on the wire
Before your browser can fetch anything, it has to turn a name into an address. That question goes out on UDP port 53, in the clear, usually to whichever resolver your ISP handed you over DHCP. No encryption, no authentication of the answer. Any device between you and the resolver can read the question, and in principle rewrite the answer.
# Which resolver is this machine actually using?
resolvectl status | grep -i 'DNS Server'
# A plain query, the old way
dig +short technobabu.com
# Anything on the path can read that name. Plain DNS has no encryption
# at all; it simply was not part of the original design.Two consequences follow. Your ISP has a complete list of every domain you asked about, timestamped, tied to your connection, whether or not you ever visited the site. And on a network you do not control, the answers you get are whatever that network chose to give you. Encrypted DNS closes both of those gaps and nothing else. Hold on to that sentence, because the rest of this article is really about the word nothing.
DoH and DoT, and where each one lives
Both wrap the same DNS queries in TLS. The difference is packaging, and the packaging decides who can tell that DNS is happening at all.
DoT: DNS over TLS
DoT runs on its own port, 853, and looks like what it is. A network operator can see that you are doing encrypted DNS, can see which resolver you chose, and cannot read the queries. Because it sits on a dedicated port, it is easy for an operating system to manage centrally, which is why Android’s Private DNS feature was built on it. Easy to manage also means easy to block, and a network that blocks 853 will push you back to plain DNS unless you have told the device to fail closed.
DoH: DNS over HTTPS
DoH puts queries inside ordinary HTTPS on port 443, mixed in with the rest of your web traffic. Harder to single out, harder to block without blocking real websites. It is also the one browsers ship, and that has a side effect people miss: the browser resolves names itself, ignoring whatever the operating system was configured to use. That is how a single browser setting can quietly make your whole household DNS policy irrelevant.
| Where you set it | Protocol | Covers |
|---|---|---|
| Chrome or Firefox settings | DoH | That browser only |
| Android, Private DNS | DoT | Whole phone, including apps |
| Windows 11, per-adapter DNS | DoH | Whole machine |
| Linux, systemd-resolved | DoT | Whole machine |
| Router or local resolver | DoT or DoH upstream | Every device on the LAN |
The arrangement that works: encrypted upstream configured once on the machine that serves DNS to the flat, browser DoH switched off so it does not sidestep that, and Private DNS on the phones for when they leave the house.
the part the marketing skips
Encrypting the lookup hides the question. It does not hide the visit. Three things still expose which sites you reach.
The address you connect to. Immediately after the lookup, your device opens a TCP connection to an IP address, and that address travels in every packet header. Your ISP sees it. For a site on its own server, the address alone identifies the site. Shared hosting and large CDNs blur this usefully, but they do not remove it.
The name in the TLS handshake. HTTPS connections normally announce the hostname they want in cleartext, in a field called SNI, so that one server can host many sites. Anyone watching the first packets of the connection reads the domain there, encrypted DNS or not. Encrypted ClientHello is the fix and it is still spreading unevenly, so assume the name is visible today.
The resolver you chose. You stopped handing your query log to your ISP and started handing it to whoever runs the resolver. That is a real improvement or a real downgrade depending entirely on the two parties. It is the same trust-shifting arithmetic I went through in the VPN explainer, and it never disappears, it only moves.
Short version to give the relatives: encrypted DNS stops the network you are on from reading and tampering with your lookups. It does not make your browsing private from your ISP, and it does not hide anything from the websites themselves.
choosing a resolver is choosing whom to trust
Ask three things of a candidate. What does it log and for how long, stated in writing rather than implied by a marketing page. What jurisdiction is the operator in. And does it filter anything, because some resolvers block malware domains by default, which many households want and a few people find intrusive.
On response speed, a resolver with servers inside India will feel quicker than one answering from Singapore or Frankfurt, and the difference is a small delay you will not notice on a warm cache. Figures pulled off a single connection in Patna are not a benchmark, so this article will not dress any up as one. Test two candidates on your own line for a day each and keep the one that feels right.
setting it up in the three places that matter
On Android, Settings, then Network and internet, then Private DNS, then enter the hostname of your provider. This is the single highest-value privacy toggle on a phone that spends its day on mobile data and strange Wi-Fi, because it covers apps and not just the browser.
On a Linux box or home server, systemd-resolved handles DoT with a few lines:
# /etc/systemd/resolved.conf.d/encrypted.conf
[Resolve]
DNS=9.9.9.9#dns.quad9.net
Domains=~.
FallbackDNS=
DNSOverTLS=yes
DNSSEC=allow-downgrade
Cache=yessudo systemctl restart systemd-resolved
# Confirm it, do not assume it
resolvectl status | grep -E 'DNSOverTLS|Current DNS'
resolvectl query technobabu.comThe hostname after the hash is not decoration. It is the name the certificate must match, and without it you get encryption with no verification of who answered. Domains=~. makes this server the default for every lookup, so servers handed out by DHCP aren’t used instead. DNSOverTLS=yes is strict mode and refuses to fall back to plain queries. An empty FallbackDNS= stops systemd-resolved using its built-in fallback servers. You’d rather see a failure than be downgraded without noticing.
On a router, look for upstream DNS settings supporting DoT or DoH. Plenty of ISP-supplied boxes cannot do it, which is one of several reasons I would put resolution on a small always-on machine instead.
living with a Pi-hole at the same time
This is where most households come unstuck, and it is the Private DNS situation described at the top of this article. If a local resolver does your filtering, as in my Pi-hole setup guide, then a device using encrypted DNS directly never asks it, so nothing gets filtered. Both features are working correctly and fighting each other.
The arrangement that works: point the local resolver’s upstream at an encrypted resolver, so LAN queries are filtered and then leave the house encrypted. Then turn browser DoH off on machines at home, and turn Private DNS off on phones while on home Wi-Fi if your phone lets you make it conditional. You lose encryption between your device and your own Pi-hole, which sits on your own LAN, and that is a trade I am comfortable with. Device-level filtering is the complement rather than the replacement here, which is the case I made in the DNS-level blocking explainer.
common mistakes
- Believing the lookup is the browsing. Encrypted DNS hides the question, while the address and usually the hostname in the handshake still go out in the open.
- Setting it in one browser and calling the device done. Every other app on the machine carries on with plain port 53.
- Omitting the certificate hostname in a DoT configuration, which leaves you encrypted to a server you never verified.
- Leaving a plain fallback configured, so any network that blocks the encrypted port silently downgrades you.
- Running encrypted DNS on a device and a filtering resolver on the LAN without deciding which one wins.
- Switching resolvers for privacy without reading the logging policy, which is the only part of the decision that actually concerns privacy.
FAQ
does encrypted DNS slow my connection?
Barely, and only on the first lookup for a name. TLS adds a handshake, then the connection is reused and answers are cached locally, so the cost lands once and then disappears. A resolver physically far from you will feel slower than a nearby one, which is worth more attention than the encryption overhead.
should I use this instead of a VPN?
They cover different ground. Encrypted DNS protects your lookups and costs nothing; a VPN also hides the addresses you connect to from your ISP, at the price of trusting the VPN operator with all of it. On a café network I would rather have both, and if I had to pick one habit to fix first it would be neither of these, it would be the account hygiene I wrote about in password managers and 2FA.
can my ISP still block sites if I use DoH?
Yes. Encrypted DNS only affects name resolution, and enforcement can also happen on the address or the hostname in the TLS handshake, both of which remain visible. Lawful blocking in India is a requirement placed on ISPs, and nothing in this article is about working around it. Treat encrypted DNS as protection against passive collection and tampering on untrusted networks, not as a switch that changes what your connection is allowed to reach.
Of the three places covered above, the phone’s Private DNS setting does the most for the least effort, because it covers apps and not just the browser. The decision that deserves more thought is which single resolver your household trusts, since that matters more than which of the two protocols you picked.
Update history: corrected a misleading code comment, added Domains=~. to the systemd-resolved example with a clearer explanation of each setting, and cited RFC 6066 for SNI.