Closed Bug 2044254 Opened 1 month ago Closed 1 month ago

Family-specific DNS lookups (RESOLVE_DISABLE_IPV4/RESOLVE_DISABLE_IPV6) cannot coalesce onto a pending AF_UNSPEC lookup

Categories

(Core :: Networking: DNS, defect, P2)

defect

Tracking

()

RESOLVED FIXED
153 Branch
Tracking Status
firefox153 --- fixed

People

(Reporter: kershaw, Assigned: kershaw)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

A family-restricted DNS request — RESOLVE_DISABLE_IPV6 or RESOLVE_DISABLE_IPV4 — cannot attach to an in-flight AF_UNSPEC lookup for the same host. Instead, it starts its own DNS lookup, duplicating work that the pending unspec lookup would already produce.

In Happy Eyeballs, HappyEyeballsConnectionAttempt::SetupDnsFlags sets RESOLVE_DISABLE_IPV4 / RESOLVE_DISABLE_IPV6 for its per-family A/AAAA queries. If the channel has already issued an AF_UNSPEC DNS prefetch (nsHttpChannel::MaybeStartDNSPrefetch) and that lookup is still pending, the HE per-family lookups cannot append their callbacks to it. As a result, the host may be resolved up to three times concurrently: the unspec prefetch plus one per family.

DNS queries are cheap. In addition, they take up a tiny fraction of connection establishment time. With that in mind, why not a P3 instead of a P2? Not opposed to fixing it eventually.

Before Happy Eyeballs starts connection establishment, we often already have a DNS prefetch in flight or completed. Ideally, the HE lookups should be able to reuse that result directly from the DNS cache instead of issuing more lookups.
The problem is that we are wasting the prefetch work we already did, and this also shows up as a DNS lookup timing regression in our metrics. That’s why I think P2 is reasonable.

Assignee: nobody → kershaw
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 153 Branch
QA Whiteboard: [qa-triage-done-c154/b153]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: