Technical Specification

Encrypted DNS Protocols

Deep dive into the architecture of modern encrypted DNS. Understanding the performance characteristics, security models, and implementation differences.

Protocol Comparison

Benchmarking Speed, Privacy, and Reliability

The Problem: Legacy DNS (Do53)

Classic DNS from 1983 sends every lookup in plaintext on port 53. Anyone on the path between you and the resolver - your ISP, a public Wi-Fi operator, a network filter - can see every domain you look up, log it, or change the answer it returns.

Every protocol below fixes this the same way: wrapping DNS in an encrypted, authenticated tunnel. They differ only in which tunnel - and that changes speed, stealth, and compatibility.

// what your ISP sees with plain DNS
14:02:11 lookup: example.com
14:02:13 lookup: news.example
14:02:19 lookup: video.example
- readable, loggable, modifiable -
// with encrypted DNS (DoH / DoT / DoQ)
14:02:11 TLS 1.3 → dnsdoh.art ████████████

DoH

RFC 8484
Stealth (Privacy)High
Connection SpeedMedium

Port 443: Blends with web traffic. Hardest to block.

Best for: Desktops, browsers, restricted networks

DoT

RFC 7858
Stealth (Privacy)Low
Connection SpeedMedium

Port 853: Dedicated port. Easily blocked by firewalls.

Best for: Android phones, routers

DoQ

RFC 9250
Stealth (Privacy)Medium
Connection SpeedUltra

QUIC/UDP: 0-RTT handshake. Solves packet loss lag.

Best for: Phones on the move, modern DNS apps

DoH3

RFC 9114
Stealth (Privacy)High
Connection SpeedUltra

QUIC on 443: DoH cover with parallel streams.

Best for: Desktops & phones on modern browsers/apps

What encrypted DNS does not hide

  • The IP addresses you connect to are still visible to your ISP.
  • The TLS handshake (SNI) can still reveal hostnames until ECH becomes universal.
  • It is not a VPN - your traffic itself is unchanged; only the lookups become private.

Encrypted DNS removes the easiest, most-abused surveillance channel - it doesn't make you invisible. Honest tools, honest limits.

Encryption ≠ DNSSEC

Two different problems, best solved together:

  • DoH / DoT / DoQ hide your queries in transit - privacy.
  • DNSSEC cryptographically proves the answer wasn't forged - authenticity.

Our resolver validates DNSSEC for you on every query - see the infrastructure page.

Which one should you use?

Phone / Tablet

Android: Private DNS (DoT) - built-in, one field, system-wide. iPhone: our signed profile (DoH).

Restricted Network

DoH or HTTP/3 on port 443 - indistinguishable from normal web traffic, hardest to block.

Lowest Latency

DoQ or DoH3 - QUIC transport, 0-RTT reconnects, survives Wi-Fi ↔ 5G switching.

Whole Household

DoH/DoT on the router - covers TVs, consoles, and IoT devices in one step.

DNS over HTTPS

RFC 8484 • Port 443

DoH encapsulates DNS queries within standard HTTPS (HTTP/2) traffic. Because it uses Port 443 (the same as all web traffic), DoH is hard to block without also blocking ordinary HTTPS.

Why we use it

It works through most firewalls and ISP filtering because it is indistinguishable from normal HTTPS. Chrome and Firefox support it directly.

Wire Format (HTTP/2) GET / POST
:method = POST
:scheme = https
:path = /dns-query
accept: application/dns-message
content-type: application/dns-message
content-length: 56
<Binary DNS Packet>

Strengths

  • +Indistinguishable from regular HTTPS - works through almost any firewall, hotel Wi-Fi, or national filter.
  • +Broadest client support of any encrypted DNS: every major browser, Windows 11, Apple profiles, ChromeOS.
  • +Rides the HTTP ecosystem: HTTP/2 multiplexing, connection reuse, and a free upgrade path to HTTP/3.

Weaknesses

  • Heaviest of the three: HTTP headers add overhead to every query compared to raw DoT or DoQ.
  • Runs on TCP (with HTTP/2), so one lost packet can stall parallel queries - fully solved only by HTTP/3.
  • Browser defaults funnel users to a few giant providers - DoH centralizes the DNS unless you choose an independent resolver.

Good to know: RFC 8484 (2018) defines two wire forms - POST with a binary DNS body, and GET ?dns= with base64url encoding. We accept both. Queries can also be padded (RFC 8467) so that packet size reveals nothing about which domain you looked up.

One honest caveat: DoH shifts trust from your ISP to your resolver - whoever runs it can see the queries. That is exactly why we publish a strict no-logs privacy policy.

Connection Flow TLS 1.3
TCP Handshake (SYN/ACK)
TLS Client Hello
Encrypted Tunnel Established
[Length] [DNS Query]

