Status: ❌ Rejected
What the first RFC 9460 implementation attempted, why its scope grew, and why it was not accepted.
The networking team is taking a different direction with ongoing refactoring work, so these CLs will not land in their current form. The write-up stays up as a record of the investigation and the patches that came out of it.
Initial HTTPS-RR Change
Issue 40257146 tracks gaps in Chromium's RFC 9460 support, including AliasMode and ServiceMode records with different target names.
The first CL implemented that behavior on Chromium's legacy resolver path. Its functional tests passed, but code review identified an architectural conflict with the Happy Eyeballs v3 (HEv3) network-stack work.
The Block: "Wait for HEv3"
The Chromium networking team was in the middle of the Happy Eyeballs v3 (HEv3) refactor. The review recommendation was to wait and integrate with that architecture:
"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."
HEv3 allows connection attempts to race without waiting for every DNS result. A legacy-path implementation risked duplicating or constraining that work, so the CL was parked.
HEv3 Became Uncertain
Later, the project reported that HEv3's completion date was uncertain:
"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."
That uncertainty prompted a broader prototype combining HEv3 plumbing with the missing HTTPS-RR behavior. Its scope included DNS result normalization, target-name follow-ups, connection-attempt representation, fallback behavior, metrics, and integration tests.
Outcome
Two preparatory fixes landed, but the larger prototype stack was not accepted in its current form. Most entries below were experiments used to understand subsystem boundaries; many were abandoned without formal review.
Prototype CL inventory
Landed / Merged:
- MERGED Fix HEv3 intermediate update behavior
- MERGED Ignore H2 sessions for non-SSL in AttemptManager
In Review (DNS & Normalization):
- IN REVIEW DnsTaskResultsManager target-name behavior
- IN REVIEW Canonicalize domain-name matching
- ABANDONED Apply HTTPS metadata via alias targets
- IN REVIEW Deduplicate endpoints in DnsTaskResultsManager
- ABANDONED Allow multiple HTTPS completions
- IN REVIEW Avoid adding HTTPS query names to DNS aliases
- ABANDONED Surface HTTPS alias records
- IN REVIEW Normalize DNS names for endpoint keying
- IN REVIEW Normalize HTTPS target names in extractor
- ABANDONED Propagate stale DNS aliases
- ABANDONED Normalize canonical name matching in HostCache
- IN REVIEW Log DNS aliases with endpoint updates
- IN REVIEW Normalize canonical names in HostCache entries
- ABANDONED HostCache normalization coverage
In Review (Followups & ServiceMode):
- IN REVIEW Extend DnsTaskResultsManager tests
- ABANDONED Prototype AliasMode followup resolution
- ABANDONED Add bounded recursion + cycle detection
- IN REVIEW Extend DnsTaskResultsManager to accept followups
- ABANDONED 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
- ABANDONED Add connection-layer tests for multi-target ServiceMode
- ABANDONED 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
- ABANDONED Cancel in-flight QUIC attempts on session activation
- ABANDONED 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
- ABANDONED Add NetLog event for HEv3 SPDY throttle delay
- IN REVIEW Record QUIC failure in connection_attempts_
- IN REVIEW Convert CHECK to DCHECK in MaybeAttemptTcpBased
- ABANDONED 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
- ABANDONED 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
The prototype showed that combining resolver changes, connection-layer refactoring, and RFC 9460 behavior in one stack was too broad for useful review. The later HTTPS-RR take-two keeps the work inside the resolver path and separates it into smaller changes.
What This Attempt Established
Even though the stack was rejected, it identified the relevant ownership boundaries: DnsResponseResultExtractor, HostResolverDnsTask, DnsTaskResultsManager, and the connection-attempt layer. It also made clear that RFC 9460 behavior should be reviewed separately from unrelated HEv3 architecture changes.