DNS Security and Privacy: DNSSEC, DoH, and DoT

Plaintext DNS over UDP/53 (RFC 1035) is both spoofable and visible to every on-path observer. Two distinct defences exist: DNSSEC (RFC 4033–4035) gives responses cryptographic authenticity through a chain of trust rooted at the IANA-managed root zone, and DoH (RFC 8484) / DoT (RFC 7858) / DoQ (RFC 9250) give the stub-to-recursive hop confidentiality. They are independent — a zone can be DNSSEC-signed but reached over plaintext, and DoH happily transports unsigned answers — and reaching the full privacy posture also requires Encrypted ClientHello (RFC 9849) on the subsequent TLS connection.

This article is the security entry in the DNS series — see also DNS Resolution Path, DNS Records, TTL, and Caching, and the DNS Troubleshooting Playbook for adjacent ground.

Mental model

DNS security splits cleanly along two axes; conflating them is the most common reasoning mistake.

A useful analogy: DNSSEC is a notarised letter (anyone reads it, but you can verify the sender); DoH/DoT/DoQ is a sealed envelope (the carrier sees only the address); ECH closes the last gap by encrypting the recipient name on the TLS envelope as well.

DNSSEC: cryptographic authentication

Chain of trust

DNSSEC signs every RRset (resource-record set) inside a zone and ties zones together with hashes published in the parent. The validator anchors at one pre-configured key — the root KSK — and walks down ¹.

A signed zone publishes three record types beyond the regular A/AAAA/MX:

The root KSK is the only key that must be trusted out-of-band — every other public key is reached via a DS published by its parent. Validating resolvers refresh the trust anchor via RFC 5011 so a planned KSK rollover does not require manual reconfiguration.

Key types: KSK and ZSK

Splitting the role lets the ZSK rotate often — limiting exposure if it leaks — without dragging the parent registrar into every change. The KSK signs only the DNSKEY RRset, so it can sit in an HSM or offline ceremony and roll on a multi-year cadence. RFC 7583 covers the timing constraints: during a rollover both keys must be visible long enough for every cache to see them, and signature validity must overlap so resolvers with either key still validate.

Algorithms

RFC 8624 is the current algorithm matrix. Pick by validator support, not by what the signer can produce:

The pragmatic default for a modern signer is ECDSA P-256: the matrix marks it MUST for both signing and validation, and ECDSA’s ~64-byte signatures cut response sizes 3–4× versus RSA-2048, reducing UDP truncation and TCP fallback. ED25519 is preferable on paper but surveys still report meaningful pockets of validators that fall back to “insecure” rather than validating it ³; if a tier-1 audience is involved, prefer ECDSA P-256 for deployment compatibility and treat ED25519 as the next step.

Authenticated denial: NSEC vs NSEC3

When a name does not exist, a signed zone must still prove it does not exist — otherwise an attacker could forge NXDOMAIN and break a query without leaving a trace.

NSEC (RFC 4034) returns the canonically adjacent existing names:

1alpha.example.com.    NSEC    beta.example.com. A AAAA RRSIG NSEC

A “no name exists between alpha and beta” proof. Replay it for every gap and you trivially walk the zone — every hostname becomes public.

NSEC3 (RFC 5155) hashes names with SHA-1 plus a salt and (optionally) iterations extra rounds, ordering on the hash:

11AVVQN7M7RBL98TR3NBLTI3BNDQR0OQU.example.com.   NSEC3   J8DF92KL9PORK10VC...

You now have to reverse the hash to walk the zone — feasible for short labels with rainbow tables, much harder for high-entropy names.

Modern validators enforce a hard ceiling regardless of zone configuration:

If you operate a signed zone, run dnssec-policy (BIND) or your signer’s equivalent with iterations: 0 and an empty salt today — older guidance to “use a high iteration count” is wrong and actively dangerous. APNIC’s measurements show many zones still drift; treat compliance as a recurring audit item.

Validation behaviour and Extended DNS Errors

