Encrypted DNS Explained: DNSCrypt, DoH and DoT Compared on Ports, Trust and Blocking

Hop 01

What encrypted DNS protects, and what it leaves visible

RFC 9076, the IETF’s survey of DNS privacy, makes the point plainly: an HTTPS connection to a site is encrypted, yet the DNS exchange that came before it is not. It also notes that the best place to tap is between your device and the recursive resolver, because nothing there is hidden behind a cache.

Encryption closes that gap for the lookup itself, and it also stops an attacker on the path from injecting a forged answer. It does not make you anonymous. The resolver you pick still sees every name, the network still sees the IP addresses you connect to, and the TLS Server Name Indication can still reveal the site.

Hop 02

DNSCrypt, DoH and DoT: three protocols, three designs

All three protocols solve the same problem with different building blocks. DNSCrypt is a purpose-built DNS protocol, DNS-over-TLS puts classic DNS messages inside a TLS session, and DNS-over-HTTPS carries them as ordinary web requests. The table below sums up the differences that matter in practice; the interactive comparison adds DoQ, ODoH and Anonymized DNSCrypt.

	DNSCrypt v2	DNS-over-HTTPS (DoH)	DNS-over-TLS (DoT)
Specification	dnscrypt.info protocol document	RFC 8484	RFC 7858
Transport	UDP and TCP	HTTPS (HTTP/2, HTTP/3)	TCP with TLS
Default port	443 (UDP and TCP)	443	853
Server authentication	Ed25519-signed certificates, provider public key from a DNS stamp	TLS certificate of the resolver hostname	TLS certificate of the resolver hostname
Encryption	X25519-XChaCha20Poly1305	TLS	TLS
Visible to the network	Encrypted packets on port 443, no SNI	TLS to port 443, SNI names the resolver	TLS to a dedicated port
Built into operating systems	No, needs a client such as dnscrypt-proxy	Windows 11, Apple platforms	Android 9 and later, Apple platforms, Windows 11 DNS client

DNSCrypt v2

The DNSCrypt v2 specification runs over UDP and TCP, with a default port of 443 for both. Queries and responses are encrypted with X25519-XChaCha20Poly1305, and responses are padded to a multiple of 64 bytes so that their length gives away less. Resolvers rotate their short-term keys at least every 24 hours.

DNS-over-HTTPS

RFC 8484 maps each query and response onto one HTTP exchange, so a DoH lookup looks like any other request to an HTTPS server on port 443. The DNSCrypt FAQ notes that it runs over standard HTTP/2 or HTTP/3. The DNS-over-HTTPS guide covers URL templates, resolver endpoints and how browsers and operating systems decide when to use it.

DNS-over-TLS

RFC 7858, published in May 2016, has the client open a TLS session to TCP port 853 and send ordinary DNS messages through it. Because the payload is unchanged DNS, existing resolvers only need a TLS layer in front of them, and Android uses it for Private DNS. The DNS-over-TLS page explains its strict and opportunistic modes.

A fourth protocol is worth knowing about, even if it is the newest. RFC 9250 defines DNS over Dedicated QUIC Connections, usually shortened to DoQ, which runs on UDP port 853 and avoids the head-of-line blocking that TCP brings. AdGuard DNS publishes quic:// endpoints for its servers; the DNS-over-QUIC page tracks other resolvers and clients.

Hop 03

Authentication in DNSCrypt and DoH: who vouches for the resolver

Encryption alone is not enough if you might be talking to the wrong server. DoH and DoT lean on the TLS certificate system: the resolver proves it owns a hostname such as dns.quad9.net. RFC 8310 defines a Strict Privacy profile that refuses to resolve without that proof, and an Opportunistic one that tries and falls back.

DNSCrypt skips certificate authorities entirely. The client receives a provider public key in advance, usually inside a DNS stamp, and accepts only short-term certificates signed with that key using Ed25519. Nobody else can mint a valid certificate for that resolver, which is the main reason the project argues that standard TLS interception boxes cannot read its traffic.

Hop 04

Blocking DNS traffic: why the port decides on hostile networks

How easily a network can spot and block secure DNS depends mostly on what the packets look like. A dedicated port is easy to filter, and a recognisable hostname in the handshake is easy to match. The DNSCrypt FAQ argues that DoT on port 853 is trivially blocked exactly where encryption is most needed.

The same FAQ concedes that DoH on port 443 is harder to block, but notes that SNI still names the resolver. DNSCrypt sends no SNI and no HTTP headers, and regular DNS can share its port. These are the project’s own arguments; the port facts come from the specifications. The DNS port guide lists firewall rules for each.

Hop 05

Operating system support for secure dns

Native support is uneven. Windows 11 offers DNS over HTTPS under Settings, Network and internet, in the IP assignment editor, with an optional Fallback to plaintext switch; Microsoft notes the setting is missing on Windows 10. Android 9 and later expose DNS-over-TLS as Private DNS, where you type a hostname such as dns.quad9.net.

Apple’s WWDC20 session on encrypted DNS describes two system-wide routes on its platforms: an app built on NEDNSSettingsManager, or a configuration profile containing a DNSSettings payload, each pointing at a DoH or DoT server. DNSCrypt has no native support anywhere, so it always runs through a client such as dnscrypt-proxy, which listens locally and serves every application.

That client matters for another reason. Its README lists DNSCrypt v2, DoH, Anonymized DNSCrypt and Oblivious DoH, but not DoT, so a single dnscrypt-proxy install can mix DNSCrypt and DoH resolvers and pick the fastest. Secure dns at the operating system level covers one protocol at a time, and only where the vendor built it in.

Hop 06

Choosing encrypted DNS for your setup

For one phone, the built-in option is usually enough: Private DNS on Android, a profile on iPhone. On a laptop that moves between untrusted networks, a local dnscrypt-proxy gives you DNSCrypt on port 443, filtering and a query log in one place, and it keeps all dns traffic from every application inside one encrypted channel.

On a home router, encrypting there protects devices with no setting of their own, such as televisions. Whichever route you take, check the result afterwards: stop the client briefly and see whether names still resolve, or watch for packets leaving on port 53. Plain dns traffic on that port means something is bypassing it.