Ordinary DNS is sent in plain text, so anyone on the path between you and your resolver can read every hostname you look up, and in principle change the answers. DNS over HTTPS (DoH) and DNS over TLS (DoT) both fix that by encrypting the lookup. They protect the same thing in almost the same way. The real differences are about who can see that you're using them, and the bigger point is how much encrypted DNS leaves uncovered.
A normal DNS query goes out over UDP port 53, unencrypted. The Wi-Fi network you're on, your ISP and any network in between can log it or tamper with it. That's how some ISPs build browsing profiles, how some networks block sites, and how hotspots inject their own answers.
Encrypted DNS wraps that same question in TLS, the same encryption HTTPS uses, and authenticates the resolver with a certificate. Observers on the path see that you're talking to a resolver, but not what you asked or what came back.
Both do the same job. The DNS message inside is identical. What differs is the wrapping.
DNS over TLS (RFC 7858) runs DNS directly inside a TLS connection on its own dedicated port, 853. It's simple and it's what Android's Private DNS setting uses, from Android 9 onwards.
DNS over HTTPS (RFC 8484) sends DNS messages as HTTPS requests on port 443, with the content type application/dns-message. To the network it looks like any other HTTPS traffic. Browsers mostly use DoH: Firefox and Chrome both support it, and Windows 11 has it built into the network settings.
There's a newer third option, DNS over QUIC (RFC 9250), which some resolvers and apps support. It's rarely what you'll meet in a settings menu yet.
In practical terms:
Speed differences between the two are small next to the distance to the resolver itself. Pick based on where you can configure it, not on benchmarks.
This is the part most guides skip, and it's where expectations go wrong.
The resolver still sees everything. Encryption protects the trip, not the destination. Cloudflare, Google, Quad9 or whoever you've chosen decrypts and reads every query. You've moved the log from your ISP to your resolver. That can be a good trade, but it is a trade.
The IP address you then connect to is visible. After the lookup, your browser connects to the site's IP address, and every network on the path can see that. For a site on its own dedicated address, that's as revealing as the hostname. For sites behind a big CDN, many domains share addresses, so it reveals less.
The hostname often leaks again in the TLS handshake. When your browser starts an HTTPS connection, it sends the hostname in the Server Name Indication (SNI) field so the server knows which certificate to present. Traditionally that field is unencrypted. Encrypted Client Hello (ECH), now published as RFC 9849, encrypts it, but it only works when both the browser and the site support it. Without ECH, your ISP can read the site name from the handshake even though your DNS lookup was hidden.
The resolver's own lookups are mostly plain text. Between your resolver and the authoritative name servers for each domain, the queries are usually still unencrypted. Your IP address isn't in them (unless the resolver sends a partial client subnet), but the names are.
It doesn't prove the answer is true. Encryption proves you're talking to your chosen resolver. It doesn't prove the resolver's answer matches what the domain owner published. That's DNSSEC's job, which is about authenticity, not privacy. The two complement each other.
So the fair summary: encrypted DNS stops the local network and your ISP from reading or tampering with your lookups. It does not make you anonymous, and on its own it doesn't stop your ISP knowing which sites you visit. If that's your goal, look at a VPN or Tor, as covered in VPN vs proxy vs Tor.
Chrome's automatic mode keeps your current DNS provider. If your system resolver is one Chrome knows has a DoH endpoint, it upgrades to encrypted DNS with that same provider, and otherwise it stays with plain DNS. Managed (enterprise) devices are opted out automatically, and administrators control it by policy. You can pick a specific provider under chrome://settings/security, in the "Use secure DNS" option.
Firefox enables DoH by default for desktop users in some countries, including the United States and Canada, in a fallback mode: if DoH fails, it uses the system resolver rather than showing an error.
Android has an Automatic Private DNS mode, which tries DoT with your network's resolver and falls back to plain DNS if it isn't supported. Entering a hostname switches to strict mode, where lookups fail rather than fall back. That's more private, and it's also why a strict setting can break hotel Wi-Fi logins.
Apple added system support for both DoH and DoT in iOS 14 and macOS 11. It's switched on through an app or a configuration profile rather than a toggle in Settings.
If you haven't picked a resolver yet, our guide to changing your DNS server lists the main providers and the setup on each platform.
For DoH, curl can use an encrypted resolver for a single request:
curl --doh-url https://cloudflare-dns.com/dns-query https://example.comCloudflare also answers DoH in a readable JSON form, which is handy for seeing the raw answer:
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A'With BIND 9.18 or later, dig can send both kinds itself (the older dig shipped with macOS can't):
dig +https @1.1.1.1 example.com
dig +tls @1.1.1.1 example.comTo compare what an encrypted resolver returns against the records the domain actually publishes, run the same name through our DNS lookup tool. Matching answers mean the resolver isn't rewriting anything.
No. The encryption is the same TLS in both. DoH is harder to spot and block, which some people count as more private. DoT is easier to manage on networks you run. Neither protects the lookup better than the other.
On phones and laptops that use public Wi-Fi, yes, it's a sensible default. On managed work devices, leave it to IT, because it can bypass security filtering they rely on.
Many organisations filter malicious domains at their own resolver. An app using DoH to an outside resolver skips that filter entirely, so admins block it to keep their protection in place.
The first query opens a TLS connection, which adds a small setup cost. After that the connection is reused, and in everyday use the difference is hard to notice. Distance to the resolver matters far more.
0 comments
No comments yet. Be the first.