My first impression is that it needs it's own section, as there are quite a few prefs - the main one of course is to block the rollout by default (AFAIK there is a notification panel allowing you to cancel, or at least to let you know). I think the rollout has been limited to the USA so far - but at some stage they will flip it for a lot more (not sure how that works - since I assume most arkenfox English users install en-US builds?)
This is not a debate on this state = good, this state = bad. There are pros and cons to both. It's more about what prefs to add, references, and so on. My initial thoughts are the section header can have some references/info on whether or not DoH is for you (pros/cons) as everyone's threat model will differ, and we can dispel some myths or whatever. And then the only active pref is to block the rollout - thus putting the choice in the hands of the end-user, not some rollout. All other prefs are for those who want to setup their DoH config and use it.
After lots of teething issues and shitloads of bugs and changes, I think DoH is finally ready. IANAE on this shit, so help is appreciated, especially from those using it who know the pitfalls and what configs screw things up etc
FYI: DoH + CNAME cloaking is finally fixed in ESR78.4 and FF82
It's things like this bug, and constant new prefs and pref changes and UI changes etc, why I never wanted to have a DoH section/entries and dealing with the inevitable fallout/issues and it's why I removed what we had about a year ago or whenever it was .. but now I think we can look at adding it back in
edit: typos
I run a private DNS server using AdGuardHome and I've got it set up to accept DNS, DoT, and DoH requests. I've got all my browser profiles set up to use my AdGuardHome instance via DoH.
I cannot for the life of me get Firefox to recognize the network.trr.mode preference set in user.js. It is 100% set in user.js but never gets written to prefs.js. Maybe there is some other setting I need to change for Firefox to capture it from user.js, but If there is I haven't found it.
Oh also if you want to enable encrypted SNI, you must have DoH enabled; otherwise the network.security.esni.enabled preference has no effect whatsoever.
In my opinion this is somewhat well intentioned but ultimately also somewhat annoying. Yes, if you ultimately don't use DoH which site you're visiting is leaked anyways. But someone could be using a local DNS server that accepts regular DNS requests and forwards them over DoH or DoT.
FWIW: My DoH overrides
/*** [SECTION 6750]: DoH ***/
/* 6751: DoH mode ***/
// user_pref("network.trr.mode", 2); // enable TRR (with System fallback)
user_pref("network.trr.mode", 3); // enable TRR (without System fallback)
// user_pref("network.trr.mode", 5); // Disable TRR
/* 6752: DoH resolver
* The second pref is optional for DoH mode 2 and required for mode 3 ***/
user_pref("network.trr.uri", "https://xxxx/dns-query");
user_pref("network.trr.bootstrapAddress", "x.x.x.x");
/* 6753: DoH resolver list
DEFAULT(72): [{ "name": "Cloudflare", "url": "https://mozilla.cloudflare-dns.com/dns-query" }]
DEFAULT(73): "[{ \"name\": \"Cloudflare\", \"url\": \"https://mozilla.cloudflare-dns.com/dns-query\" },{ \"name\": \"NextDNS\", \"url\": \"https://trr.dns.nextdns.io/\" }]"
***/
// user_pref("network.trr.resolvers", "[{ \"name\": \"<NAME1>\", \"url\": \"https://<URL1>\" }, { \"name\": \"<NAME2>\", \"url\": \"https://<URL2>\" }]");
/* 6754: ***/
user_pref("network.dns.skipTRR-when-parental-control-enabled", false);
/* 6755: enable ESNI
* ESNI has nothing to do with DoH, but the implementation in Firefox requires it ***/
user_pref("network.security.esni.enabled", true);
I ignored other prefs such as
network.trr.credentials because I don't need it.network.trr.early-AAAA, network.trr.request_timeout_ms because I don't mess with it.network.trr.send_*_headers, network.trr.disable-ECS, network.trr.allow-rfc1918 because they are Privacy-by-Default.@rusty-snake did setting network.trr.mode in your user.js actually work for you? Because I've never gotten it to work - I've always had to set it in prefs.js
Linux Debian testing - Firefox 80.0.1 64bits
My DoH settings, about:config modifications :
user_pref("network.trr.mode", 2);
user_pref("network.trr.uri", "https://xxxx/dns-query");
user_pref("network.trr.bootstrapAddress", "x.x.x.x");
user_pref("network.dns.skipTRR-when-parental-control-enabled", false);
user_pref("network.security.esni.enabled", true);
user_pref("network.trr.blocklist_cleanup_done", true);
user_pref("network.trr.custom_uri", "https://xxxx/dns-query");
I pick my DoH server from :
https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers
@seonwoolee WFM
That's interesting. What system are you running this on? I'm using the latest Firefox on Arch Linux
Fedora 32 with firefox from page sources. Does it work to set any other pref from this user.js? Is there no typo?
FYI: out of topic
@seonwoolee network.trr.mode WFM as well
do you mind testing something for me?
In case you have search bar enabled in your firefox, disable it in your preferences inside the browser and exit it
Then add this:
user_pref("browser.search.widget.inNavBar", true); // enable search bar
to your user.js, boot up firefox again and tell me if the search bar pops up or not, because when I do this, it doesn't pop up for me
I have this problem on archlinux, but I've had it in other distros as well
@rusty-snake thank you for that, I guess I should've searched it up better
@rusty-snake I have a ton of prefs in user.js that work, just not this one. 100% positive it is not a typo.
Changing it in about:config or prefs.js works and passes a restart, right? Can you try it in a new, clean, empty profile.
I cannot for the life of me get Firefox to recognize the network.trr.mode preference set in user.js
This reminds me of https://github.com/arkenfox/user.js/issues/952#issuecomment-643322391 , where the package was "interfering"
Yes, changing it in about:config and prefs.js works and passes a restart.
I already tested this in a brand new profile. Still can't get Firefox to accept the network.trr.mode value set in user.js
Didn't know about vendor.js but that isn't (or at least shouldn't be) the source of the problem:
$ cat vendor.js
// Use LANG environment variable to choose locale
pref("intl.locale.requested", "");
// Use system-provided dictionaries
pref("spellchecker.dictionary_path", "/usr/share/hunspell");
// Disable default browser checking.
pref("browser.shell.checkDefaultBrowser", false);
// Don't disable extensions in the application directory
pref("extensions.autoDisableScopes", 11);
Nothing in it: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox.
It could also be policies.json or network.dns.skipTRR-when-parental-control-enabled.
Still can't get Firefox to accept the network.trr.mode value set in user.js
Which value?
$ cat /usr/lib/firefox/distribution/policies.json | grep network
"geo.provider.network.url": "",
"browser.region.network.url": "",
"network.connectivity-service.enabled": false,
"network.prefetch-next": false,
"network.predictor.enabled": false,
"network.predictor.enable-prefetch": false,
"network.http.speculative-parallel-limit": 0,
"network.IDN_show_punycode": true
I'm setting it to 3.
Well I'm getting somewhere. If I create a fresh profile and create a single line user.js with just network.trr.mode set to 3, it gets set properly. If I use my custom user.js, which has a bunch of other preferences alongside network.trr.mode set to 3, it doesn't work. And I've made sure I'm not overwriting the preference by setting it multiple times:
$ grep network.trr.mode < user.js
user_pref("network.trr.mode", "3");
Binary search time to find which preference is causing a conflict.
Honestly, this only happened to me a single time and it was when I had this mysterious red dot displayed on my Notepad++, it was apparently a character of some sort I put in accidentally and it was screwing up the pref right next to it
I was pissed off because I went at it for hours when the cause was "right there"...
Never mind, I was an idiot and forgot I need to clear the pref in pref.js first.
Even if I
Firefox still uses network.trr.mode of 0.
I also tried a two line user.js, with
user_pref("network.trr.mode", "3");
user_pref("network.dns.skipTRR-when-parental-control-enabled", false);
The parental control preference was recognized while network.trr.mode was not
grep network.trr.mode < user.js
OT: You can also let grep open the file, no need for a <: grep network.trr.mode user.js
user_pref("network.trr.mode", "3");
This is an integer, works it if you use user_pref("network.trr.mode", 3); instead.
And...I'm an idiot.
I was putting "3", not 3. Firefox was rejecting it as a string.
Sorry for all the ruckus.
perhaps the bigger question is whether Mozilla should be messing with DNS at all
personally i find this fucking offensive, period
this should be done at the OS level, or per application at the users discretion
i really think the broader picture of Mozilla's goals need to be considered here and given the avenues they've been perusing, and rightfully getting their fucking teeth kicked in for, i don't want them messing with DNS
OS level is also a shit due to multihomed name resolution in windows leading to DNS leak. 馃槥
well i'm sure this will offend some here, but it shouldn't; if we're interested in privacy, at all, then we're sure as hell not running windoze
stay on topic please: reminder from the first post: This is not a debate on this state = good, this state = bad
FYI: seems like 1544233: DoH +hosts file was resolved in FF83 by 1616252 .. so that's good. More parity, possible holes fixed etc
I would very much like to see a default of disabling DoH in this. I think it is only a matter of time before Mozilla starts to roll this out as default enabled. On our network we block DoH, but we also use a default user.js based upon the Arkenfox and having this set here helps a lot.
@iio7 that's easy enough ... just set user_pref("network.trr.mode", 5); .. 5 is an explicit do not roll out. That would help with multiple profiles. Otherwise my understanding is that a user gets a doorhanger prompt before DoH is flicked on, and they can cancel it
Thanks @rusty-snake @2glops for your configs 馃憤
ANYONE ELSE .. and I can't stress this enough ... _NOW IS THE TIME TO CONTRIBUTE_ ... links on how DoH, ESNI, bugzillas, what works and what doesn't, known bugs, your configs, anything. It would be cool to get this issue resolved and out of the way. Thanks
good article/summary: https://www.eff.org/deeplinks/2020/12/dns-doh-and-odoh-oh-my-year-review-2020
Most helpful comment
stay on topic please: reminder from the first post: This is not a debate on this state = good, this state = bad