When validation fails, the resolver returns SERVFAIL. That is the same code as a network timeout, an unreachable authoritative, and a dozen other failures, which is why DNSSEC outages historically looked invisible from the client side. RFC 8914 added the Extended DNS Errors (EDE) option to disambiguate; the codes most relevant here:

dig (BIND 9.18+) and kdig print EDE codes inline; expose them in your monitoring so an expiring signature surfaces as code 7 rather than as a generic SERVFAIL. The AD flag is the positive counterpart — set on a successful chain validation, useful for stub resolvers that trust their recursive operator. Setting CD (“Checking Disabled”) on a query asks the resolver to skip validation; in practice, comparing dig name and dig name +cd is the fastest way to isolate a DNSSEC-only failure.

Adoption and operational reality

DNSSEC adoption splits sharply between validation (resolvers asking for signatures) and signing (zones publishing them). APNIC Labs measurements (April 2026) put global validation at ~36% of users behind a fully validating resolver; Europe is materially higher at ~46%, with national outliers like Sweden (~86%) and the Netherlands (~76%). Zone signing trails badly: the last public APNIC measurement of .com put it near 4–5% ⁶.

Where adoption is high, it correlates with explicit incentives. SIDN, the .nl registry, integrated DNSSEC into a “Registrar Scorecard” that ties qualification for various commercial benefits to securing customer domains — and .nl signing now sits near 60% ⁷. Sweden’s .se registry runs an analogous program. TLDs without such incentives stagnate, because the operational cost (key management, signature monitoring, rollover planning) is borne by the zone operator while the benefit (a slightly more honest answer when a resolver bothers to validate) is invisible to end users.

Provisioning automation: CDS, CDNSKEY, and CSYNC

KSK rollovers used to require an out-of-band ticket to the registrar to update the parent’s DS record — exactly the kind of manual step that breeds expired-signature outages. RFC 7344 (elevated to Standards Track by RFC 8078) defines two child-side records that flip the polarity:

RFC 8078 also specifies the bootstrap case (parent polls a brand-new signed child and accepts the first DS after a publication-stability window — typical policies require 72 hours of consistency from multiple vantage points). .ch, .li, .nl, .se, and Cloudflare-managed zones consume CDS automatically ⁸; .com does not as of early 2026, which is the practical reason large .com operators still own a registrar API integration. Pair CDS/CDNSKEY with RFC 7477 CSYNC to also keep parental NS / glue in sync.

Complementary defence: DNS cookies

Encrypted transport is the heavyweight answer; DNS cookies (RFC 7873), updated by RFC 9018, are the lightweight one. Each side echoes a 64-bit pseudorandom token, so an off-path attacker has to guess the cookie before they can poison a cache or spoof a response — comparable to the protection a 32-bit TCP sequence number gives. Cookies are cheap (one EDNS option, no key material) and supported in BIND, Unbound, Knot, and PowerDNS, but they buy nothing against an on-path attacker who can read the cookie in flight, and they are not a substitute for DNSSEC’s response authenticity. Treat them as the last cleartext-DNS hardening before the recursive-to-authoritative hop you cannot easily encrypt.

DoH — DNS over HTTPS

DoH (RFC 8484) wraps DNS messages in HTTP/2 (or HTTP/3) on port 443. The wire format is unchanged binary DNS; the framing is HTTP. Two encodings:

1GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.12Host: cloudflare-dns.com3Accept: application/dns-message

1POST /dns-query HTTP/1.12Host: cloudflare-dns.com3Content-Type: application/dns-message4Content-Length: 3256[binary DNS query]

A non-standard JSON encoding (application/dns-json) is offered by Google and Cloudflare for browser/SDK convenience ⁹ but is not part of RFC 8484; do not depend on it for anything beyond demos.

HTTP semantics that matter for DNS:

