DNSCrypt vs DoH vs DoT vs DoQ

DNSCrypt or DoT, if those are your two

This pairing gets asked more than any other, and the table above spreads the answer across several rows. Short version: the choice is about deployment, not cryptography. Both encrypt the same payload to the same resolver, and neither is meaningfully weaker than the other.

Pick DoT if you want the whole device covered with nothing installed. It is an IETF standard, RFC 7858, and it is already in the operating system: Android exposes it as Private DNS, a hostname in one field, and Linux has it in systemd-resolved. There is no client to install, no configuration file, and nothing to keep updated.

Pick DNSCrypt if you need a relay, or if port 853 is blocked. It is a community protocol rather than an IETF standard, it needs dnscrypt-proxy installed and configured, and it usually rides port 443 where it is not trivially separable from ordinary web traffic. That "usually" is worth a number: of the 452 DNSCrypt entries in the signed public resolver list on this machine, 420 use port 443 and 32 do not - Quad9, the resolver measured below, is one of the 18 on 8443. DoT's fixed port 853 is the opposite: easy to spot, easy to block.

The one capability that genuinely has no DoT equivalent is Anonymized DNSCrypt, which sends each query through a relay so the resolver that answers never learns your address. That separates who is asking from what is asked. Oblivious DoH was the standardised attempt at the same split and never saw real deployment, so relays remain DNSCrypt's own territory. If that property is why you are asking, the comparison is already decided.

What each transport costs on the wire

Everything above this line is the sort of comparison you can read anywhere. This part is ours: one client, one resolver address, six transports, counting what each actually puts on the wire for a single cold lookup.

Medians of 12 cold lookups per transport, same client, same resolver address.

DNSCrypt is the cheapest encrypted option here, by about a factor of seven. Four packets and 1,052 bytes against DoT's 20 and 7,186. It has no TLS handshake to pay for: one plain DNS query fetches the resolver's certificate and the encrypted query follows. Everything built on TLS spends most of its cold cost receiving a certificate chain, roughly 5 kB of both the DoT and the DoH totals.

The two QUIC transports invert the direction. DoQ and DoH3 are the only arms where the client sends more than it receives, 7,550 and 7,812 bytes against 4,228 and 4,605. That is the protocol's own anti-amplification rule rather than anything about DNS: RFC 9000 requires a client to pad any datagram carrying an Initial packet so it is at least 1,200 bytes, and the handshake takes several. In these captures they leave as a run of 1,308-byte datagrams.

Plain Do53 is in the table as the floor, not as a recommendation: two packets and 168 bytes, nothing encrypted and nothing authenticated.

Ranges across the 12 runs: Do53 168 to 168, DNSCrypt 988 to 1,172, DoT 7,164 to 7,270, DoH 7,740 to 7,897, DoQ 11,000 to 12,689, DoH3 11,468 to 13,254. On the TCP and QUIC arms that spread is bookkeeping - how many bare acknowledgements and teardown packets fall inside the capture window - while DNSCrypt's whole spread is the size of the answer.

Run it against your own network

All six arms are one tool against a public resolver, so this reproduces anywhere. Save it as measure.sh and run it as root.

#!/usr/bin/env bash
# measure.sh - what one cold DNS lookup costs on the wire, per transport.
# One client, one resolver address, so only the transport varies.
#
#   ./measure.sh            measure and delete the captures
#   KEEP=1 ./measure.sh     keep them, and print where they are
#
# Keep them whenever a number looks wrong. The counting here is deliberately
# crude - every packet to and from the address - and the pcap is the only way
# to see what it actually counted.
set -e

for t in q tcpdump tshark ip awk; do
  command -v "$t" >/dev/null || { echo "missing tool: $t"; exit 1; }
done
[ "$(id -u)" -eq 0 ] || { echo "run as root - tcpdump needs it"; exit 1; }

KEEP="${KEEP:-0}"
D=$(mktemp -d)
cleanup() {
  if [ "$KEEP" = 1 ]; then printf '\ncaptures kept in %s\n' "$D"
  else rm -rf "$D"; fi
}
trap cleanup EXIT

