Deploy360 26 December 2018

DNS-over-HTTPS (DoH) Support in Mozilla Firefox

By Kevin MeynellFormer Senior Manager, Technical and Operational Engagement
Fernando GontGuest Author

Recent releases of Firefox have introduced the concept of DNS privacy under the name “Trusted Recursive Resolver”. Although Firefox ships with DNS-over-HTTPS (DoH) disabled by default, there has been some discussion within the Mozilla developer community about changing the default to “enabled”.

Although DoH is somewhat controversial because it moves control plane (signalling) messages to the data plane (data forwarding), and can thereby bypass local network policies, DoH advocates argue that it makes it harder to block or monitor DNS queries which is a commonly used method for restricting access to the Internet and/or monitoring user behaviour.

But putting these arguments aside, if you want to try out DoH then the DNS privacy (or “TRR” in Firefox speak) configuration in Firefox can be accessed as follows:

  • Enter “about:config” in the address box of the browser
  • Search for “trr” (without quotes)

A sample output of DNS privacy configuration in Mozilla Firefox is as follows:

Firefox offers its technical users quite a few settings to play with, but the most important options (along with their recommended settings) for TRR are:

  • trr.bootstrapAddress:(empty)
  • trr.mode: 3
  • trr.uri: https://mozilla.cloudflare-dns.com/dns-query

“network.trr.bootstrapAddress” specifies the IP address of a recursive resolver that should be employed to obtain the address of the DoH resolver specified using the “network.trr.uri” variable.

For modes other than “3”, Firefox will employ any DNS servers learned from DHCP. However, when mode “3” is selected, queries are not sent by default to any non-DoH resolver, and hence it is necessary to specify the address of a DNS resolver to be able to “bootstrap” DNS privacy.

Setting network.trr.mode to “3” sets “strict” resolution – meaning only DoH will be employed, with no fall back mechanism. This is a sensible option, since it prevents downgrade attacks.

Finally, network.trr.uri allows the selection of a DoH server/resolver.

The resulting configuration is:

In order to check whether TRR has been successfully enabled, it’s possible to use a protocol analyzer, as follows:

  • Check the network for traditional DNS traffic – this means packets destined for TCP port 53 or UDP port 53. If DoH has been successfully enabled, you should see no traffic from the local node to those ports
  • Check the network for DoH traffic – that means packets destined for TCP port 443 of the IP address(es) corresponding to the DoH resolver in the “network.trr.uri” variable. If DoH has been successfully enabled, you should probably see traffic to this port.

A more interesting way of checking the status of TRR is to employ the Firefox’ “about:networking”  experimental interface. This allows access to internal networking-related features, and can be accessed by entering the aforementioned string (without quotes) in the address box – with the DNS cache being directly available at “about:networking#dns”.

The following figure shows a sample output of the DNS cache:

The first column contains the list of cached domain names, while the second column indicates the protocol family employed (IPv4, in all of our domain names). The third column specifies whether TRR (DoH) was employed for DNS resolution, as if it has been enabled on the browser since we ran it, all of the entries in the DNS cache should have the third column set to “true”.

The fourth column specifies the addresses resulting from DNS resolution, while the fifth column specifies the current “time-to-live” of each entry (in seconds) before the entry is purged from the cache.

Firefox TRR Configuration variables

Whilst we only need to set three configuration variables to enable TRR, Firefox offers a range of other options for tuning it:

  • trr.allow-rfc1918: false (boolean)
    • Firefox will only allow RFC1981 addresses in TRR responses if this flag is set to “true”
  • trr.blacklist-duration: 60
    • Number of seconds a domain will be kept in a “blacklist” when resolution does not work with TRR, but works with a normal resolver.
  • trr.bootstrapAddress:
    • Address of a recursive resolver to obtain the address of the server specified in “network.trr.uri”
  • trr.confirmationNS: example.com
    • Firefox will try to do DNS resolution to check that TRR is working properly
  • trr.credentials:
    • Credentials to be used in the “Authorization” request header
  • trr.disable-ECS: true (boolean)
    • Disable sending EDNS Client Subnet (ECS) information to authoritative servers.
  • trr.early-AAAA: true (boolean)
    • Firefox normally sends both A and AAAA queries in paralell. It will only use AAAA records if they arrive first and this flag is set to true
  • trr.max-fails:
    • Number of times after which Firefox should give up on TRR resolution for a given domain name
  • trr.mode: 0
    • 0: Off – use normal resolver and don’t use TRR
    • 1: Race – do TRR and normal resolution in parallel, and use whatever answer comes first
    • 2: First – use TRR, and fall back to normal resolver if it fails
    • 3: Only – Only use TRR, and never use normal resolver (after initial setup)
    • 4: Shadow – Do TRR in parallel with normal resolver (for measurements) but only use results from normal resolver5: Off by choice – same as “0”, but represents explicit decision to disable TRR
  • trr.request-timeout: 3000
    • Time value in seconds after which a TRR query is considered to have failed
  • trr.uri: https://mozilla.cloudflare-dns.com/dns-query
    • URI to be employed for DNS resolution
  • trr.useGET: false (boolean)
    • Whether to use GET rather than POST method.
  • trr.wait-for-portal: true (boolean)
    • Whether to wait for captive portal detection before using DoT

Further Information

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...