This way we preserve the behaviour of getaddrinfo, where both A and AAAA
responses come back at the same time.
Without this Firefox will always be biased, as the first request will usually
be resolved first. So if we requested IPv4 first, we'd mostly be using IPv4.
If we requested IPv6 first, normally we'll wait for the IPv4 response to come
back too, which is functionally equivalent to the new behaviour.
However, if the pref is set network.trr.early-AAAA;true then we'd use the IPv6
response immediately, possibly leading to a failed request if the IPv6
connection fails before we have an IPv4 address to fall back to.
A test for this patch was added in bug 1542561.
Depends on D33476
Differential Revision: https://phabricator.services.mozilla.com/D33477
--HG--
extra : moz-landing-system : lando
This is an optimization. If we detect that the system can't use the IPv6
address, there's no point in making a request for it.
Depends on D33475
Differential Revision: https://phabricator.services.mozilla.com/D33476
--HG--
extra : moz-landing-system : lando
Normally you wouldn't want localhost or *.local domain to be resolved by a
remote resolver.
This patch makes sure that even if we are in TRR-only mode, we still
successfully resolve the domains specified by network.trr.excluded-domains
using native DNS.
Also fixes bug in TRRService::ReadPrefs where we didn't clear mExcludedDomains
before reading the pref.
Differential Revision: https://phabricator.services.mozilla.com/D24380
--HG--
extra : moz-landing-system : lando
... when that NS check is used to check the "parent" domain of a
blacklisted host.
Previously, additional TRRblacklist entries due to this would always be
added with the originSuffix "" which was incorrect for all uses of other
suffxes.
MozReview-Commit-ID: EeorQuuRCRX
Differential Revision: https://phabricator.services.mozilla.com/D10192
--HG--
extra : moz-landing-system : lando
This fixes the regression caused by bug 1500549.
MozReview-Commit-ID: 3VBvIbrEbDT
Differential Revision: https://phabricator.services.mozilla.com/D9526
--HG--
extra : moz-landing-system : lando
Set the "network.trr.disable-ECS" pref to false to disable.
MozReview-Commit-ID: GE6L8Vpvuu0
Differential Revision: https://phabricator.services.mozilla.com/D2933
--HG--
extra : moz-landing-system : lando
... by making sure we only retry TRR when we go from CP bad=>good.
MozReview-Commit-ID: FcDwzSHm6Ia
--HG--
extra : rebase_source : dce21e18e6a4d854bd2023c61974658b100c1484
Move the TRR blacklist check to the main thread, and since it is now
done a little later and for each separate request, make sure to only do
the telemetry counting for one of the record types (A) so that we don't
count them twice.
MozReview-Commit-ID: BgvU4TzrpCq
--HG--
extra : rebase_source : 304bc75a6f22963b51e89034de1b30506337b6ec
If the confirmation state machine has gone into FAILED mode, updated
prefs is reason enough to try again and possibly get TRR verified
proper.
MozReview-Commit-ID: ALRbNJdvxdn
--HG--
extra : rebase_source : 8ad0a7d74d570228db17d91c1f5127b0524117a8
... but keep the logic that avoids re-initialization.
MozReview-Commit-ID: 2XQCRaM6U4B
--HG--
extra : rebase_source : e7291b3c7b26d39dcfde445212dd4f10b63ec98d
... to avoid a catch-22 as CP needs name resolve to work.
MozReview-Commit-ID: DC1CjlUy4cJ
--HG--
extra : rebase_source : 3bc0f146071f04757d44b76f352e48b2abb4dad0
To prevent it from sitting waiting for an event that was sent before the
TRRService started.
MozReview-Commit-ID: 9F0IlWGdA9O
--HG--
extra : rebase_source : 6a70210a4e538d8a1b240684a0b3ed5fed38e6ad
Early AAAA responses might cause issues on hosts without working native
IPv6 connectivity, of course especially notable in TRR-only mode.
MozReview-Commit-ID: 6ZqE6AKnucH
--HG--
extra : rebase_source : ff42cb8daf941a3fa1f7e783c76d823e879024c3
Kershaw Chang
Junior Hsu
Valentin Gosu
Sylvestre Ledru
Dana Keeler
Bogdan Tara
Dragana Damjanovic
Daniel Stenberg
Gurzau Raul
Noemi Erli
Jeff Hemphill
Dorel Luca
Andi-Bogdan Postelnicu