DNS over TLS

RFC 7858 • Port 853

DoT is the "purest" encrypted DNS protocol. It strips away the HTTP overhead and wraps standard DNS packets directly in a TLS tunnel over TCP. This makes it slightly more bandwidth-efficient than DoH.

Built for OS

It is the native standard for Android ("Private DNS") - one hostname field, no app. Apple devices support it via configuration profiles. It maintains a persistent connection to reduce latency.

Strengths

  • +Leanest TLS-based option: no HTTP layer, just a 2-byte length prefix per query - minimal overhead.
  • +The oldest standard (2016) means the most mature support: Android 9+, systemd-resolved, and most router firmware.
  • +Persistent connections with TLS 1.3 session resumption keep repeat-query latency very low.

Weaknesses

  • The dedicated port 853 announces "this is DNS" - strict firewalls and some ISPs block it with one rule.
  • TCP transport means head-of-line blocking: one lost packet delays every query behind it.
  • No browser supports it - DoT is an operating-system and router protocol.

Good to know: RFC 7858 defines two security profiles - opportunistic (encrypt if possible, fall back silently) and strict (authenticate or fail). Android's Private DNS hostname mode is strict: it validates our TLS certificate against dnsdoh.art before sending a single query, so it can't be silently downgraded.

Trade-off to know: the dedicated port 853 makes DoT easy for strict firewalls to block. On a restricted network, switch to - it hides on port 443. More edge cases in the knowledge base.

DNS over QUIC

RFC 9250 • UDP

DoQ solves the "Head-of-Line Blocking" problem. By using QUIC (over UDP) instead of TCP, it allows multiple queries to be resolved in parallel without waiting for lost packets to be retransmitted.

0-RTT Faster connection setup than TCP+TLS.
Roaming Survives switching from WiFi to 5G.
QUIC Stream Stream ID: 4
// No TCP Handshake
Query A: google.com -> Sent
Query B: youtube.com -> Sent
Query A: [Lost Packet] Ignored
Query B: Result Processed!
* Query B not blocked by A's loss

Strengths

  • +Every query gets its own QUIC stream - a lost packet never delays the other queries in flight.
  • +0-RTT session resumption: reconnecting to a known resolver costs almost nothing.
  • +Connection migration - the session survives switching from Wi-Fi to 5G without renegotiating.

Weaknesses

  • No operating system supports it natively yet - you need a DoQ-capable DNS client.
  • UDP on port 853 is throttled or dropped by some middleboxes and corporate networks.
  • Youngest standard (2022) - the smallest ecosystem of clients and resolvers so far.

Good to know: to keep 0-RTT safe from replay attacks, RFC 9250 only allows queries that are harmless to repeat in early data - your client enforces this automatically. Early experimental deployments used port 784 before 853/UDP became the official assignment.

Note: no mobile OS speaks DoQ natively yet - Android's built-in Private DNS uses DoT instead, which is already fully encrypted. DoQ is for enthusiasts squeezing out the last milliseconds.

HTTP/3 DNS

RFC 9114 • Port 443 UDP

We support h3 on our DoH endpoint. It is still "DNS over HTTPS", but it swaps the underlying TCP transport for QUIC: the port-443 cover of DoH with the parallel streams of DoQ.

The hybrid of DoH and DoQ

It looks like ordinary web traffic on port 443, yet each query rides its own QUIC stream, so one lost packet never stalls the others. Clients that already speak DoH upgrade themselves the moment they see our Alt-Svc header.

Transport HTTP/2 vs HTTP/3
TCP · HTTP/2
Q1done
Q2lost
Q3blocked
Q4blocked
QUIC · HTTP/3
Q1done
Q2lost
Q3done
Q4done

One lost packet on TCP stalls every query queued behind it - "head-of-line blocking". On QUIC each query is its own stream, so only the lost one waits.

Strengths

  • +DoQ-class speed with DoH-class stealth: QUIC on UDP 443 looks like any modern website or video stream.
  • +Immune to TCP head-of-line blocking - parallel queries never wait on each other's lost packets.
  • +Fully automatic: clients that already speak DoH upgrade themselves when they see our Alt-Svc header.

Weaknesses

  • Some corporate networks drop UDP on 443 - clients then silently fall back to HTTP/2 (still encrypted, just slower).
  • The first connection still starts over HTTP/2 before the upgrade kicks in, unless the client remembers us.

Good to know: no new DNS standard was needed for this - RFC 8484 is transport-agnostic, and HTTP/3 (RFC 9114, 2022) slots in underneath. The emerging DDR standard (RFC 9462) goes further: it lets devices ask a resolver "do you support encryption?" and upgrade automatically, no configuration at all.