Module 9 · Lesson 4

Emerging Trends Worth Watching

An honest assessment of where DNS is heading: SVCB/HTTPS records, DNS over QUIC, the new gTLD round, regulatory changes, and what's probably noise.

Emerging Trends Worth Watching

Trend sections in technical courses tend toward two failure modes: breathless enthusiasm for things that won't matter for five years, or blanket skepticism that misses genuinely important shifts. The goal here is neither.

What follows is an honest assessment of where DNS is actually moving — what's getting real adoption, what's regulatory rather than technical, what's interesting but not yet practical, and what's mostly noise.

Worth Watching

SVCB and HTTPS Records

SVCB (Service Binding) records, and their application-specific variant HTTPS records, are the most practically important DNS change in recent years for web infrastructure operators.

The problem they solve: the current pattern for "serve this hostname over HTTPS on port 443 with HTTP/2 and HTTP/3 support" requires multiple lookups and connections. A client connects on port 80, gets redirected to HTTPS, and negotiates the connection without advance knowledge of what protocols the server supports. This is slow and wastes a round trip.

An HTTPS record allows a domain to advertise this information in DNS:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="203.0.113.10" ipv6hint="2001:db8::1"

A browser that supports HTTPS records can:

  • Skip the initial HTTP connection entirely
  • Start TLS with knowledge of supported protocols
  • Use IP hints to skip an additional A/AAAA lookup

The adoption path: Chrome and Firefox added HTTPS record support. Cloudflare serves HTTPS records automatically. Major CDNs are adding support. This is not speculative — it's shipping.

What it means for you: if you're behind Cloudflare or a CDN that supports HTTPS records, you may already be benefiting without doing anything. If you manage your own authoritative DNS, adding HTTPS records to your zone is a concrete performance improvement for supported clients.

SVCB records serve a more general purpose — any protocol can use them for service discovery, not just HTTPS. The long-term trajectory is that SVCB/HTTPS become the standard mechanism for announcing service capabilities in DNS, replacing the A+CNAME+SRV pattern for many use cases.

DNS over QUIC (DoQ)

DNS over TLS (DoT) and DNS over HTTPS (DoH) are both deployed and working. DNS over QUIC (DoQ, RFC 9250) takes the next step: DNS queries over QUIC transport, which eliminates the head-of-line blocking inherent in TLS over TCP, and eliminates connection setup latency for subsequent queries.

In practical terms: DoQ is faster than DoT for multiple concurrent queries, and starts faster than DoH because QUIC's connection establishment is lighter.

Current status: specified (RFC 9250, 2022), with early deployments appearing in public resolvers. Not yet widely deployed compared to DoH. Worth watching because if QUIC adoption in browsers and operating systems continues its current trajectory, DoQ will follow.

The practical implication for most infrastructure operators in the next 2-3 years: monitoring whether your resolver infrastructure supports DoQ and planning for it, but not urgently. For privacy-conscious users choosing a resolver today, DoH and DoT are the practical options.

The New gTLD Application Round

ICANN is opening a second application window for new generic top-level domains. The first round (2012-2014) produced over 1,200 new TLDs, most of which have seen minimal use.

The second round will likely produce hundreds or thousands more. From a pure namespace perspective, this creates more surface area for typosquatting, brand confusion, and defensive registration decisions.

What you should do before the round opens: have your domain strategy already documented. Know which new TLDs would require defensive registration for your brand and at what cost. Know which category of monitoring or UDRP response you'd apply to the rest.

The second round won't change the fundamental economics of brand protection in DNS — it just scales up the surface area. Teams with a documented tiered registration strategy will handle it cleanly; teams without one will find themselves registering domains reactively and expensively.

For brands considering applying for a .brand TLD: the second application window is a real opportunity, not a vanity exercise. A .brand registry gives you complete control over who can register under your TLD, making subdomain takeover and phishing under your namespace essentially impossible without your cooperation. For major brands with significant abuse problems, this is worth serious evaluation.

Consolidation Risk: Cloudflare and Google

