Privacy & encryption

Encrypting DNS protects a hop, not the entire naming system

DoT, DoH and DoQ can stop a local network observer from reading or modifying traffic between a client and its selected resolver. The resolver still sees the question, and authoritative servers still participate in resolution.

Comparison of classic DNS, DNS over TLS, DNS over HTTPS and DNS over QUIC transports
TransportTypical portEncapsulationOperational character
Classic DNS53/UDP and 53/TCPDNS directly over UDP or TCPSimple and widely interoperable; no transport confidentiality.
DoT853/TCPDNS over TLSDedicated, identifiable encrypted DNS channel.
DoH443/TCP or QUICDNS messages carried by HTTPSIntegrates with web infrastructure and is harder to distinguish from other HTTPS traffic.
DoQ853/UDPDNS over a dedicated QUIC connectionEncrypted streams without TCP head-of-line blocking.

Threat model

Ask which observer you are defending against

Encrypted DNS can hide queries from a Wi-Fi operator, access provider or hostile device on the path to the resolver. It can also authenticate the resolver endpoint when certificate validation is correctly configured.

It does not stop the chosen resolver from logging queries. It does not prevent destination IP addresses, TLS handshakes or subsequent application traffic from revealing useful metadata. It also does not make unsigned DNS data authentic.

Local-path observer

Protected by encrypted DNS

Cannot directly read query names on that encrypted hop.

Chosen resolver

Still trusted

Receives the full client query and can apply policy or retain logs.

Authoritative operator

Partially exposed

Sees queries from resolvers; QNAME minimisation reduces unnecessary detail sent to intermediate authorities.

Application destination

Separate channel

Sees the actual connection and may infer the name through application protocols.

QNAME minimisation

Reveal only the label needed at each delegation step

Without minimisation, a cold-cache resolver might send the complete name private-service.department.example.com to the root and TLD servers, even though they only need to provide referrals.

Root seescom. NS?
com seesexample.com. NS?
Authoritative seesprivate-service.department.example.com. A?

Minimisation reduces data disclosure across the hierarchy. It complements encrypted client-to-resolver transport; neither replaces the other.

DNSSEC versus encrypted DNS

Different mechanisms answer different questions

DNSSEC

Authenticates signed DNS data and detects modification.

Does not encrypt

DoT / DoH / DoQ

Encrypt and authenticate a transport connection to a resolver.

Do not sign zone data
Use bothwhen authenticity and transport privacy matter

Resolver choice

Encryption shifts trust; it does not eliminate it

A network-designated resolver can provide local names, filtering and policy consistency. A public resolver can bypass local interference and offer broad anycast reach. A self-operated recursive resolver reduces dependence on a single external recursive provider but still talks to the public authoritative hierarchy.

The correct choice depends on the threat model, local service needs, jurisdiction, logging policy, failure tolerance and who should control filtering.

Local encrypted resolver

Strong control and local policy, with operational responsibility retained by the network owner.

Public encrypted resolver

Simple deployment and large-scale infrastructure, with query visibility concentrated at the provider.

Full recursion

Distributes queries across authorities and avoids forwarding every lookup to one recursive provider.