DNS over TLS and DNS over HTTPS

Introduction¶

Classic DNS (UDP/53) is plaintext: anyone on the path sees every domain you look up, and can tamper with answers (DNSSEC signs records but most clients don't validate, and it doesn't hide the query). DoT and DoH encrypt the client-to-resolver hop.

DoT — DNS over TLS¶

• Port 853, a dedicated TLS wrapper around normal DNS wire format.
• Easy to identify on the network (it's on its own port) — an operator can block it or see that DoT is in use, just not the contents.
• Standardised (RFC 7858), supported by systemd-resolved, unbound, stubby, Android ("Private DNS").

# systemd-resolved
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes

The #hostname is the TLS SNI/cert name to validate against.

DoH — DNS over HTTPS¶

• Port 443, queries as HTTP requests (GET/POST to a /dns-query endpoint), often over HTTP/2.
• Indistinguishable from other HTTPS traffic — can't be selectively blocked without breaking the web, can't be observed by the network.
• Built into browsers (Firefox, Chrome) which can use DoH independently of the OS resolver — a point of contention for enterprises.

https://cloudflare-dns.com/dns-query
https://dns.google/dns-query

DoT vs DoH — the trade-off¶

For privacy from the local network / ISP, DoH is stronger (unblockable, unobservable). For an organisation that needs DNS visibility (security filtering, split-horizon, logging), DoT to your resolver — and blocking external DoH — keeps control.

A practical setup: local resolver, encrypted upstream¶

Run unbound on the LAN; it serves plain DNS to internal clients (so you keep visibility and local zones) and uses DoT upstream so queries leave the building encrypted:

# unbound.conf
server:
    interface: 10.0.0.53
    access-control: 10.0.0.0/8 allow
    # ... local zones, DNSSEC validation ...

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 9.9.9.9@853#dns.quad9.net

Clients get fast local caching + local names; the upstream hop is private.

DNSSEC vs encrypted transport¶

They solve different problems:

• DNSSEC — cryptographic authentication of records (this A record really came from the zone owner). Doesn't encrypt; anyone still sees the query.
• DoT/DoH — confidentiality and integrity of the client↔resolver channel. Doesn't prove the resolver isn't lying.

Best is both: DoT/DoH to a validating resolver.

Verification and troubleshooting¶

# Test DoT
kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
# Test DoH
curl -sH 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq

resolvectl status | grep -i "DNS over TLS"

• DoT set but resolution fails — port 853 blocked (some networks do), cert hostname mismatch (#hostname wrong), or the resolver doesn't actually support DoT. DNSOverTLS=opportunistic falls back to plaintext (weaker); yes is strict.
• Browser DoH ignoring corporate DNS / split-horizon broken — the browser enabled DoH on its own. Enterprises publish the "canary domain" use-application-dns.net as NXDOMAIN to signal browsers to disable DoH, and/or block known DoH endpoints, and/or push policy (GPO / MDM).
• Slower than plain DNS — TLS handshake per connection. Resolvers keep the connection open (RFC 7858 idle timeout); a resolver that reconnects per query is misconfigured.
• DoH over HTTP/1.1 is slow — no multiplexing; one query blocks the connection. Use an HTTP/2 endpoint.
• Can't tell if it's actually encrypted — tcpdump port 53 should show nothing for your lookups if DoT/DoH is working; traffic is on 853/443.

Related tools and reading¶

• On-site: DNS lookup, DNSSEC checker.
• Related posts: DNS resolution, step by step, resolv.conf and systemd-resolved.