netwerk/docs/dns/dns-over-https-trr.md

   1 # DNS over HTTPS (Trusted Recursive Resolver)
   2
   3 ## Terminology
   4
   5 **DNS-over-HTTPS (DoH)** allows DNS to be resolved with enhanced
   6 privacy, secure transfers and comparable performance. The protocol is
   7 described in [RFC 8484](https://tools.ietf.org/html/rfc8484) .
   8
   9 **Trusted Recursive Resolver (TRR)** is the name of Firefox\'s
  10 implementation of the protocol and the
  11 [policy](https://wiki.mozilla.org/Security/DOH-resolver-policy) that
  12 ensures only privacy-respecting DoH providers are recommended by
  13 Firefox.
  14
  15 On this page we will use DoH when referring to the protocol, and TRR
  16 when referring to the implementation.
  17
  18 **Unencrypted DNS (Do53)** is the regular way most programs resolve DNS
  19 names. This is usually done by the operating system by sending an
  20 unencrypted packet to the DNS server that normally listens on port 53.
  21
  22 ## DoH Rollout
  23
  24 **DoH Rollout** refers to the frontend code that decides whether TRR
  25 will be enabled automatically for users in the [rollout
  26 population](https://support.mozilla.org/kb/firefox-dns-over-https#w_about-the-us-rollout-of-dns-over-https).
  27
  28 The functioning of this module is described
  29 [here](https://wiki.mozilla.org/Security/DNS_Over_HTTPS).
  30
  31 The code lives in
  32 [browser/components/doh](https://searchfox.org/mozilla-central/source/browser/components/doh).
  33
  34 ## Implementation
  35
  36 When enabled TRR may work in two modes, TRR-first (2) and TRR-only (3).
  37 These are controlled by the **network.trr.mode** or **doh-rollout.mode**
  38 prefs. The difference is that when a DoH request fails in TRR-first
  39 mode, we then fallback to **Do53**.
  40
  41 For TRR-first mode, we have a strict-fallback setting which can be
  42 enabled by setting network.trr.strict\_native\_fallback to true. With
  43 this, while we will still completely skip TRR for certain requests (like
  44 captive portal detection, bootstrapping the TRR provider, etc.) we will
  45 only fall back after a TRR failure to **Do53** for three possible
  46 reasons:
  47 1. We detected, via Confirmation, that TRR is currently out of
  48 service on the network. This could mean the provider is down or blocked.
  49 2. The address successfully resolved via TRR could not be connected to.
  50 3. TRR result is NXDOMAIN.
  51
  52 When a DNS resolution doesn't use TRR we will normally preserve that data in the form of a _TRRSkippedReason_. A detailed explanation of each one is available [here](trr-skip-reasons).
  53
  54 In other cases, instead of falling back, we will trigger a fresh
  55 Confirmation (which will start us on a fresh connection to the provider)
  56 and retry the lookup with TRR again. We only retry once.
  57
  58 DNS name resolutions are performed in _nsHostResolver::ResolveHost_. If a
  59 cached response for the request could not be found,
  60 _nsHostResolver::NameLookup_ will trigger either a DoH or a Do53 request.
  61 First it checks the effective TRR mode of the request is as requests
  62 could have a different mode from the global one. If the request may use
  63 TRR, then we dispatch a request in _nsHostResolver::TrrLookup_. Since we
  64 usually resolve both IPv4 and IPv6 names, a **TRRQuery** object is
  65 created to perform and combine both responses.
  66
  67 Once done, _nsHostResolver::CompleteLookup_ is called. If the DoH server
  68 returned a valid response we use it, otherwise we report a failure in
  69 TRR-only mode, or try Do53 in TRR-first mode.
  70
  71 **TRRService** controls the global state and settings of the feature.
  72 Each individual request is performed by the **TRR** class.
  73
  74 Since HTTP channels in Firefox normally work on the main thread, TRR
  75 uses a special implementation called **TRRServiceChannel** to avoid
  76 congestion on the main thread.
  77
  78 ## Dynamic Blocklist
  79
  80 In order to improve performance TRR service manages a dynamic blocklist
  81 for host names that can\'t be resolved with DoH but work with the native
  82 resolver. Blocklisted entries will not be retried over DoH for one
  83 minute (See _network.trr.temp\_blocklist\_duration\_sec_
  84 pref). When a domain is added to the blocklist, we also check if there
  85 is an NS record for its parent domain, in which case we add that to the
  86 blocklist. This feature is controlled by the
  87 _network.trr.temp\_blocklist_ pref.
  88
  89 ## TRR Confirmation
  90
  91 TRR requests normally have a 1.5 second timeout. If for some reason we
  92 do not get a response in that time we fall back to Do53. To avoid this
  93 delay for all requests when the DoH server is not accessible, we perform
  94 a confirmation check. If the check fails, we conclude that the server is
  95 not usable and will use Do53 directly. The confirmation check is retried
  96 periodically to check if the TRR connection is functional again.
  97
  98 The confirmation state has one of the following values:
  99
 100 -   CONFIRM\_OFF: TRR is turned off, so the service is not active.
 101 -   CONFIRM\_TRING\_OK: TRR in on, but we are not sure yet if the
 102         DoH server is accessible. We optimistically try to resolve via
 103         DoH and fall back to Do53 after 1.5 seconds. While in this state
 104         the TRRService will be performing NS record requests to the DoH
 105         server as a connectivity check. Depending on a successful
 106         response it will either transition to the CONFIRM\_OK or
 107         CONFIRM\_FAILED state.
 108 -   CONFIRM\_OK: TRR is on and we have confirmed that the DoH server
 109         is behaving adequately. Will use TRR for all requests (and fall
 110         back to Do53 in case of timeout, NXDOMAIN, etc).
 111 -   CONFIRM\_FAILED: TRR is on, but the DoH server is not
 112         accessible. Either we have no network connectivity, or the
 113         server is down. We don\'t perform DoH requests in this state
 114         because they are sure to fail.
 115 -   CONFIRM\_TRYING\_FAILED: This is equivalent to CONFIRM\_FAILED,
 116         but we periodically enter this state when rechecking if the DoH
 117         server is accessible.
 118 -   CONFIRM\_DISABLED: We are in this state if the browser is in
 119         TRR-only mode, or if the confirmation was explicitly disabled
 120         via pref.
 121
 122 The state machine for the confirmation is defined in the
 123 _HandleConfirmationEvent_ method in _TRRService.cpp_
 124
 125 If strict fallback mode is enabled, Confirmation will set a flag to
 126 refresh our connection to the provider.
 127
 128 ## Excluded Domains
 129
 130 Some domains will never be resolved via TRR. This includes:
 131
 132 -   domains listed in the **network.trr.builtin-excluded-domains** pref
 133 (normally domains that are equal or end in *localhost* or *local*)
 134 -   domains listed in the **network.trr.excluded-domains** pref (chosen by the user)
 135 -   domains that are subdomains of the network\'s DNS suffix
 136 (for example if the network has the **lan** suffix, domains such as **computer.lan** will not use TRR)
 137 -   requests made by Firefox to check for the existence of a captive-portal
 138 -   requests made by Firefox to check the network\'s IPv6 capabilities
 139 -   domains listed in _/etc/hosts_
 140
 141 ## Steering
 142
 143
 144 A small set of TRR providers are only available on certain networks.
 145 Detection is performed in DoHHeuristics.sys.mjs followed by a call to
 146 _TRRService::SetDetectedURI_. This causes Firefox to use the
 147 network specific TRR provider until a network change occurs.
 148
 149 ## User Choice
 150
 151 The TRR feature is designed to prioritize user choice before user agent
 152 decisions. That means the user may explicitly disable TRR by setting
 153 **network.trr.mode** to **5** (TRR-disabled), and that
 154 _doh-rollout_ will not overwrite user settings. Changes to
 155 the TRR URL or TRR mode by the user will disable heuristics use the user
 156 configured settings.