Until ~2018, every DNS query you made was unencrypted plaintext. Anyone on the network path — your ISP, the coffee shop Wi-Fi operator, a curious advertiser — could see exactly which domains you were resolving. They didn’t see the content of HTTPS-protected sites you visited, but the names leaked.

DNS over HTTPS (DoH) and DNS over TLS (DoT) fix that. Both encrypt DNS queries between client and resolver. They achieve the same goal but with different protocols, different deployment patterns, and different controversies.

This post explains both, when each is preferred, and the implications for users, network operators, and application developers.

A Quick Recap of Plain DNS

Standard DNS:

Protocol: UDP port 53 (TCP for large responses).
Encryption: None.
Observable by: Your ISP, anyone on the wire between you and the resolver.

When you visit bank.com, your browser asks your configured DNS resolver “what’s the IP for bank.com?” That query travels in plaintext. The response (the IP) also travels in plaintext.

The HTTPS connection to bank.com is encrypted — but the DNS query that revealed you were going to bank.com was not. This is the gap that DoH and DoT close.

For a refresher on how DNS works generally, see how DNS lookup works.

DNS over TLS (DoT)

DoT wraps DNS queries in TLS. The connection runs over TCP port 853 (dedicated port). Once the TLS handshake completes, the same DNS message format flows over the encrypted channel.

Client → TLS handshake on port 853 → Resolver
Client → encrypted DNS query → Resolver
Resolver → encrypted DNS response → Client

Specified in: RFC 7858 (2016).

Implementations: Most major resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) all support DoT. OS-level integration in Android 9+ (Android calls it “Private DNS”), iOS 14+, Linux via systemd-resolved.

Identifying characteristic: Port 853. Network operators can see “this device is doing encrypted DNS” because the port is unique.

DNS over HTTPS (DoH)

DoH wraps DNS queries in HTTPS. Queries are encoded as either GET or POST requests to a resolver’s HTTPS endpoint.

GET https://cloudflare-dns.com/dns-query?name=bank.com&type=A
Accept: application/dns-message

Response: application/dns-message (binary DNS response)

Specified in: RFC 8484 (2018).

Implementations: Firefox (since 62), Chrome (since 78), Edge, Safari. Most modern browsers default to DoH for some users. Cloudflare, Google, Quad9, and others all run DoH endpoints.

Identifying characteristic: Looks indistinguishable from any HTTPS traffic on port 443. Network operators can’t easily tell DoH from regular web browsing.

The Key Difference

Both encrypt DNS. Both prevent on-path observers from seeing your queries. The difference is visibility to the network operator.

Aspect	DoT (port 853)	DoH (port 443)
Encrypted	Yes	Yes
Distinguishable from regular HTTPS	Yes (port 853)	No
Easy for network ops to block	Yes (block port 853)	No (would have to block all HTTPS)
Easy for network ops to allow but observe	Just see TLS metadata	Sees nothing distinct
Default in modern OSes	iOS, Android	Browsers
Default in modern browsers	No	Yes

This drives most of the politics around encrypted DNS:

DoH can’t be blocked without breaking HTTPS, which is why repressive regimes and corporate network admins dislike it.
DoT can be blocked at the firewall, which is why the same admins prefer it (if they have to accept encrypted DNS at all).
Users generally prefer DoH because it works in more network environments — including hostile ones.

Who Resolves Your Queries Now?

The bigger shift isn’t encryption — it’s who you trust to resolve DNS for you.

Pre-DoH: your ISP. Your computer was configured (via DHCP) to use your ISP’s resolver. The ISP saw all your DNS, profiled it, sometimes sold it.

Post-DoH: often a centralized provider. Firefox, by default, routes DNS through Cloudflare (in regions where it’s enabled). Chrome bootstraps with Google. Safari uses Apple’s resolver.

The privacy gain (no more ISP snooping) comes paired with a centralization concern (Cloudflare, Google, and Apple now see DNS for a substantial fraction of internet users). Each of these providers has published privacy policies; the actual privacy posture depends on whether you trust the policy and the implementation.

Use Cases

DoH in browsers

Modern browsers default to DoH for many users. The browser sets its own DoH resolver (usually with an opt-out preference). This protects users from network-level snooping even when the OS DNS is left at default.

DoT in mobile OSes

Android’s “Private DNS” feature uses DoT by default for many configurations. You enter a resolver hostname; Android opens a DoT connection. Whole-system DNS encryption.

DoH for application developers

If you’re building an application that resolves DNS programmatically (a CLI tool, a bot, a backend service), you can speak DoH directly:

