This patch calls NetworkConnectivityService::GetSingleton() on the main thread
and keeps a ref to the service until shutdown.
Even though calling ncs->GetIPv6() off-main-thread is technically a data-race
in practice that's OK because only the simple decision whether to send
AAAA requests is made based on that value, which in itself is an optimization.
I filed bug 1556967 for making the connectivity service thread safe.
Differential Revision: https://phabricator.services.mozilla.com/D33765
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--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
Split nsHostRecord into AddrHostRecord and TypeHostRecord for standard address dns queries and queries by-type.
Differential Revision: https://phabricator.services.mozilla.com/D6130
--HG--
extra : moz-landing-system : lando
Split nsHostRecord into AddrHostRecord and TypeHostRecord for standard address dns queries and queries by-type.
Differential Revision: https://phabricator.services.mozilla.com/D6130
--HG--
extra : moz-landing-system : lando
So that explicitly disabling TRR for specific resolves won't end up just
using the cached entry resolved with TRR!
MozReview-Commit-ID: HZ4AyKOMpet
Differential Revision: https://phabricator.services.mozilla.com/D4215
--HG--
extra : moz-landing-system : lando
Instead of creating and deleteing each thread, we use a nsThreadPool with a max of 8 resolver threads.
Whereas before each thread would run ThreadFunc exactly once then shut down, the threads may now remain active for a while. During this time we may post another task(runnable) to the thread.
MozReview-Commit-ID: FiE370ic1ah
--HG--
extra : rebase_source : 065bbf1f9867dfb38ac7b13816d4d06824d3a05d
... when comparing against the native resolver. DNS_TRR_COMPARE is meant
to compare how the actually performed name resolves fare against each
other.
MozReview-Commit-ID: 98NoUGPpHr6
--HG--
extra : rebase_source : 4042c81da3e5478de26feb7f83c98ee5eb298156
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
The DNS service was shutdown and restarted again in several scenarios,
for example when one of its prefs changed and by nsIOService when going
offline/online. The DNSService restart dragged the resolver, TRRService
and others with it and they too were thus restarted.
Most notably this hurt TRR resolving, as the restart caused short gaps
in time when there was no TRRService available and nsHostResolver
defaults to TRR Mode "native" if there's no TRRservice up, causing the
name resolver to occasionally use the wrong or unexpected resolver even
though TRR is enabled.
The resolver restart also flushed the DNS cache which is now avoided.
It is also a performance gain.
MozReview-Commit-ID: pp4Y8bNQJk
--HG--
extra : rebase_source : 9e3b3e6c0df16b8ca6287d8045f594026ae9ad6d
Otherwise it will just load back the same (problematic) addresses from the
cache again the second time. This introduces a new resolver bit
(REFRESH_CACHE) that also invalidates the existing cache entry while doing the
new resolve.
MozReview-Commit-ID: 5Bc2KiAGYYA
--HG--
extra : rebase_source : ae368c88a5db27f0980b9928439d27588bc84815
... and remove Cancel() from nsHostRecord::RemoveOrRefresh since we
don't need to cancel TRR resolves due to network changes.
MozReview-Commit-ID: Akuhpzgg4N5
Provides an optional resolver mechanism for Firefox that allows running
together with or instead of the native resolver.
TRR offers resolving of host names using a dedicated DNS-over-HTTPS server
(HTTPS is required, HTTP/2 is preferable).
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure
transfers and improved performance.
To keep the failure rate at a minimum, the TRR system manages a dynamic
persistent blacklist for host names that can't be resolved with DOH but works
with the native resolver. Blacklisted entries will not be retried over DOH for
a couple of days. "localhost" and names in the ".local" TLD will not be
resolved via DOH.
TRR is preffed OFF by default and you need to set a URI for an available DOH
server to be able to use it. Since the URI for DOH is set with a name itself,
it may have to use the native resolver for bootstrapping. (Optionally, the
user can set the IP address of the DOH server in a pref to avoid the required
initial native resolve.)
When TRR starts up, it will first verify that it works by checking a
"confirmation" domain name. This confirmation domain is a pref by default set
to "example.com". TRR will also by default await the captive-portal detection
to raise its green flag before getting activated.
All prefs for TRR are under the "network.trr" hierarchy.
The DNS-over-HTTPS spec: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-03
MozReview-Commit-ID: GuuU6vjTjlm
--HG--
extra : rebase_source : 53fcca757334090ac05fec540ef29d109d5ceed3
* Converts PLDHashTable mDB to nsRefPtrHashtable<nsGenericHashKey<nsHostKey>, nsHostRecord> mRecordDB
* Removes nsHostDBEnt and associated PLDHashTableOps
This patch makes the code a lot easier to understand, by simplifying the
ownership model. Now the hashtable holds RefPtr<nsHostRecord>, so it's
easier to follow the lifetime of each record.
MozReview-Commit-ID: IMavN8YSPSn
--HG--
extra : rebase_source : 3ff3135e2d9610577f15aaf307a62eec5ed3b47a
* nsResolveHostCallback extends nsISupports (for addref-ing and because nsDNSAsyncRequest implements nsICancelable)
* nsResolveHostCallback extends LinkedListElement<RefPtr<nsResolveHostCallback>> so the list can properly manage references
* nsDNSAsyncRequest and nsDNSSyncRequest properly implement nsISupports and use RefPtr to manage lifetimes
MozReview-Commit-ID: 5NvBcWZzfyN
--HG--
extra : rebase_source : 67adcbd20a29803e5abbb3d16324f9cac6771d28