• Cache layering. The effective TTL is the minimum of the DNS TTL and the HTTP Cache-Control window. RFC 8484 explicitly recommends that clients send DNS ID 0 so HTTP caches can reuse responses across requests for the same name.
• Method choice. GET enables HTTP intermediate caches to share results; POST avoids URL-bound caching for queries you would rather not log. The query name is still visible in the HTTP request itself either way.
• Connection reuse. A single HTTP/2 stream pools many outstanding queries on one TCP+TLS connection, amortising the handshake — important because DoH adds at minimum 1-RTT versus UDP DNS.

Browser behaviour

Browsers ship two distinct DoH strategies, and the difference matters operationally.

The canary domain use-application-dns.net is Mozilla’s signal: if a recursive returns NXDOMAIN for it, Firefox disables automatic DoH on that network — the conventional way for an enterprise to prevent surprise off-network DNS. It only blocks the automatic path; a user who manually configures DoH bypasses it.

Chrome’s auto-upgrade preserves split-horizon DNS and corporate logging — at the cost of leaving the existing resolver as your privacy posture. Firefox’s default-to-Cloudflare gives a stronger privacy posture against the local ISP but hands all queries to one operator and breaks any internal resolution that depended on the original DNS server.

Privacy reality check

DoH gives confidentiality between client and resolver, not unconditional privacy:

• The resolver still sees every query. Centralising DNS at Cloudflare/Google/Quad9 just changes who that operator is.
• The IP destination still leaks. Once DNS resolves, the client connects to a target IP that is visible to every on-path observer.
• TLS SNI still leaks the hostname until ECH is deployed (see the ECH section).
• Traffic-analysis fingerprints DoH itself. The resolver IP and TLS handshake pattern identify DoH usage; in censorship contexts that is sometimes enough.

Oblivious DoH (RFC 9230)

ODoH inserts a privacy proxy between client and resolver so neither party holds both pieces of information:

The query is encrypted to the target’s HPKE public key (fetched out-of-band over HTTPS), wrapped in an HTTP request to the proxy, and forwarded. The proxy never sees the plaintext query; the target never sees the client IP. Cloudflare runs odoh.cloudflare-dns.com and Apple’s iCloud Private Relay uses ODoH (with HPKE) for DNS resolution, distributing traffic across multiple partner resolvers including Cloudflare, Akamai, and Fastly ¹².

ODoH costs an extra hop in latency and assumes the proxy and target are operated by genuinely independent parties — collusion (or a single legal jurisdiction compelling both) reverses the privacy property.

DoT — DNS over TLS

DoT (RFC 7858) is the simpler relative: TLS on a dedicated port (853), then DNS messages prefixed with a 2-byte length field. There is no HTTP layer; framing is essentially “DNS over TCP, but encrypted”. RFC 7858 deliberately mandates port 853 and prohibits cleartext DNS on it, so the port itself becomes a policy lever — operators can allow or block DoT independently of HTTPS.

RFC 8310 defines two security profiles:

• Opportunistic privacy: Try DoT, fall back to cleartext DNS if 853 is blocked or the TLS handshake fails. Defends against passive attackers; trivially defeated by an active downgrade.
• Strict privacy: Require an authenticated DoT connection (typically via DNS-based pin or hostname verification). No fallback — DNS fails closed.

Most managed environments (Android 9+ “Private DNS” being the largest deployment) use strict mode with a configured hostname.

DoH vs DoT trade-off

The choice often follows the threat model: a corporate environment that wants visibility-with-encryption prefers DoT; a user trying to circumvent censorship prefers DoH (or DoQ) precisely because it is harder to single out.

DoQ — DNS over QUIC

RFC 9250 (May 2022, Standards Track) runs DNS over QUIC on UDP port 853 — same number as DoT, different protocol. The properties carry over from QUIC itself (RFC 9000):

• Combined transport + crypto handshake: 1-RTT new connections, 0-RTT for resumed sessions.
• No head-of-line blocking: independent QUIC streams, so a lost UDP datagram delays only the affected query.
• Connection migration: the QUIC connection ID survives an IP change (Wi-Fi to cellular).