const response = await fetch('https://cloudflare-dns.com/dns-query?name=example.com&type=A', {
    headers: { 'Accept': 'application/dns-json' }
})
const data = await response.json()
console.log(data.Answer[0].data)  // e.g., "93.184.216.34"

This is sometimes useful for portable code that needs to bypass system DNS or work in restricted environments.

DoT for self-hosted DNS

Run-your-own-DNS deployments (Pi-hole + Unbound) often enable DoT for the upstream side — your resolver forwards encrypted queries to a public resolver.

The Controversies

Encrypted DNS has had two big controversies since rollout:

1. Bypassing parental and corporate controls

A school filters DNS to block adult content. A corporate network filters to block malware. Both rely on seeing DNS queries — which DoH defeats. Browsers enabling DoH “above the network layer” caused friction with these admins.

Resolution (sort of): browsers now check whether the local DNS resolver is “trusted” before enabling DoH. If your network advertises certain canary domains saying “don’t use DoH,” the browser respects that. Imperfect but workable.

2. Centralization of DNS resolution

Tens of millions of users moving from ISP DNS to Cloudflare/Google/Apple represents enormous centralization. Critics argue this trades distributed but observable DNS for centralized but encrypted DNS — better for some threat models, worse for others.

Resolution (ongoing): more providers run resolvers (Quad9, AdGuard, NextDNS, individual ISPs starting their own DoH/DoT endpoints). Users can choose; defaults still matter most for typical users.

Performance

DoT and DoH both add some latency compared to plain DNS.

DoT: TLS handshake setup time (~50ms on first connection). Subsequent queries reuse the TLS session, so per-query overhead is minimal.
DoH: Same overhead as TLS, plus HTTP framing. Slightly higher overhead but negligible in practice.

Caching, connection pooling, and HTTP/2 multiplexing make the differences imperceptible to users. In 2026 the latency cost of encrypted DNS is essentially zero.

DoT vs DoH for Different Audiences

For end users

DoH is what you get by default in modern browsers. DoT works at the OS level if your OS supports it. Either is much better than plain DNS. Pick a resolver you trust (1.1.1.1, 9.9.9.9, NextDNS, etc.) and configure it.

For network operators

DoH is harder to manage because it’s indistinguishable from web traffic. Encourage internal use of DoT (port 853, blockable, configurable) or run your own DoH endpoint and direct internal traffic there.

For application developers

You generally don’t think about this. The OS or browser handles DNS for you. Where it comes up: if you’re building a network tool, security software, or a service that needs deterministic DNS, you may need to bypass the OS resolver and speak DoH or DoT directly.

For privacy advocates

Encrypted DNS is necessary but not sufficient. Use it, but also be aware that DNS encryption doesn’t hide which IP you connect to next (the connection itself is observable, even if its DNS lookup isn’t).

Combining With Other Privacy Layers

DNS encryption is one layer of a privacy stack:

DoH/DoT — Encrypts DNS queries.
HTTPS / TLS — Encrypts the application data.
ECH (Encrypted Client Hello) — Hides the SNI field in the TLS handshake (which would otherwise reveal which site you’re connecting to even with HTTPS).
VPN / Tor — Hides your source IP from the destination.

In 2026 all four are mature. A modern privacy-conscious user has all of them by default.

What This Means for Application Code

For most application developers, encrypted DNS is transparent — your code does fetch('https://api.example.com') and the underlying OS handles DNS resolution however it’s configured.

A few places where it matters:

Custom DNS resolution

If you implement your own DNS (security tools, network analyzers), you should support DoH/DoT, not just port 53.

Reverse DNS / forward DNS lookups

For reverse DNS and forward DNS lookups in your backend, the standard OS APIs use whatever DNS the system is configured for — usually plain DNS to the system resolver, which then upstreams via DoH/DoT if configured.

Logging considerations

If you log DNS queries (security monitoring, compliance), be aware that DoH/DoT mean the queries are no longer visible at the network layer. You’d need to capture them at the application layer.

TL;DR

Both DoH and DoT encrypt DNS between client and resolver.
DoT runs on port 853 — distinguishable, blockable.
DoH runs on port 443 — indistinguishable from HTTPS.
Modern browsers default to DoH. Modern mobile OSes prefer DoT.
The privacy gain is real — ISPs and on-path observers no longer see your DNS.
The centralization concern is real — a handful of providers now resolve DNS for most users.
Performance is essentially identical to plain DNS in 2026.
Network admins managing encrypted DNS should use DoT internally for visibility.

For DNS basics, see how DNS lookup works and the DNS record types reference. For IP intelligence — country, city, ASN — once DNS gets you the IP, the Ip2Geo API handles the rest.

DNS over HTTPS vs DNS over TLS: Encrypted DNS Explained