This patch uses the existing xpcshell test certificate infrastructure
(pycert/pykey) to manage the http2 test certificates (and gets rid of some uses
of nsIBadCertListener2 as a bonus).
Differential Revision: https://phabricator.services.mozilla.com/D21814
--HG--
rename : netwerk/test/unit/CA.cert.der => netwerk/test/unit/http2-ca.pem
rename : testing/xpcshell/moz-http2/http2-key.pem => testing/xpcshell/moz-http2/http2-cert.key
extra : moz-landing-system : lando
... since AF_INET wouldn't actually use IPv4!
MozReview-Commit-ID: FCf7psawENI
Differential Revision: https://phabricator.services.mozilla.com/D4749
--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
... and before chasing a cname, check if the address record for that
CNAME is actually in fact already provided in the DNS packet that passed
on the CNAME!
Some existing tests ajusted for this. Two new tests added.
MozReview-Commit-ID: CBMO7N7jMEX
--HG--
extra : rebase_source : 1110a8df6d89fcbb0ad2a35b3762b837ce7a1e18
In the section of the response body parser that just skips over the
answer section, the code wrongly assumed there could only be a pointer
at the start, while in fact every label can be made as a pointer. Just
turned out to not be used very often.
MozReview-Commit-ID: 8ZYtlq8HDPw
--HG--
extra : rebase_source : cc790caf36b4d4e77b113f89ed427ee537a539d8
RFC 1035 section 4.1.1 documents this bit as:
RD - Recursion Desired - this bit may be set in a query and is copied
into the response. If RD is set, it directs the name server to pursue
the query recursively. Recursive query support is optional.
MozReview-Commit-ID: 8iHDgNtA1L1
--HG--
extra : rebase_source : a29010a2894fd00ebfbfb869f5938cf507345a2f
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
Valentin Gosu
Dorel Luca
Cosmin Sabou
Dana Keeler
Dragana Damjanovic
Gurzau Raul
Noemi Erli
Daniel Stenberg
Nicholas Hurley
Nicholas Hurley
Sebastian Hengst
Patrick McManus
Wes Kocher
Jonathan Hao
Carsten "Tomcat" Book
Kit Cambridge