Reviving HEv3 & HTTPS-RR in Chromium

This post is a work in progress -- it will be updated as CLs land and the project evolves.

Taking matters into my own hands to pursue RFC 9460 support in Chrome.

The Beginning: HTTPS Resource Records

It all started with a simple goal: I wanted to implement full support for HTTPS Resource Records (HTTPS-RR) in Chromium, specifically RFC 9460. This includes proper handling of AliasMode and ServiceMode with different target names—features crucial for the modern web's evolution towards more flexible and secure service discovery.

I picked up Issue 40257146 and went to work. I put together a CL that successfully implemented the logic. It worked! I was ready to land it.

The Block: "Wait for HEv3"

But then, the code review feedback came in. It wasn't about the correctness of my specific logic, but about the architecture. The Chromium team was in the middle of a major network stack refactor known as Happy Eyeballs v3 (HEv3).

My approach was flagged as conflicting with this new direction:

"My preference would be 'Wait until HEv3 lands and then revisit with proper integration.' At this point I don't have concrete ideas about how we should implement aliases and different target names so I'm not sure we keep or abandon this CL. I think marking this as work in progress... is a reasonable action for now."

It made sense. HEv3 is designed to allow connection attempts to race without waiting for all DNS results—a huge performance win. My implementation, based on the legacy path, might have blocked this optimization. So, I parked the CL and waited.

The Twist: "We might not do HEv3"

Time passed. HEv3 development dragged on. Then came the update that flipped everything:

"The HEv3 development has been prolonged and it's difficult to predict when it will be completed. The team are moving towards not implementing HEv3 (that's unfortunate). We may consider supporting HTTPS RR aliases and different target names without HEv3, nothing has been decided yet."

So, the shiny new architecture I was waiting for—the one that blocked my feature—was potentially being abandoned? And we might go back to a non-HEv3 implementation anyway?

The Revival

That was my "WTF" moment. Instead of waiting for a compromise or abandoning the architectural improvements of HEv3, I decided to revive the effort myself. If HEv3 was stalled, I would help unblock it to get my HTTPS-RR features landed properly.

I dove deep into the HEv3 design docs and the codebase. I mapped out a detailed plan and started working through a 70+ step checklist to:

Become a regular contributor to the HEv3 codepath (net/dns, net/http).
Implement HTTPS-RR follow-ups (AliasMode/ServiceMode) within the HEv3 model.
Ensure no performance regressions (the whole point of HEv3!).
Ship it.

Current Status

I've already landed several preparatory CLs and have a stack of 63 changes in flight to completely overhaul the HEv3 codepath for HTTPS-RR support. The core functionality is now working end-to-end!

View all 63 CLs (Progress: 2 Merged, 61 In Review) →

Landed / Merged:

In Review (DNS & Normalization):

IN REVIEW DnsTaskResultsManager target-name behavior
IN REVIEW Canonicalize domain-name matching
IN REVIEW Apply HTTPS metadata via alias targets
IN REVIEW Deduplicate endpoints in DnsTaskResultsManager
IN REVIEW Allow multiple HTTPS completions
IN REVIEW Avoid adding HTTPS query names to DNS aliases
IN REVIEW Surface HTTPS alias records
IN REVIEW Normalize DNS names for endpoint keying
IN REVIEW Normalize HTTPS target names in extractor
IN REVIEW Propagate stale DNS aliases
IN REVIEW Normalize canonical name matching in HostCache
IN REVIEW Log DNS aliases with endpoint updates
IN REVIEW Normalize canonical names in HostCache entries
IN REVIEW HostCache normalization coverage

In Review (Followups & ServiceMode):

IN REVIEW Extend DnsTaskResultsManager tests
IN REVIEW Prototype AliasMode followup resolution
IN REVIEW Add bounded recursion + cycle detection
IN REVIEW Extend DnsTaskResultsManager to accept followups
IN REVIEW Add ServiceMode TargetName followup query handling
IN REVIEW Extend tests for ServiceMode multi-target followups
IN REVIEW Validate IsMetadataReady semantics
IN REVIEW Plumb target name through connection layer
IN REVIEW Add connection-layer tests for multi-target ServiceMode
IN REVIEW NetLog or UMA for followup query timing
IN REVIEW ServiceMode multi-target test coverage

In Review (Connection Layer & Plumbing):

IN REVIEW Add ServiceEndpointConnectionAttempt representation
IN REVIEW Plumb ServiceEndpointConnectionAttempt through connect jobs
IN REVIEW Add TCPServiceEndpointConnectJob and wire SSLConnectJob
IN REVIEW Update QuicSessionPool::Job for pre-resolved endpoints
IN REVIEW Add preconnect support in HttpStreamPool
IN REVIEW Add HEv3 ECH fallback handling
IN REVIEW Add idle socket lookup or bypass mode
IN REVIEW Move proxy resolution to HttpStreamFactory
IN REVIEW Cancel in-flight QUIC attempts on session activation
IN REVIEW Align HEv3 TCP/TLS timeout error codes
IN REVIEW Add UMA for HEv3 TCP-based and QUIC attempt outcomes
IN REVIEW Add HEv3 dual-stack TLS fallback test
IN REVIEW Add HEv3 incremental DNS endpoint update test
IN REVIEW Add HEv3 DNS error fallback and multi-endpoint tests
IN REVIEW Add NetLog event for HEv3 SPDY throttle delay
IN REVIEW Record QUIC failure in connection_attempts_
IN REVIEW Convert CHECK to DCHECK in MaybeAttemptTcpBased
IN REVIEW Test preconnect with HTTPS RR metadata endpoints
IN REVIEW Test cancellation mid-followup
IN REVIEW Integration cleanup

In Review (HTTPS-RR Core - The Key Gate!):

KEY CL Remove TargetName filter in DnsResponseResultExtractor
IN REVIEW End-to-end HTTPS RR different TargetName followup test
IN REVIEW Followup recursion limit + cycle detection test

In Review (Metrics & Flag Flip):

IN REVIEW UMA for HEv3 vs legacy path selection
IN REVIEW UMA for DNS resolution time in HttpStreamPool
IN REVIEW UMA for intermediate vs final endpoint usage
FLAG FLIP Enable kHappyEyeballsV3 by default

It's a deep dive into Chromium's networking internals—HostResolver, HttpStreamPool, DnsTaskResultsManager—but we're getting there. The goal remains: Full RFC 9460 support in Chrome, backed by the performance of Happy Eyeballs v3.

Stay tuned for updates as I work through the checklist.

A Note on Reality

Will this work? I don't know yet. I'm one contributor with a vision, navigating a codebase shaped by many hands over many years. There will be tough reviews, architectural debates, and probably surprises I haven't anticipated. That's the nature of working in a project as complex as Chromium.

But here's what I do know: the best way to make something happen is to start. Every merged CL is one step closer. Every review comment is an opportunity to learn. And even if the path changes--even if we discover the way forward looks different than what I've mapped out--the effort itself moves the needle.

If there's a will, there's a way. We just might not know the way today.

"Only those who will risk going too far can possibly find out how far one can go."
— T.S. Eliot