This is not a technology trend — it's a structural one. Cloudflare and Google together handle a large fraction of DNS queries globally: Cloudflare via both its authoritative hosting (millions of zones) and its 1.1.1.1 public resolver, Google via 8.8.8.8. Add Quad9, OpenDNS, and a few others and you have most of the world's DNS resolution running through a handful of operators.

This creates dependency risk that is not visible in most organizations' resilience planning. If Cloudflare has a significant outage (which has happened), a huge portion of the internet degrades simultaneously.

What this means for you:

  • If your authoritative DNS is entirely on Cloudflare, you have single-provider risk even if your hosting is redundant.
  • If your internal resolvers forward to 8.8.8.8 or 1.1.1.1 exclusively, you have single-resolver risk.
  • Multi-provider authoritative DNS is partly a hedge against this consolidation.

The consolidation trend is likely to continue rather than reverse. The practical response is what it's always been for infrastructure: identify single points of failure in your specific setup and add redundancy where the risk justifies the cost.

Regulatory Changes: Watch Carefully

WHOIS and RDAP

GDPR has been eroding public WHOIS data since 2018. The RDAP protocol (RFC 7482, 7483, 7484) is replacing the legacy WHOIS protocol with a structured, extensible alternative. RDAP is now mandatory for gTLD registries and many registrars.

The practical effect: registrant contact data is increasingly gated behind accredited access requests or not available at all for privacy-protected domains. For brand protection teams that used WHOIS for threat intelligence, this changes the data sources available.

For most developers and operators, RDAP is simply "better WHOIS" — structured JSON output instead of free-form text. The whois command is being superseded; tools like rdap.org or the rdap CLI are the modern replacements.

NIS2 and DNS Infrastructure

The EU's NIS2 Directive (Network and Information Security Directive 2) came into force in October 2024 and significantly expands the scope of critical infrastructure obligations in Europe. DNS operators providing services to entities in scope (critical infrastructure sectors) face new requirements around incident reporting, security measures, and supply chain security.

If you're a DNS-heavy operation serving European clients in regulated sectors (energy, health, finance, transport), you need to understand your NIS2 obligations or the obligations of the services you depend on. This is not hypothetical — the enforcement window is now open.

Probably Noise (For Most People)

Blockchain DNS

ENS (Ethereum Name Service), Handshake, Unstoppable Domains — the idea of a decentralized, censorship-resistant naming system built on blockchain has been circulating for years. The technology is real. The use cases are coherent.

The practical adoption, however, remains at near zero for ordinary internet infrastructure. Resolving a .eth domain still requires special resolver support (browser extension, modified resolver configuration) or a centralized bridge. This means blockchain DNS is not a substitute for traditional DNS in any realistic production scenario today.

The architecture is also slow for the use cases DNS is typically optimized for, and the smart contract governance of ENS creates its own centralization vectors.

This might change. Watch it if you're interested in the technology. Don't build infrastructure dependencies on it.

AI-Generated DNS Configurations

Language models can generate DNS configuration files, Terraform HCL, and BIND zone data. What they produce often looks correct and plausible.

The problem: DNS is a domain where plausible-looking but wrong configurations have real consequences. An AI-generated SPF record that's syntactically valid but missing a mail provider's include will quietly break email delivery. A DNSSEC configuration that's almost right will cause SERVFAIL for all clients doing DNSSEC validation.

Use AI tooling as a starting point if you want, but DNS configurations need to be validated: queried directly, checked against the spec, and tested before they're authoritative. "It looks right" is not sufficient.

Key Takeaways

  • SVCB/HTTPS records are worth implementing now if you control your authoritative DNS. Real adoption, real browser support, real performance improvement.
  • DNS over QUIC is coming. Not urgent, but include it in your resolver upgrade planning.
  • The new gTLD round requires a strategy before it opens, not a reaction after.
  • Cloudflare/Google consolidation is a structural risk to plan around — multi-provider authoritative DNS addresses your direct exposure.
  • Regulatory (NIS2, RDAP, GDPR WHOIS) is moving faster than technical in the short term. Know your obligations.
  • Blockchain DNS: interesting technology, not production infrastructure. Don't build dependencies on it.

Up Next

Lesson 5 — Final Project: DNS Audit and Architecture Review: Put it all together. A structured audit of a real domain setup, with templates you can take back to your own infrastructure.