# DNS-over-HTTPS and PQC: Connection-Layer Migration **Source**: https://quantumsequrity.com/blog/dns-over-https-pqc **Category**: Network Protocols --- [← Back to Blog](../../blog.html) Network Protocols # DNS-over-HTTPS and PQC: Connection-Layer Migration 10 min read DNS-over-HTTPS (DoH) is the protocol that wraps DNS queries inside HTTPS requests. Instead of sending plaintext DNS queries to your ISP's resolver on port 53 (where your network operator can see and modify them), your browser or operating system sends them to a DoH server like `https://1.1.1.1/dns-query` or `https://dns.google/dns-query` over TLS. DoH is defined in RFC 8484, published in October 2018. It is now deployed by every major browser as either an option or a default. Cloudflare, Google, Quad9, OpenDNS, and most other public resolvers operate DoH endpoints. Many enterprises also run their own DoH infrastructure for internal name resolution. The PQC story for DoH is unusual because DoH itself does not need any cryptographic changes. The privacy guarantees of DoH come entirely from the underlying TLS layer. When TLS gets PQC, DoH gets PQC for free. This blog post walks through what that means in practice, what edge cases matter, and what operators should think about. ## DoH As A Protocol DoH is a thin layer. The DNS query is encoded as a wire-format DNS message (the same format used over UDP port 53 since RFC 1035) and either: - Sent as the body of a POST request with `Content-Type: application/dns-message`, or - Encoded as a base64url string in a query parameter of a GET request. The response is the wire-format DNS reply, returned with `Content-Type: application/dns-message`. That's it. No new authentication, no new key exchange, no new cryptographic primitives. The encryption is HTTPS, which means TLS 1.3 (or sometimes TLS 1.2 for old clients), which means the [TLS 1.3 hybrid handshake](../../blog/tls-1-3-hybrid-handshake.html) story applies directly. ## Why The TLS Layer Is Where PQC Happens For DoH, the entirety of the cryptographic protection sits in the TLS handshake and record layer: - **Confidentiality**: HTTPS encrypts the DNS query, so an on-path observer cannot see what domain you are looking up. - **Integrity**: HTTPS authenticates the response, so the resolver cannot be impersonated. - **Identity**: The TLS certificate proves you are talking to the resolver you intended. When TLS 1.3 negotiates a hybrid PQC group like `X25519MLKEM768`, the DNS query inside that connection inherits all the post-quantum protection. The DoH client and server do not need to know anything about PQC; the TLS library handles it. This is the cleanest possible PQC migration story: a protocol that depends entirely on a lower layer's security gets PQC the moment the lower layer does. ## Connection Reuse: A Performance Subtlety DoH connections are typically long-lived. A browser opens a DoH connection to its configured resolver and reuses that connection for many DNS queries. This is good for performance — you pay the TLS handshake cost once and then send queries cheaply. For PQC, connection reuse is even more important. The hybrid PQC handshake is roughly 4-5 ms slower than classical (per Cloudflare's measurements) and adds 2-3 KB of bandwidth. Per-query that would be expensive. Amortized over hundreds of queries, it is invisible. So: ensure your DoH client maintains long-lived connections. Modern browsers and operating systems do this by default. Embedded devices and custom clients should be configured to do the same. ## HTTP/2 vs HTTP/3 For DoH DoH originally used HTTP/1.1, then HTTP/2, and now increasingly HTTP/3 (which means QUIC). The PQC story for each: - **HTTP/1.1 over TLS**: Hybrid PQC works fine. Performance is mediocre because HTTP/1.1 has head-of-line blocking, but the security inherits cleanly. - **HTTP/2 over TLS**: Same hybrid PQC, plus HTTP/2's multiplexing for better performance. - **HTTP/3 over QUIC**: Hybrid PQC inherits from QUIC's TLS-inside-QUIC handshake. See our [QUIC PQC article](../../blog/quic-pqc-implementation.html) for the QUIC-specific complications. For modern DoH deployments, HTTP/2 over TLS 1.3 is the most common. HTTP/3 adoption is growing for DoH, especially among Cloudflare's clients. ## Resolver-Side PQC Configuration If you operate a DoH resolver, the PQC configuration is essentially identical to operating any other HTTPS service: 1. Update your TLS library (OpenSSL 3.5+, BoringSSL, rustls, etc.) to a version with hybrid PQC support. 2. Configure the supported groups list to include `X25519MLKEM768`, ahead of `X25519` and `secp256r1`. 3. Make sure your TLS certificates are valid (PQC certificate signatures are still future work; classical certs are fine for now). 4. Monitor handshake metrics to see what fraction of clients negotiate PQC. For Cloudflare's 1.1.1.1 resolver, this is automatic — Cloudflare's edge already does hybrid PQC. For Google's 8.8.8.8/8.8.4.4 (Google Public DNS DoH at `dns.google`), Google has been deploying hybrid PQC across their TLS infrastructure. For Quad9 (9.9.9.9), the same. For self-hosted DoH resolvers like dnsdist, AdGuard Home, or Pi-hole running with DoH frontends, the PQC story depends on which TLS library handles the inbound HTTPS connection. Most of these route through nginx or Caddy, and recent versions of both support hybrid PQC. ## Client-Side PQC Configuration DoH clients in the wild include: - **Browsers**: Chrome, Firefox, Edge, Safari all have DoH. They use their built-in TLS stacks (BoringSSL for Chrome, NSS for Firefox, etc.). Recent versions support hybrid PQC. - **Operating systems**: Windows 11 has native DoH. macOS and iOS support DoH via configuration profiles. Linux systemd-resolved supports DoH. - **Embedded clients**: stubby, dnscrypt-proxy, AdGuard, and others. PQC support varies by the underlying TLS library. For most users, no configuration is needed. The DoH client uses whatever TLS the underlying library negotiates, which increasingly means hybrid PQC by default. ## Performance Considerations DNS queries are tiny — typically under 100 bytes for the query, 200-500 bytes for the response. Compared to a TLS handshake's 2-3 KB, the DNS data is negligible. This means the per-query overhead of DoH is dominated by network round-trip time, not cryptographic computation. Hybrid PQC adds a few milliseconds to the initial TLS handshake but adds nothing to subsequent queries on the same connection. The practical performance picture for hybrid-PQC DoH versus classical-DoH: - **First query on a fresh connection**: 4-5 ms slower for hybrid PQC. - **Subsequent queries on the same connection**: identical performance. - **Long-running browsers**: indistinguishable from classical. For mobile devices that frequently establish new connections (because of network changes, sleep/wake cycles), the overhead is more visible but still small. ## DNS Privacy: What DoH Does And Does Not Solve A common confusion is to think DoH solves all DNS privacy problems. It doesn't. DoH protects the DNS query in transit between the client and the configured DoH resolver. It does not: - Hide your DNS lookups from your DoH resolver — the resolver sees everything you query. - Prevent the resolver from logging or selling your DNS history. - Encrypt the resolver's onward queries to authoritative servers (those still go in plaintext, unless the resolver also uses authenticated encryption upstream). PQC for DoH improves the in-transit privacy guarantee against future quantum adversaries. It does not change the trust model with respect to the resolver itself. For full DNS privacy, the parallel technology is DNS-over-QUIC (DoQ, RFC 9250) for client-to-resolver and DNS-over-TLS (DoT, RFC 7858) for resolver-to-authoritative. Both inherit PQC from their TLS layer in the same way DoH does. ## Encrypted Client Hello And DoH A related privacy technology is Encrypted Client Hello (ECH), which encrypts the SNI (Server Name Indication) field in TLS so an on-path observer cannot see which website you are connecting to. ECH is being deployed by Cloudflare and others. PQC for ECH works the same way: ECH uses HPKE (Hybrid Public Key Encryption, RFC 9180) under the hood, and HPKE has PQC variants in development. As ECH and PQC mature in parallel, they will combine to give browsers a fully quantum-safe privacy layer. ## Browser Configuration Defaults Each major browser has its own DoH configuration: - **Chrome**: enables DoH automatically when the OS DNS resolver is on a known list of DoH-capable providers. Otherwise opt-in. - **Firefox**: enables DoH by default in many regions ("DNS over HTTPS" in network settings) using Cloudflare or NextDNS. - **Edge**: similar to Chrome. - **Safari**: can be configured via configuration profiles on macOS and iOS. The PQC inheritance happens at the browser's TLS stack level. Chrome's BoringSSL handles hybrid groups; Firefox's NSS handles them. As of late 2025, all major browsers ship hybrid PQC support and use it automatically when the server supports it. ## DoH Server Selection And PQC Capability DoH is configured per-client. Most browsers ship with a default DoH provider but allow user override. As of late 2025, the major public DoH providers and their PQC status are: - **Cloudflare (1.1.1.1)**: hybrid PQC enabled at the edge, automatic for compatible clients. - **Google (8.8.8.8 via dns.google)**: deploying hybrid PQC across their TLS infrastructure. - **Quad9 (9.9.9.9)**: tracking PQC deployment, no firm date as of late 2025. - **NextDNS**: relies on its CDN provider for TLS, follows that provider's PQC schedule. - **AdGuard DNS**: tracking but no production PQC yet. For privacy-conscious users, the choice of DoH provider matters more than the PQC status. The provider sees every DNS query you make. PQC ensures no on-path observer also sees those queries, which is a smaller (but real) privacy improvement. ## Operational Telemetry For a DoH operator, watching the fraction of TLS handshakes that negotiate hybrid PQC is a useful metric. Cloudflare reports more than 60% of compatible TLS clients negotiate hybrid groups as of 2025. For a DoH-specific service, the numbers track closely because the same browsers and operating systems power both. Operators can drive PQC adoption upward by: - Ensuring their TLS library (OpenSSL 3.5+, BoringSSL, rustls) is current. - Putting `X25519MLKEM768` first in the supported groups configuration. - Avoiding aggressive rate limits that might cause clients to fall back to plain DNS. ## What QNSQY Does QNSQY does not operate a DoH service. We use third-party DoH (typically Cloudflare 1.1.1.1) for our internal infrastructure, and we let our employees configure DoH on their personal devices. For our customers, the relevance of DoH PQC is indirect: when QNSQY-encrypted files are transferred over the internet, the network layer that resolves `api.quantumsequrity.com` to an IP address is independently secured by DoH (if the user's resolver supports it). This protects against a specific attack where an adversary watches DNS traffic to identify when QNSQY is being used. The defense-in-depth model: QNSQY's [hybrid encryption](../../blog/hybrid-encryption.html) protects the file content regardless of network layer. DoH PQC protects the metadata of which domains the user looks up. TLS PQC on the file transfer protects the in-transit encrypted file. Each layer protects a different aspect of user privacy and security. ## Frequently Asked Questions **Q: Does DoH need a new specification for PQC?** No. DoH is defined in RFC 8484 and that specification is unchanged. PQC arrives via the underlying TLS layer. **Q: Will my DoH client work with PQC automatically?** If your DoH client uses a TLS library that supports `X25519MLKEM768` or similar hybrid groups, yes. Most modern browsers and operating systems already do this automatically. **Q: Can a DoH server require PQC and refuse classical clients?** Technically yes, but operationally unwise. The vast majority of clients still negotiate classical groups. Refusing them would break DNS resolution for many users. Instead, add PQC as an option clients can negotiate. **Q: Is DoH still vulnerable to harvest-now-decrypt-later without PQC?** Yes, in the same way as any TLS connection. An attacker capturing your DNS-over-HTTPS traffic today and decrypting it on a future quantum computer learns your DNS query history. PQC closes that window. **Q: Does DNS-over-TLS (DoT) have the same PQC story as DoH?** Yes. DoT is DNS over a TLS connection on port 853. The TLS handshake handles PQC the same way; the DNS layer doesn't change. ## Sources 1. RFC 8484 — DNS Queries over HTTPS (DoH). https://datatracker.ietf.org/doc/html/rfc8484 2. RFC 7858 — DNS over TLS (DoT). https://datatracker.ietf.org/doc/html/rfc7858 3. RFC 9250 — DNS over Dedicated QUIC Connections (DoQ). https://datatracker.ietf.org/doc/html/rfc9250 4. RFC 8446 — TLS 1.3. https://datatracker.ietf.org/doc/html/rfc8446 5. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism. https://csrc.nist.gov/pubs/fips/203/final 6. Cloudflare Research — The state of the post-quantum Internet. https://blog.cloudflare.com/pq-2024/ ## Related Articles - [TLS 1.3 Hybrid Handshake](../../blog/tls-1-3-hybrid-handshake.html) - [QUIC PQC Implementation](../../blog/quic-pqc-implementation.html) - [What Is Post-Quantum Cryptography?](../../blog/what-is-post-quantum-cryptography.html) - [ML-KEM Explained](../../blog/ml-kem-explained.html) - [Harvest Now, Decrypt Later](../../blog/harvest-now-decrypt-later.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)