# The stamp carries its own address. Change IP and you must change STAMP too,
# or the DNSCrypt arm will talk to one resolver while the capture watches another.
IP="149.112.112.112"
IF=$(ip route get "$IP" | awk '{for(i=1;i<=NF;i++) if($i=="dev") {print $(i+1); exit}}')
STAMP='sdns://AQMAAAAAAAAAFDE0OS4xMTIuMTEyLjExMjo4NDQzIGfIR7jIdYzRICRVQ751Z0bfNN8dhMALjEcDaN-CHYY-GTIuZG5zY3J5cHQtY2VydC5xdWFkOS5uZXQ'

echo "Interface $IF, resolver $IP"
echo "----------------------------------------------------------------------"

for proto in do53 dnscrypt dot doh doh3 doq; do
  case $proto in
    do53)     a=(@"$IP") ;;
    dnscrypt) a=(@"$STAMP") ;;
    dot)      a=(@tls://"$IP" --tls-server-name dns.quad9.net) ;;
    doh)      a=(@https://"$IP"/dns-query --tls-server-name dns.quad9.net) ;;
    doh3)     a=(@https://"$IP"/dns-query --http3 --tls-server-name dns.quad9.net) ;;
    doq)      a=(@quic://"$IP" --tls-server-name dns.quad9.net) ;;
  esac

  tcpdump -i "$IF" -n -s0 -w "$D/$proto.pcap" "host $IP" 2>/dev/null &
  T=$!
  sleep 0.7

  ans=$(q example.com A "${a[@]}" 2>/dev/null | head -1) || true
  sleep 1.2

  kill "$T" 2>/dev/null || true
  wait "$T" 2>/dev/null || true

  # An unanswered exchange still puts packets on the wire. Without this check a
  # failed transport prints a plausible-looking byte count.
  [ -n "$ans" ] || { printf "%-9s no answer - not counted\n" "$proto"; continue; }

  tshark -r "$D/$proto.pcap" -T fields -e ip.src -e ip.len 2>/dev/null | awk -v ip="$IP" -v p="$proto" \
    'NF==2 { pk++; by+=$2; if ($1==ip) rx+=$2; else tx+=$2 }
     END { if (pk == "") printf "%-9s answered, but nothing seen on %s - wrong address?\n", p, ip
           else printf "%-9s %2d packets %6d bytes   sent %5d   received %5d\n", p, pk, by, tx, rx }'
done

One run on this host, with KEEP=1 so the captures survive:

Interface ens1, resolver 149.112.112.112
----------------------------------------------------------------------
do53       2 packets    168 bytes   sent    68   received   100
dnscrypt   4 packets    988 bytes   sent   423   received   565
dot       21 packets   7218 bytes   sent  2241   received  4977
doh       24 packets   7740 bytes   sent  2565   received  5175
doh3      23 packets  11663 bytes   sent  7072   received  4591
doq       16 packets  11018 bytes   sent  6781   received  4237

captures kept in /tmp/tmp.5LpXThzPPz

Keep the captures whenever a number looks wrong. The counting is deliberately crude - every packet to and from the address, no attempt to tell a handshake from an answer - and the pcap is the only way to see what it actually counted. That is not a hypothetical: an earlier pass here read a server's certificate, split across two TCP segments, as though it were a DNS answer, and the only reason we noticed was that the number looked too tidy.

Two of those checks exist because the measurement lied to us first. An unanswered exchange still puts packets on the wire, so a transport that fails will happily print a plausible byte count - pointed at an address that answers nothing, an early version of this script reported do53 1 packets 68 bytes and dot 7 packets 420 bytes and exited cleanly. And a query can succeed while the capture sees nothing, because the client used a different address than the filter watched. Both now say so instead of printing a number.

A single run of anything is an anecdote, so treat one pass as a shape rather than a number. Expect the TCP and QUIC arms to move by a few hundred bytes between runs and the two UDP arms to sit almost still. Point IP at any resolver that answers more than one protocol and the comparison holds - but change the stamp with it, or the DNSCrypt arm will keep talking to Quad9 while everything else moves.