The Future of DNS

A note on framing: "the future of DNS" is a phrase that should make you skeptical. DNS changes slowly and conservatively. The core protocol has been stable for 40 years. New mechanisms take years to go from RFC publication to meaningful deployment. What I can tell you is what's been standardized and why, where actual deployment is happening, and where the consolidation problems are going.

DNS over QUIC (DoQ)

DNS over TLS (DoT, RFC 7858) and DNS over HTTPS (DoH, RFC 8484) solved transport privacy for DNS by encrypting queries between clients and resolvers. Both use TCP-based transports, which means they inherit TCP's head-of-line blocking problem: if one packet is lost, all queries in flight wait.

DNS over QUIC (RFC 9250, published 2022) addresses this. QUIC is a transport protocol built on UDP that provides connection-oriented semantics, TLS 1.3 encryption, and per-stream multiplexing without head-of-line blocking. Lose a packet, and only the queries on that stream are affected — other concurrent queries continue.

For DNS, the practical advantages over DoT:

Faster connection establishment (0-RTT or 1-RTT handshake vs 2-RTT for TLS/TCP)
No head-of-line blocking for multiple concurrent queries
Connection migration: if the client's IP changes (mobile handoff), the QUIC connection can continue without renegotiation

DoQ uses port 853 (same as DoT) and ALPN token doq.

Deployment reality as of early 2026: DoQ is available on NextDNS and some other privacy-focused resolvers. Cloudflare has limited support. It's not broadly deployed at the scale of DoH. Client support exists in some DNS libraries (knot-resolver, stubby) but isn't in mainstream browsers or operating systems yet. The technical case for DoQ is strong; adoption has been slower than DoH, partly because DoH benefited from browser vendors shipping it and partly because the QUIC implementation overhead is higher than TCP+TLS for many operators.

Oblivious DNS (ODoH)

DoH and DoT encrypt the transport but leave one privacy problem intact: the resolver knows who is asking what. When you use 1.1.1.1 or 8.8.8.8, the resolver operator sees your IP address and every domain you query. They know your browsing patterns.

Oblivious DNS over HTTPS (ODoH, RFC 9230) separates the "who is asking" from the "what are they asking." The mechanism:

The client encrypts the query using the target resolver's public key (the resolver can't see who sent it)
The client sends the encrypted query to a proxy
The proxy forwards it to the target resolver (the proxy sees who's asking but not what)
The resolver decrypts and answers the query (the resolver sees what's being asked but not who's asking)
The response goes back through the proxy to the client

Neither the proxy nor the resolver has both pieces of information. Both would need to collude to correlate queries to identities.

Deployment reality: Cloudflare and Apple collaborated on an ODoH deployment in 2020. Apple routes some Safari traffic through ODoH. Cloudflare operates the resolver endpoint. There's an iCloud Private Relay product that uses a similar architecture (two-hop proxy with encrypted DNS). For everyday users, this is the main path ODoH has taken to deployment — through products rather than through general resolver infrastructure.

For engineers building privacy-sensitive applications, ODoH is worth knowing about but requires finding a resolver and proxy pair that supports it. The tooling is not yet as mature as DoH.

DNS Push Notifications

Traditional DNS is pull-based: clients query, servers answer. If a record changes, clients don't know until their cached TTL expires and they query again.

DNS Push Notifications (RFC 8765) enables servers to push updates to subscribed clients when records change. The client establishes a long-lived TCP connection to the server and subscribes to specific records. When those records change, the server pushes the new data.

Where this matters: IoT and service discovery. mDNS is link-local — if you want service discovery across subnets in a controlled network, you need unicast DNS. But polling for changes is inefficient. DNS Push lets devices subscribe to service records and get notified when services appear or disappear.

Deployment reality: Limited. BIND and Knot support it. It's used in some enterprise network management contexts. For the IoT service discovery case, it's an alternative to constant polling, but the complexity of maintaining long-lived connections has slowed adoption.

SVCB and HTTPS records

The SVCB (Service Binding) and HTTPS record types (RFC 9460, published 2023) are the most immediately practical new DNS record types.

The HTTPS record is a specialization of SVCB for HTTPS. It lets a domain advertise:

Where to connect (IP addresses or a different hostname)
What protocols are supported (HTTP/2, HTTP/3/QUIC)
That HTTPS is required (upgrade from HTTP is built into the DNS response)

example.com.  300  IN  HTTPS  1 . alpn=h3,h2 ipv4hint=93.184.216.34

This record says: when connecting to example.com, prefer HTTP/3, fall back to HTTP/2, and here's an IP hint to skip an extra A record lookup.

Why this matters in practice:

Browsers can start an HTTP/3 connection without first trying HTTP/1.1 and getting a redirect
The HTTPS record implicitly forces HTTPS (no HTTP downgrade)
The IP hints reduce connection setup latency

Cloudflare has deployed HTTPS records widely. Chrome and Firefox support them. This is probably the nearest-term DNS change that will affect how most internet infrastructure operates.

The consolidation problem

I want to end this lesson on something that isn't a new protocol — it's a structural problem with the direction DNS is going.

DoH, in particular, has accelerated a trend toward DNS resolution running through a very small number of large providers. Firefox routes DoH queries through Cloudflare by default (or NextDNS if you've changed it). Chrome routes through the system resolver, but Google's 8.8.8.8 is a common default. Apple's iCloud Private Relay routes through Apple/Cloudflare.

DNS was designed as a distributed system. The security model assumed that no single entity would see most of the world's DNS queries. That assumption is no longer true.

The top three DoH resolvers (Cloudflare, Google, Apple via Private Relay) likely see a majority of consumer DNS queries across major platforms. That's an enormous amount of user behavior data concentrated in a few places. The privacy argument for DoH was that your ISP shouldn't see your queries — valid. But it resulted in your queries instead going to large tech companies, which may be a different rather than better outcome for privacy.

This isn't an argument against encrypting DNS. It's an argument for thinking carefully about which resolver you use and whether centralizing your organization's DNS through one large provider is the right choice.

For organizations: running your own DoH/DoT resolver (or using a smaller privacy-focused provider like NextDNS or Mullvad DNS) keeps more of the benefit of encrypted transport while reducing concentration risk.

Key takeaways

DNS over QUIC (RFC 9250) improves on DoT with no head-of-line blocking and faster handshakes; deployment is still catching up
ODoH separates "who is asking" from "what are they asking"; deployed in iCloud Private Relay
HTTPS/SVCB records are the most practically useful new record type right now — deployed by Cloudflare, supported in major browsers
DNS Push Notifications exist but adoption is limited outside specific IoT/service discovery contexts
DoH has improved transport privacy while inadvertently concentrating DNS resolution through a few large providers

Up next

Lesson 07: Emerging DNS-Based Security Techniques — RPZ, passive DNS, threat intel feeds, and how DNS-layer security actually works in practice.