The IMC 2022 measurement paper “DNS Privacy with Speed?” found DoQ to be roughly 10% faster than DoH for simple page loads and only ~2% slower than cleartext UDP DNS ¹³. A 2026 follow-up comparing DoQ to DNS over HTTP/3 reported the two are within ~1% on low-latency paths ¹⁴.

Production deployment is sparse: AdGuard DNS exposes DoQ as a public resolver, and dnsdist 1.9+, Technitium, and dnspython 2.7+ ship server/library support, but no major browser has shipped DoQ as of early 2026. The blocker is QUIC stack maturity, not the protocol itself.

ECH — Encrypted ClientHello

Even after DoH/DoT/DoQ encrypts the resolution, the very next thing the client does is open a TLS connection — and the original TLS ClientHello carries the destination hostname in the SNI extension in plaintext. That is what most national-firewall systems actually filter on. Encrypted ClientHello (RFC 9849, March 2026) closes that gap.

The mechanics:

1. The client resolves the destination via DoH/DoT and gets back an HTTPS (SVCB) record containing an ECHConfig with the server’s HPKE public key.
2. The client sends a TLS ClientHelloOuter with a generic public name in the SNI (e.g. cloudflare-ech.com) plus an encrypted_client_hello extension carrying the HPKE-encrypted ClientHelloInner.
3. The server (which holds the HPKE private key) decrypts the inner ClientHello, extracts the real SNI, and continues the handshake for the actual destination.

Browser support: Chrome shipped ECH in v117 (September 2023); Firefox enabled it by default in v119 (October 2023). Cloudflare turned ECH on by default for its hosted properties in October 2024 ¹⁵.

Censorship pushback: Russia’s regulator Roskomnadzor began dropping TLS ClientHellos that contain both the encrypted_client_hello extension and the SNI value cloudflare-ech.com in November 2024 ¹⁶; iOS and Windows users routed to Cloudflare-fronted sites saw immediate breakage. China and Iran have similar filters. The episode underscores the design risk of a single popular outer SNI: it becomes the easiest fingerprint to filter on.

Enterprise deployment

Encrypted DNS is a policy minefield: it removes a long-standing observability and control point. The NSA’s January 2021 guidance “Adopting Encrypted DNS in Enterprise Environments” lays out the dominant pattern: route all enterprise DNS — encrypted or not — through a designated internal resolver, and block external encrypted DNS at the egress.

Split-horizon breakage

The first thing that breaks when a managed laptop turns on Firefox’s default-Cloudflare DoH is split-horizon (split-brain) DNS. Internal names like payroll.corp.example.com are not in the public zone; Cloudflare returns NXDOMAIN, the laptop fails to find the internal app, and your security team loses DNS-based egress logging in the same step.

Mitigations, in increasing order of strength:

The defensible default is “internal encrypted resolver + MDM-pushed policy + canary domain”, with port 853 firewalled and DoH on port 443 left open because trying to block it without breaking the web is hopeless.

Resolver selection cheat-sheet

EDNS Client Subnet (RFC 7871) trades privacy for routing accuracy: by sending an anonymised client prefix to the authoritative server, GeoDNS routing can pick a regionally optimal answer — but the authoritative now learns roughly where you are. Cloudflare deliberately omits ECS; Google sends it. For most consumer users the latency win is real and the privacy loss minor; for sensitive workloads, prefer the operator that does not.

Operational verification

DNSSEC checks

1dig example.com DNSKEY +dnssec2dig example.com +dnssec3dig example.com +cd4delv example.com +vtrace

Interpretation:

• flags: ... ad in the response header means the resolver verified the chain and you can trust the answer.
• SERVFAIL from dig example.com and a clean answer from dig example.com +cd is the unambiguous DNSSEC signature — the chain is broken.
• Both commands failing points at an authoritative or network problem, not DNSSEC.
• delv with +vtrace walks each link and prints which one failed; pair it with dnsviz.net/d/<name>/analyze/ for a visual chain map.

DoH / DoT / DoQ checks

