Instantly share code, notes, and snippets.

Embed
What would you like to do?
trr prefs

NOTE

A blog post with more updated info then this has been posted here

Preferences

All preferences for the DNS-over-HTTPS functionality in Firefox are located under the "network.trr" prefix (TRR == Trusted Recursive Resolver). The support for these are targeted for shipping in release Firefox 62.

network.trr.mode

set which resolver mode you want.

0 - Off (default). use standard native resolving only (don't use TRR at all)

1 - Race native against TRR. Do them both in parallel and go with the one that returns a result first.

2 - First. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.

3 - Only. Only use TRR. Never use the native (after the initial setup).

4 - Shadow. Runs the TRR resolves in parallel with the native for timing and measurements but uses only the native resolver results.

5 - Off by choice This is the same as 0 but marks it as done by choice and not done by default.

network.trr.uri

(default: none) set the URI for your DOH server. That's the URL Firefox will issue its HTTP request to. It must be a HTTPS URL. If "useGET" is enabled, Firefox will append "?ct&dns=...." to the URI when it makes its HTTP requests. For the default POST requests, they will be issued to exactly the specified URI.

Publicly announced servers include:

network.trr.credentials

(default: none) set credentials that will be used in the HTTP requests to the DOH end-point. It is the right side content, the value, sent in the Authorization: request header.

network.trr.wait-for-portal

(default: true) set this boolean to tell Firefox true to wait for the captive portal detection to okay first before TRR is used. (on Android, this will default to false since the captive portal handling is done outside of Firefox, by the OS itself.)

network.trr.allow-rfc1918

(default: false) set this to true to allow RFC 1918 private addresses in TRR responses. When set false, any such response will be considered a wrong response that won't be used.

network.trr.useGET

(default: false) When the browser issues a request to the DOH server to resolve host names, it can do that using POST or GET. By default Firefox will use POST, but by toggling this you can enforce GET to be used instead.

network.trr.confirmationNS

(default: example.com) Firefox will check an NS entry at startup to verify that TRR works to ensure proper configuration. This preference sets which domain to check. The verification only checks for a positive answer, it doesn't actually care what the response data says. Set this to skip to completely avoid confirmation.

network.trr.bootstrapAddress

(default: none) by setting this field to the IP address of the host name used in "network.trr.uri", you can bypass using the system native resolver for it.

network.trr.blacklist-duration

(default: 60) is the number of seconds a name will be kept in the TRR blacklist until it expires and then will be tried with TRR again. The default duration is one minute.

Entries are added to the TRR blacklist when the resolve fails with TRR but works with the native resolver, or if the subsequent connection with a TRR resolved host name fails but works with a retry that is resolved natively. When a host name is added to the TRR, its domain gets checked in the background to see if the whole domain should be blacklisted to ensure a smoother ride going forward.

network.trr.request-timeout

(default: 3000) is the number of milliseconds a request to and corresponding response from the DOH server is allowed to take until considered failed and discarded.

network.trr.early-AAAA

(default: false) For each normal name resolve, Firefox issues one HTTP request for A entries and another for AAAA entries. The responses come back separately and can come in any order. If the A records arrive first, Firefox will - as an optimization - continue and use those without waiting for the second response. If the AAAA records arrive first, Firefox will only continue and use them immediately if this option is set to true.

Does it work?

Go to about:networking, click the DNS link in the left-side menu. That shows the contents of the in-memory DNS cache. The TRR column says "true" for host names that were resolved using TRR (DNS-over-HTTPS).

I found a bug!

If you experience a problem or find a host name that has problems with TRR, consider extracting logs from Firefox during the hiccup by asking for nsHostResolver:5 logs as instructed on the HTTP logging page and submit a bug report

@wellington1993

This comment has been minimized.

wellington1993 commented Jun 4, 2018

Thanks!

@zsnmwy

This comment has been minimized.

zsnmwy commented Jun 8, 2018

Thanks!
It's useful for me.

@mdavids

This comment has been minimized.

mdavids commented Jun 22, 2018

Thanks.
I was wondering if the web developer tools or some other tool in FF have an option to follow the DoH queries. I would like to see the actual HTTP-request.

@VonNaturAustreVe

This comment has been minimized.

VonNaturAustreVe commented Jun 29, 2018

thanks!

@cleanbrowsing

This comment has been minimized.

cleanbrowsing commented Jul 13, 2018

Awesome! Would add that CleanBrowsing also has 3 public DoH endpoints:

Family filter (blocks adult content + proxies + enforces safe search + strict mode on youtube)
https://doh.cleanbrowsing.org/doh/family-filter/

Adult filter (blocks adult content)
https://doh.cleanbrowsing.org/doh/adult-filter/

Security filter (blocks malware and phishing):
https://doh.cleanbrowsing.org/doh/security-filter/

@iphorde

This comment has been minimized.

iphorde commented Aug 6, 2018

Who thought this would be a good idea? Do you work for Cloudflare? Once upon a time this kinda thing was posted as an RFC. Now people just implement stupid ideas without first talking it over.

@rugk

This comment has been minimized.

rugk commented Aug 6, 2018

More servers are here: https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers

Also I am not sure whether this gist is still up-to-date, but:

The support for these are targeted for shipping in release Firefox 62.

So it won't be enabled in this version?

@enygren

This comment has been minimized.

enygren commented Aug 6, 2018

Why is network.trr.early-AAAA set to false by default? How does this relate to the rest of the Happy Eyeballs implementation? The best practice is / should be to try and use IPv6 from AAAA responses unless IPv4 is measured to be significantly better. Using a faster DNS response for A records is a poor reason to select using IPv4. See RFC8305 for current best-practices.

@uBlock-user

This comment has been minimized.

uBlock-user commented Aug 7, 2018

Google DNS doesn't work in TRR mode 3, domains don't get resolved at all, Firefox says Server not found. Why ?

@phonphen

This comment has been minimized.

phonphen commented Aug 10, 2018

@uBlock-user

go to https://dns.google.com/query?name=dns.google.com&type=A&dnssec=true

resolve ip address for dns.google.com
for example 74.125.68.101

then insert in about:config network.trr.bootstrapAddress

then TRR mode 3 should work for google DNS

@uBlock-user

This comment has been minimized.

uBlock-user commented Aug 28, 2018

@phonphen I inserted 8.8.8.8 and it still doesn't work, probably an issue with Firefox itself.

@hong620

This comment has been minimized.

hong620 commented Sep 6, 2018

I'm little confuse on Cloudflare's URI

https://mozilla.cloudflare-dns.com/dns-query
dump me to
104.16.112.25 US

and
https://cloudflare-dns.com/dns-query
that description in mozilla's wiki https://wiki.mozilla.org/Trusted_Recursive_Resolver
is dump me to closer regional properly.
1.1.1.1 AUS

i dunno much on tech aside but tested both with Force mode(3) and seems alright on both.
so i've choose closer regional one.
during FF60~61 period is quite broken and not worked well. now seems works fine with FF62 i guess.

@tscpd

This comment has been minimized.

tscpd commented Sep 6, 2018

I'm little confuse on Cloudflare's URI

To use Mozilla's TRR you have to use https://mozilla.cloudflare-dns.com/dns-query - this activates Mozilla's strong privacy agreement on servers operated by cloudflare. Those are located all over the world. You dont have to think about "closer regional"!

and https://cloudflare-dns.com/dns-querythat description in mozilla's wiki https://wiki.mozilla.org/Trusted_Recursive_Resolver

I guess that should indeed be changed in mozilla's wiki!

@hong620

This comment has been minimized.

hong620 commented Sep 9, 2018

@tscpd

Yeah, 1.1.1.1 or 104.16.112.25 or whichever already Cloudflare's DNS is fastest and less latenrcy then other DNS for most of users living in asia-pacific regions so which ever pick doesn't affect much.

but one thing i'm really confused is when bootstrapAddress setted in major address they anounced as '1.1.1.1', then that Mozilla base uri(not the 1.1.1.1 one) could be discordant beside those two values, and this could be a make a 'issue depends on user's regional so make hard to tracking causes'

theoretically this is should be describe clearly by Mozilla themself..
anyone got a contacts or know persons in that part?

bugzilla couldn't be good for asking this..

@tscpd

This comment has been minimized.

tscpd commented Sep 14, 2018

but one thing i'm really confused is when bootstrapAddress setted

In the most cases the value bootstrapAddress can be empty! Its initially resolving https://mozilla.cloudflare-dns.com/dns-query to a IP. You can set any valid DNS e.g. 8.8.8.8 or 1.1.1.1

@hong620

This comment has been minimized.

hong620 commented Sep 14, 2018

but one thing i'm really confused is when bootstrapAddress setted

In the most cases the value bootstrapAddress can be empty! Its initially resolving https://mozilla.cloudflare-dns.com/dns-query to a IP. You can set any valid DNS e.g. 8.8.8.8 or 1.1.1.1

so.. that means trr.uri is always priority to check resolver by web browser(ff in this case) so bootstrapAddress isn't important to put value on there right?

@nanake

This comment has been minimized.

nanake commented Sep 21, 2018

@phonphen I inserted 8.8.8.8 and it still doesn't work, probably an issue with Firefox itself.

You have to make sure that dns.google.com resolve to 8.8.8.8.

dns.google.com NEVER resolve to 8.8.8.8 for me but 172.217.31.110. that's why you can't use 8.8.8.8 as bootstrapAddress.

@nanake

This comment has been minimized.

nanake commented Sep 21, 2018

but one thing i'm really confused is when bootstrapAddress setted

In the most cases the value bootstrapAddress can be empty! Its initially resolving https://mozilla.cloudflare-dns.com/dns-query to a IP. You can set any valid DNS e.g. 8.8.8.8 or 1.1.1.1

[...] so bootstrapAddress isn't important to put value on there right?

it is, i'm afraid. if you choose TRR mode 3.

@hong620

This comment has been minimized.

hong620 commented Sep 22, 2018

but usually TRR mode 2 recommanded for common users. 🤔
so anyway leave it(bootstrapAddress) empty for now.. is best?

some of dns packet detect & manipulate nation's users need to proper test on these settings if there's further change on values.
as i've confirm, Android Firefox is flush those values on every application updates..
so highly suggest this website for test dnsleak after every trr settings apply.

https://dnsleaktest.com/

@tscpd

This comment has been minimized.

tscpd commented Oct 3, 2018

but usually TRR mode 2 recommanded for common users. thinking

yes

so anyway leave it(bootstrapAddress) empty for now.. is best?

Leave empty will use the system native resolver. Should work "best" in the most cases: It will most likely be the ISP of your current connection.

@mjuarezm

This comment has been minimized.

mjuarezm commented Oct 30, 2018

It seems trr prefs don't work when FF is driven by selenium, anybody experienced the same issue?

I use this script below but they don't even work when I set them manually:

from selenium import webdriver

#resolver_url = 'https://mozilla.cloudflare-dns.com/dns-query'
resolver_url = 'https://dns.google.com/experimental'

fp = webdriver.FirefoxProfile()
fp.DEFAULT_PREFERENCES['frozen']["network.trr.mode"] = 2
fp.DEFAULT_PREFERENCES['frozen']["network.trr.uri"] = resolver_url

driver = webdriver.Firefox(firefox_profile=fp)
driver.get('http://facebook.com')
driver.quit()

The screenshot below is an example: same FF version, same trr prefs in about:config, but the one on the left is driven by selenium and it uses the system's DNS server instead of Google's:

screenshot_2018-10-30_14-02-13

@fgont

This comment has been minimized.

fgont commented Nov 13, 2018

Question:

Could you confirm what "network.trr.max-fails" is about? I assume that it's the maximum number of retransmissions after giving up resolution for the current domain name -- the timeout for each query being network.trr.request-timeout millisec.

So essentially resolution of a name will fail after
Fail=network.trr.request-timeout * network.trr.max-fails

?

@mdavids

This comment has been minimized.

mdavids commented Nov 14, 2018

Good stuff, thanks. What about the 'network.trr.disable-ECS' option?

@Atavic

This comment has been minimized.

Atavic commented Nov 18, 2018

network.trr.disable-ECS If set, TRR asks the resolver to disable ECS (EDNS Client Subnet). Some resolvers will use ECS to the upstream if this request is not passed on to them.

https://daniel.haxx.se/blog/2018/06/03/inside-firefoxs-doh-engine/
https://bugzilla.mozilla.org/show_bug.cgi?id=1466462

@tristanmorgan

This comment has been minimized.

tristanmorgan commented Dec 6, 2018

Another one to add to the list of possible resolvers (network.trr.uri) is Quad9's DoH service.
https://dns9.quad9.net/dns-query
or for no malicious blocking...
https://dns10.quad9.net/dns-query

with the boostrap IPs of 9.9.9.9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment