Classic DNS travels across the network in plaintext over UDP or TCP port 53, which means anyone on the path (a coffee shop router, an ISP, a transit provider) can read every hostname you look up and even rewrite the answer. Encrypted DNS fixes the confidentiality and integrity gap by wrapping those same queries in a TLS session. The two standards you will meet are DNS over TLS (DoT), defined in RFC 7858 and served on port 853, and DNS over HTTPS (DoH), defined in RFC 8484 and served on port 443. This guide explains how each works, where they differ, and how to test and deploy them without locking yourself out of name resolution.
Why plaintext DNS is a problem
DNS is the one lookup almost every connection starts with, so it is a rich side channel. Three distinct risks come from sending it in the clear:
- Eavesdropping: a passive observer learns which sites, mail hosts, and apps you contact even when the traffic itself is HTTPS encrypted.
- Tampering: an on-path attacker can forge a response and send you to the wrong address, a classic spoofing or cache-poisoning move.
- Censorship and injection: some networks return a fake NXDOMAIN or a captive-portal address for names they dislike.
Encrypted transports close the first two gaps between you and the resolver you choose. They do not encrypt the final authoritative lookups the resolver performs on your behalf, and they do not hide the destination IP address, which still appears in the IP header. Server Name Indication in TLS is a separate leak that Encrypted Client Hello addresses.
DNS over TLS (DoT)
DoT is the simplest conceptually: it is ordinary DNS wire format, the exact same bytes you would send on port 53, carried inside a TLS tunnel on a dedicated port, 853. Because it has its own port, a network operator can see that you are doing encrypted DNS and can choose to allow or block the port, but the operator cannot read the queries. Resolvers typically keep the TLS connection open and pipeline many queries over it to amortize the handshake cost.
A key operational detail is authentication. In strict (authentication-required) mode the client verifies the resolver certificate against a configured hostname so it knows it reached the real server and not an interceptor. In opportunistic mode the client will fall back to cleartext if TLS fails, which protects against passive snooping but not an active attacker.
# Query over DoT with kdig, verifying the certificate hostname
kdig -d @1.1.1.1 +tls-hostname=cloudflare-dns.com +tls example.com A
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 4211
;; ANSWER SECTION:
example.com. 276 IN A 23.192.228.80
DNS over HTTPS (DoH)
DoH carries the same DNS wire-format message, but inside an HTTPS request on port 443, the port that carries almost all web traffic. A GET request encodes the query in a base64url parameter named dns; a POST request puts the raw query in the body. The media type is application/dns-message. Because the traffic rides port 443 and looks like any other HTTPS flow, DoH is much harder for a network to single out and block without breaking the web.
# DoH over HTTP/2 using curl with the RFC 8484 GET form
curl -s -H 'accept: application/dns-message' \
'https://cloudflare-dns.com/dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' \
| xxd | head -3
# JSON convenience API (not RFC 8484, provider specific)
curl -s -H 'accept: application/dns-json' \
'https://dns.google/resolve?name=example.com&type=AAAA'
Many browsers ship DoH built in and will use it by default on some networks, which is why DoH is both praised for user privacy and criticized by operators who lose visibility into malware callbacks and can no longer enforce DNS-based filtering at the network edge.
DoH vs DoT side by side
| Property | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|
| Core RFC | RFC 7858 | RFC 8484 |
| Port | 853 | 443 |
| Transport | TLS over TCP | HTTPS (HTTP/2 or HTTP/3) |
| Message format | DNS wire format | DNS wire format, or JSON on some APIs |
| Blends with web traffic | No, distinct port | Yes, looks like normal HTTPS |
| Easy for networks to block | Yes, block port 853 | Hard without breaking 443 |
| Typical consumer | OS stub resolver, routers | Browsers, apps, OS |
Where encryption starts and stops
Both protocols secure the link between a stub or forwarder and the recursive resolver. They do not change what happens upstream. The recursive resolver still queries authoritative nameservers, and those queries are usually plaintext on port 53 unless the recursive and authoritative sides both support an emerging standard such as authoritative DoT. If you want the content of the answer to be verifiable against tampering end to end, that is the job of DNSSEC, which signs records cryptographically. Encrypted transport and DNSSEC are complementary: one hides and protects the channel, the other proves the data is authentic.
Choosing a deployment model
There are three common ways to adopt encrypted DNS, each with a tradeoff between coverage and control:
- Per application: a browser enables DoH for itself only. Fast to turn on, but other apps on the device still use plaintext.
- Operating system stub: modern Windows, macOS, Linux (systemd-resolved), Android, and iOS can send all DNS over DoT or DoH, covering every app.
- Network resolver or router: run your own recursive resolver (Unbound, BIND, Knot Resolver) that speaks DoT or DoH upstream, so every client on the LAN is protected and you keep local filtering and logging.
Pitfalls to plan for
- Bootstrapping: you need to resolve the resolver hostname before you can use it. Configure the resolver IP directly or pin a bootstrap address.
- Captive portals: hotel and airport logins rely on intercepting DNS. Encrypted DNS can break the sign-in page until you connect, so clients usually detect portals and defer.
- Split DNS: internal corporate names will not resolve if traffic skips the internal resolver. Use DoT or DoH only for external names, or point clients at an internal resolver that forwards encrypted upstream.
- Loss of visibility: security teams that depend on DNS logs should move filtering to a resolver they control rather than fighting client-side DoH.
Verify it is actually encrypted
After enabling encrypted DNS, confirm the path rather than trusting a toggle. Query a known test name, watch that port 853 or 443 carries the traffic, and check that a plaintext capture on port 53 shows nothing.
# systemd-resolved: confirm DoT is active and strict
resolvectl status | grep -E 'DNS over TLS|Current DNS'
# Expected: +DNSOverTLS and the configured resolver IP
# Cloudflare connectivity self-check
curl -s https://1.1.1.1/help | grep -i 'using_doh\|using_dot'
Once encrypted DNS is live, keep an eye on propagation and record health whenever you change resolvers or nameservers. You can confirm that a new record is visible from resolvers around the world with the Valla DNS propagation checker, and if you want to go deeper on the pieces that work alongside encrypted transport, the Valla DNS learning hub has companion guides on DNSSEC, TTL strategy, and reading a DMARC report.