1kdig @1.1.1.1 example.com +tls2kdig @1.1.1.1 example.com +https3kdig @dns.adguard-dns.com example.com +quic45curl -H 'accept: application/dns-message' \6  --data-binary @- \7  -X POST 'https://cloudflare-dns.com/dns-query' < query.bin | xxd | head

For ECH a contemporary curl (curl --ech true ...) or a browser network log will tell you whether the negotiated handshake actually used the encrypted inner SNI.

What to monitor

1dig example.com RRSIG +dnssec +multiline | grep -A1 "RRSIG"

Practical takeaways

• DNSSEC and encrypted DNS solve different problems; you need both for end-to-end protection, and neither hides the destination IP.
• For a new signed zone, default to ECDSA P-256 (algorithm 13), NSEC3 with iterations = 0 and empty salt, automated re-signing tighter than the validity window, and RRSIG-expiry alerts.
• For client-side privacy, prefer DoH (or DoQ where available); accept that it concentrates queries at one operator.
• For enterprise rollouts, run an internal recursive resolver that supports DoH/DoT, push it with MDM/GPO, return NXDOMAIN for use-application-dns.net, block outbound 853, and accept that DoH on 443 is unblockable without breaking HTTPS.
• For full hostname privacy, layer ECH over DoH/DoT — with the explicit caveat that ECH’s privacy property is only as good as the DNS lookup that fetched its key.
• Treat the root KSK rollover (October 2026) and the proposed RSA→ECDSA root algorithm rollover (2027 onward) as planned events: validators that fall behind RFC 5011 trust-anchor updates will silently start serving SERVFAIL.

Appendix

Prerequisites

• DNS resolution fundamentals — see DNS Resolution Path.
• DNS records and TTL behaviour — see DNS Records, TTL, and Caching.
• TLS handshake basics — see TLS 1.3 Handshake and HTTPS.
• HTTP/2 and HTTP/3 transport (used by DoH and DoQ respectively) — see HTTP/3, QUIC and TLS.
• Public-key cryptography fundamentals: asymmetric keys, digital signatures, HPKE.

When something is broken in production, jump to the DNS Troubleshooting Playbook for symptom-driven recipes.

Glossary

References

• RFC 4033 — DNSSEC Introduction and Requirements
• RFC 4034 — DNSSEC Resource Records
• RFC 4035 — DNSSEC Protocol Modifications
• RFC 5011 — Automated Updates of DNSSEC Trust Anchors
• RFC 5155 — DNSSEC NSEC3 Hashed Authenticated Denial of Existence
• RFC 7344 — Automating DNSSEC Delegation Trust Maintenance (CDS / CDNSKEY)
• RFC 7477 — Child-to-Parent Synchronization in DNS (CSYNC)
• RFC 7583 — DNSSEC Key Rollover Timing Considerations
• RFC 7858 — DNS over TLS (DoT)
• RFC 7871 — Client Subnet in DNS Queries (ECS)
• RFC 7873 — DNS Cookies / RFC 9018 — Interoperable DNS Server Cookies
• RFC 8078 — Managing DS Records via CDS / CDNSKEY
• RFC 8310 — Usage Profiles for DoT and DoH
• RFC 8484 — DNS Queries over HTTPS (DoH)
• RFC 8624 — Algorithm Implementation Requirements for DNSSEC
• RFC 8914 — Extended DNS Errors (EDE)
• RFC 9230 — Oblivious DNS over HTTPS (ODoH)
• RFC 9250 — DNS over Dedicated QUIC Connections (DoQ)
• RFC 9276 — Guidance for NSEC3 Parameter Settings (BCP 236)
• RFC 9849 — TLS Encrypted Client Hello (ECH)
• ICANN Root KSK Rollover programme and IANA DNSSEC Trust Anchors
• APNIC DNSSEC validation measurement
• NSA — Adopting Encrypted DNS in Enterprise Environments (Jan 2021)
• DNSViz — DNSSEC visualisation and analysis