Bug 2051290 - Warm the HTTPS RR cache from the extension dns.resolve API#6
Open
mxinden-bot wants to merge 1 commit into
Open
Bug 2051290 - Warm the HTTPS RR cache from the extension dns.resolve API#6mxinden-bot wants to merge 1 commit into
mxinden-bot wants to merge 1 commit into
Conversation
mxinden-bot
force-pushed
the
dns-resolve-warm-https-rr
branch
2 times, most recently
from
ca36529 to
b262ed7
Compare
Extensions resolving a hostname via browser.dns.resolve() (e.g. uBlock Origin's CNAME uncloaking) only consume A/AAAA, leaving the HTTPS record cold. A later connection then races a warm A/AAAA against a cold HTTPS RR and can miss HTTP/3 (bug 1953459). Issue a companion HTTPSSVC query alongside the address lookup and discard it; it only warms the cache. It is deliberately not RESOLVE_SPECULATE so, like the extension's address query, it survives network.dns.disablePrefetch (set by uBlock Origin's disable pre-fetching, the case this repairs). It also warms the recursive resolver, helping the DoH path despite the partitioned DoH cache.
mxinden-bot
force-pushed
the
dns-resolve-warm-https-rr
branch
from
b262ed7 to
1ba011f
Compare
mxinden-bot
changed the title
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
2 participants
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.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=2051290 (contributing cause: bug 1953459)
Problem
Extensions that resolve a hostname via
browser.dns.resolve()only receive A/AAAA records. uBlock Origin's CNAME uncloaking does exactly this on (almost) every request. Resolving the addresses without also resolving the HTTPS record leaves the HTTPS RR cold, so a subsequent connection races a warm A/AAAA against a cold HTTPS RR (a freshres_nquery, tens of ms on common stub resolver setups). When the HTTPS RR arrives after the happy eyeballs resolution delay, Firefox connects via HTTP/2 instead of HTTP/3 even though the record advertisesh3(bug 1953459).This is compounded by uBlock Origin's default "Disable pre-fetching" setting, which sets
network.dns.disablePrefetchand so suppresses the channel-level HTTPS RR prefetch that would otherwise warm the record.Change
browser.dns.resolve()now issues a companion HTTPS RR (RESOLVE_TYPE_HTTPSSVC) query alongside the address lookup it already performs, and discards the result. The extension-visible response is unchanged.Design points:
RESOLVE_SPECULATE. The extension's own address query is not speculative, so it survivesnetwork.dns.disablePrefetch. The companion query matches it; marking it speculative would get it dropped underdisablePrefetch, which is precisely the configuration (uBlock Origin's "disable pre-fetching", or a manual proxy) this warming is meant to repair.network.dns.upgrade_with_https_rr || network.dns.use_https_rr_as_altsvc(both default true), matching the gate used byHTMLDNSPrefetchandnsHttpChannel.Even though the DoH cache is partitioned in Firefox, the companion query also warms the recursive resolver's cache, so this helps the DoH path as well.
Test
test_ext_dns.jsgainstest_dns_resolve_warms_https_rr: withnetwork.dns.disablePrefetch=true(the uBlock Origin condition) and a native IP + HTTPS-RR override, it callsbrowser.dns.resolve(), asserts the extension still receives the address, then polls the DNS dashboard until an HTTPSSVC cache entry appears, proving the companion query fired and was not dropped.Both files are ESLint clean. The xpcshell test was not executed in my environment (no full build available); needs a run in CI:
./mach test toolkit/components/extensions/test/xpcshell/test_ext_dns.js.Note for reviewers
This issues an extra DNS query for every
browser.dns.resolve()caller, not only uBlock Origin. It is cheap (fire-and-forget, gated on the HTTPS-RR prefs) and harmless for callers that do not benefit, but if you would prefer it behind a dedicated pref or scoped more narrowly, happy to adjust.