DoH, DoT, DoQ, DNSCrypt: which encrypted DNS should you actually run?

Plain DNS on UDP port 53 is the last great unencrypted protocol on the modern internet. Every lookup your network makes — every domain, on every device — travels in clear text past your ISP, your transit providers, and anyone with a tap on the wire. Encrypting it is no longer exotic: four protocols now do it in production, and a resolver like UnveilDNS speaks all of them at once. The question is which one your clients should connect with.

This is the field guide we wish existed when we wired up our own endpoints. Same goal — confidentiality and integrity for DNS — but four very different trade-offs.

The four protocols at a glance

Note that DoT and DoQ share port 853 without conflict: one is TCP, the other UDP, so the kernel routes them on transport alone. DNSCrypt predates the IETF standards and is the only one of the four that never went through the RFC process — it uses its own certificate and stamp format instead of X.509.

DoT — the clean, honest option

DNS over TLS is just DNS wrapped in a TLS session on its own port. It is the easiest to reason about: a resolver opens a long-lived TLS connection to tls://your-server:853, and every query rides inside it. The encryption story is identical to HTTPS, the handshake is standard TLS 1.2/1.3, and the dedicated port makes it trivial to monitor and audit on your own network.

That dedicated port is also its weakness. Port 853 is unmistakably "encrypted DNS," so a censoring middlebox can block it with a single firewall rule and never touch anything else. On a hostile network DoT is the first casualty.

Rule of thumb: DoT is the right default on networks you control — a branch office, a home, a managed fleet — where nobody is trying to stop you from doing encrypted DNS.

DoH — the one that hides

DNS over HTTPS pushes queries inside ordinary HTTPS requests on port 443. To a network observer it is indistinguishable from any other web traffic: same port, same TLS, same ALPN. You cannot block DoH without blocking the web. That is exactly why browsers adopted it, and exactly why network administrators have a complicated relationship with it.

The cost is overhead and ambiguity. Every query carries HTTP framing, and because it looks like web traffic, a device can quietly bypass your local resolver entirely by talking to a public DoH endpoint. UnveilDNS proxies its own DoH on 443 through the web console, so you get the censorship-resistance without surrendering visibility — the queries still terminate on your resolver, your filters, your logs.

DoQ — DoT's faster successor

DNS over QUIC is the newest of the four (RFC 9250, 2022). QUIC is the UDP-based transport that also underpins HTTP/3: it folds the TLS 1.3 handshake into the transport, eliminates head-of-line blocking, and survives network changes (Wi-Fi → cellular) without re-handshaking. For DNS that means lower latency than DoT and graceful behaviour on flaky links — which is precisely where it earns its keep.

On high-RTT or lossy paths — think a satellite backhaul or a long international route — QUIC's 0-RTT resumption and loss recovery noticeably beat TCP-based DoT. The catch is maturity: QUIC is UDP, and some middleboxes still throttle or drop sustained UDP flows. Treat DoQ as the performance option for clients that support it, not the universal default.

DNSCrypt — the pre-standard veteran

DNSCrypt v2 predates DoT/DoH and solves the same problem with a different toolkit: an Ed25519 provider certificate signs short-lived Curve25519 keys that encrypt each query (XSalsa20-Poly1305 in the most compatible mode). Clients don't configure a hostname and port — they paste a single DNS stamp, a base64url blob that packs the server address, public key and provider name into one string:

sdns://AQcAAAAAAAAA…  (server address · public key · provider name)

The stamp is self-contained: there is no separate trust store to manage, and the embedded key pins the server, so there is nothing for a CA compromise to undermine. DNSCrypt remains popular with privacy-focused clients and is the protocol of choice when you want key-pinned DNS without depending on the public PKI. UnveilDNS generates the keys and the stamp for you on the Encryption settings page.

What encryption does — and does not — buy you

All four protocols protect the same thing: the link between the client and the resolver. They stop your ISP and on-path observers from reading or tampering with your lookups. They do not hide your queries from the resolver itself (it has to answer them), and they do nothing for the upstream hop unless that hop is also encrypted.

That last point matters. Encrypting the client side while your resolver forwards to upstreams in clear text just moves the leak one hop further. UnveilDNS keeps the upstream hop encrypted too, so the chain stays encrypted from the device all the way to the public resolver — not just to your box.

What we recommend

• Managed networks you control: DoT (853) as the baseline — simple, auditable, blockable only by you.
• Roaming devices / hostile networks: DoH (443) so encrypted DNS can't be singled out and blocked.
• Latency-sensitive or lossy links: DoQ (853/UDP) where the client supports it.
• Privacy maximalists / key pinning: DNSCrypt (5443) with a stamp.

You don't actually have to choose just one. A UnveilDNS box listens on all of them simultaneously — plain 53 for legacy clients, DoT and DoQ on 853, DoH proxied on 443, DNSCrypt on 5443 — so each device connects with whatever it supports best, and they all land on the same filtering, logging and threat-detection pipeline behind the encryption.