Add HTTPS RR CNAME consistency check to Happy Eyeballs#1
Open
mxinden-bot wants to merge 1 commit into
Open
Conversation
mxinden
reviewed
May 29, 2026
| ip_preference: IpPreference, | ||
| resolution_delay_ms: u32, | ||
| connection_attempt_delay_ms: u32, | ||
| check_https_rr_cname: bool, |
There was a problem hiding this comment.
no need for the option. always enable. see happy-eyeballs review.
Comment on lines
+233
to
+241
| // | ||
| // Happy Eyeballs v3 does not fall back to the origin once any ECH-bearing | ||
| // record is in play, so this origin-fallback case is pinned to the legacy | ||
| // path. | ||
| add_task(async function test_https_rr_with_matched_cname_1() { | ||
| Services.prefs.setBoolPref("network.http.happy_eyeballs_enabled", false); | ||
| registerCleanupFunction(() => { | ||
| Services.prefs.clearUserPref("network.http.happy_eyeballs_enabled"); | ||
| }); |
There was a problem hiding this comment.
Ah, I thought once a cname mismatch is detected, it does fallback. Please explain.
560c6fb to
df61a33
Compare
Ignore an HTTPS record whose TargetName is inconsistent with the canonical name produced by the origin's A/AAAA resolution, preferring the origin's plain A/AAAA addresses (the CNAME). This avoids breaking the ECH handshake under dual-CDN steering, matching the legacy CheckRecordIsUsableWithCname. The logic lives in the happy-eyeballs state machine (vendored at v0.7.0), where the check runs unconditionally. The canonical name rides on DnsResult::A / DnsResult::Aaaa and is threaded through the FFI from OnARecord / OnAAAARecord via nsIDNSAddrRecord::GetCanonicalName; the A/AAAA queries always request RESOLVE_CANONICAL_NAME. CheckRecordIsUsableWithCname remains as a legacy path used only when network.http.happy_eyeballs_enabled is false. Re-enable test_trr_https_rr_with_cname.js for HE3, pinning to the legacy path the subtests that exercise legacy-only behavior: the check_record_with_cname=false case (HE3 always runs the check) and the ECH origin-fallback case (HE3 does not fall back to the origin once an ECH-bearing record is in play). Differential Revision: https://phabricator.services.mozilla.com/D303605
df61a33 to
9fd6d26
Compare
mxinden-bot
pushed a commit
that referenced
this pull request
Jun 2, 2026
Upstream commit: https://webrtc.googlesource.com/src/+/983b4f025fb568e404eba87500edfd381d241fce [M149] Validate CGImage dimensions in MouseCursorMonitorMac Original change's description: > Validate CGImage dimensions in MouseCursorMonitorMac > > This adds missing height checks alongside the existing width checks > when processing and scaling the cursor image. > > Fixed: chromium:513268100 > Change-Id: Ida1e58334a9d3bda429819e4af51b33afbd0a95d > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/472700 > Reviewed-by: Alexander Cooper <alcooper@chromium.org> > Auto-Submit: Johannes Kron <kron@webrtc.org> > Commit-Queue: Alexander Cooper <alcooper@chromium.org> > Cr-Commit-Position: refs/heads/main@{#47715} (cherry picked from commit b343cd4e280980f26b4feb80684f57d5b4324e12) Bug: chromium:514928856,chromium:513268100 Change-Id: Ida1e58334a9d3bda429819e4af51b33afbd0a95d Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/473981 Auto-Submit: Chrome Cherry Picker <chrome-cherry-picker@chops-service-accounts.iam.gserviceaccount.com> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/7827@{#1} Cr-Branched-From: d606bc991592fbf4dcbe85e9d05db5e501a5ad42-refs/heads/main@{#47595}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements HTTPS Resource Record (RR) CNAME consistency checking in the Happy Eyeballs state machine to prevent connection failures when dual-CDN steering causes mismatches between HTTPS record targets and A/AAAA resolution results.
Summary
When a domain uses dual-CDN steering, the HTTPS record's
TargetNamemay point to one CDN while the A/AAAA CNAME chain steers to another. This can cause ECH handshake failures. This change adds optional filtering to drop HTTPS records whoseTargetNameis inconsistent with the canonical name from A/AAAA resolution, preferring the origin's plain addresses instead.Key Changes
AaaaandAvariants to include an optional canonical name (Option<TargetName>) reported by the resolvertarget_names_match()function for case-insensitive DNS name comparison with trailing dot normalization (RFC 4343)check_https_rr_cnameboolean field to control whether HTTPS records are filtered based on CNAME consistencyTargetNamedoesn't match the canonical name from A/AAAA resolutionImplementation Details
network.dns.https_rr.check_record_with_cnamepreference behaviorhttps://claude.ai/code/session_01Quk5LdGKEiv13yyQRrUwWh