ToDo: DoH section or entries

[Thorin-Oakenpants]

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

[seonwoolee]

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.

[seonwoolee]

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.

[rusty-snake]

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.

[2glops]

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

[Thorin-Oakenpants]

stay on topic please: reminder from the first post: This is not a debate on this state = good, this state = bad

[Thorin-Oakenpants]

FYI: seems like 1544233: DoH +hosts file was resolved in FF83 by 1616252 .. so that's good. More parity, possible holes fixed etc

[iio7]

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.

[Thorin-Oakenpants]

@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

[Thorin-Oakenpants]

good article/summary: https://www.eff.org/deeplinks/2020/12/dns-doh-and-odoh-oh-my-year-review-2020

[Thorin-Oakenpants]

note: network.security.esni.enabled removed in FF85
edit: https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

[gitthehubs]

Securing DNS is a good thing, although it can conflict with some anti virus applications that check DNS traffic. The question is more if using the current DoH implementations in internet browsers is the best solution? Personally I don't think it is wise the redirect DNS traffic from internet browsers to just a few DNS providers, it centralises DNS for the internet browsers to just a few DNS providers and that is my main concern.
The best solution, in my opinion, would be that the operating system is supporting secure DNS protocols and that the DNS servers from your internet provider supports secure DNS protocols. Sadly is not going very well, there are operating systems that do support secure DNS protocols, but the other server part on the internet providers don't seem to go very quickly in supporting secure DNS. I know android support DoH, I have red IOS 14 and MacOS would support DoH and DNSoverTLS. I know Linux is supporting it(if I'm right). Microsoft is wirking on implementing DoH in Windows 10, but not yet officially released.

Another issue is that current DoH providers in internet browsers don't always redirect you to the nearest datacenter where you local DNS servers from your providers do(I assume). I noticed that with some social media site I got redirected to another country while that web site had it's own datacenter in my own country.

So personally I don't use Firefox' DoH.

I do use secure DNS, but I run my own DNSCrypt application and use multiple secure, DNSCrypt, DNSSEC, no logging, no filtering, DNS servers in my own country to load-balance my DNS queries to.

[gitthehubs]

@Thorin-Oakenpants

note: network.security.esni.enabled removed in FF85
edit: https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

Are you, and if so when, going to add these new prefs?
user_pref("network.dns.echconfig.enabled", true);
user_pref("network.dns.use_https_rr_as_altsvc", true);

[Thorin-Oakenpants]

IDK, are they somehow important?

[gitthehubs]

IDK, are they somehow important?

Well, read your own link. 😛 😄
https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

But, quote:

Though we recommend that users wait for ECH to be enabled by default, some may want to enable this functionality earlier.

But I don't know how long that will take, users who already used the pref network.security.esni.enabled:true can consider to enable ECH already manually.

[Thorin-Oakenpants]

this is not something that is going to happen any time soon, DoH is super low priority and I refuse to do it myself - hence why I nagged you to say why they are important: read OP, why do I have to always do everything, including looking it up and searching for how it is used in DoH and all that - there was an earlier smallish DoH prefs in the user.js about two years ago which in the end I ripped out precisely because I was left holding the bucket, and there were too many bugs/changes - I'm not going back to that

• https://bugzilla.mozilla.org/show_bug.cgi?id=1649372 .. 82 open bugs, and roll-out (excluding USA) has been just around the corner for two years... maybe it will never happen
• e.g. this issue is already five months old and it's gotten nowhere. AFAIC, it's a dead issue, but I'll leave it open here for all eternity

[rusty-snake]

BTW: Does anyone know if/how network.dns.use_https_rr_as_altsvc conflicts with 0703 where network.http.altsvc.enabled=false. This should be checked too, if you add it to your user(-overrides).js.

[2glops]

DoH, ODoH, xDoH ?

For sure, it's time to wait and see :
https://blog.cloudflare.com/oblivious-dns/
https://techpp.com/2020/12/14/odoh-oblivious-dns-over-https-explained/

[gitthehubs]

@Thorin-Oakenpants

I was just a little bit confused why you asked if the new prefs were somewhat important. Because the user.js had the pref network.security.esni.enabled it was sort of logical, well to me, to use the new prefs for ECH, ECH is the successor of ESNI. And because you added the link to the article about ECH replacing ESNI I was just wondering if you red your own link else you wouldn't ask if the new prefs were somewhat important, well that was my thinking. If you used ESNI you would now want to use ECH is my opinion.
But maybe I interpreted the question wrong, was it in general speaking or did you ask for my personal opinion. Maybe I went wrong on that. Sorry if so.
I hope this clarifies it a bit. 😄

And FYI, I did read the OP, I was merely commenting on it because you commented about removing the ESNI pref network.security.esni.enabled from the user.js. It triggerd me to ask if the ECH prefs should be added as a replacement.
And I gave my opinion about the new ECH prefs, but I must agree it may not be that clear. I quote:

But I don't know how long that will take, users who already used the pref network.security.esni.enabled:true can consider to enable ECH already manually.

If you used ESNI you now want ECH and don't wait till Mozilla makes it default. Although I understand it is a TLS 1.3 extension and web servers have to support it, but that was the case with ESNI also that web servers have to support it.

this is not something that is going to happen any time soon, DoH is super low priority and I refuse to do it myself - hence why I nagged you to say why they are important

FYI2, ESNI/ECH have nothing to do with DoH. ESNI/ECH are TLS extensions. It are two different ways to hide which site you are visiting, one is in the DNS traffic and the other is in the TLS traffic.

e.g. this issue is already five months old and it's gotten nowhere. AFAIC, it's a dead issue, but I'll leave it open here for all eternity

I noticed this, but because of the 'recent' comments in january I though it was ok to comment and give my thought about DoH. You asked for input, I gave mine.

[rusty-snake]

FYI2, ESNI/ECH have nothing to do with DoH. ESNI/ECH are TLS extensions. It are two different ways to hide which site you are visiting, one is in the DNS traffic and the other is in the TLS traffic.

Firefox esni implementation required DoH to be enabled. With network.security.esni.enabled=true and network.trr.mode=0 (or 5) esni was disabled.

[gitthehubs]

@rusty-snake

Firefox esni implementation required DoH to be enabled. With network.security.esni.enabled=true and network.trr.mode=0 (or 5) esni was disabled.

That is done by Mozilla, it has no use of encrypting you SNI while your DNS is not encrypted and still exposing which site you are visiting.

[gitthehubs]

@rusty-snake

BTW: Does anyone know if/how network.dns.use_https_rr_as_altsvc conflicts with 0703 where network.http.altsvc.enabled=false. This should be checked too, if you add it to your user(-overrides).js.

I could be wrong, so no guarantees. But I would say it are two different things.
network.http.altsvc.enabled
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Alt-Svc

The Alt-Svc HTTP response header is used to advertise alternative services through which the same resource can be reached. An alternative service is defined by a protocol/host/port combination.

network.dns.use_https_rr_as_altsvc
https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

ECH also changes the key distribution and encryption stories: A TLS server supporting ECH now advertises its public key via an HTTPSSVC DNS record, whereas ESNI used TXT records for this purpose.

[Thorin-Oakenpants]

Because the user.js had the pref network.security.esni.enabled

never had it, doesn't have it now. I only mentioned it was being removed since it was in rusty's overrides

[gitthehubs]

@Thorin-Oakenpants

never had it, doesn't have it now. I only mentioned it was being removed since it was in rusty's overrides

Than that is a misunderstanding on my side, sorry for that.
I had the pref in my personal user.js, so I assumed it came from your user.js, apparently I had the pref from somewhere else.

[rusty-snake]

@gitthehubs you seem to be right. Looks like it is inspired by AltSvc but different. (https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-httpssvc-03.html#name-relationship-to-alt-svc).

[Thorin-Oakenpants]

https://blog.mozilla.org/en/mozilla/news/firefox-by-default-dns-over-https-rollout-in-canada/

so after 2+ years .. rollout is so far .. USA .. and Canada about to start .. so glad I ignored all of this for 2 + years

[Thorin-Oakenpants]

doh-rollout.home-region will reveal your region

My main FF (portable with user.js) shows US - I suspect from the fact that it is A) an en-US build B) prefs in user.js force me to en-US and region updates are disabled (I am not US) - see section 0200. In my portable test FF's, which are practically vanilla for testing, the pref value is my real country

Not sure why I've never seen a prompt or been rolled out to: maybe from the old pref when it was in the user.js, or maybe I had the xpi removed (I don't bother anymore as it forces a full download to update via the app)

So sorry all you sucker loser en-US arkenfox users, while I was busy working from early in the morning until late in the evening and making many phone calls and having many meetings, the boat sailed (probably from Florida full of superspreaders) and you were already rolled out .. lulz 🤣

---

I plan to close this before release 91 (for ESR). I will add the basic rollout pref (inactive), point to the UI, and reference some links. That's it. Just giving you all the heads up in case anyone wants to add anything after 2+ years

[Thorin-Oakenpants]

notes to self:

• https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/
• maybe: https://www.eff.org/deeplinks/2020/12/dns-doh-and-odoh-oh-my-year-review-2020
• maybe: https://wiki.mozilla.org/Security/DOH-resolver-policy
• maybe: https://www.privacytools.io/providers/dns/

@rusty-snake I don't use DoH because I live in a utopian non-shit non-3rd-world country which values privacy ... do you have any other links or info, like test pages - etc - e.g. https://old.reddit.com/r/privacytoolsIO/comments/cplstn/doh_confirmation_test/ ?

[rusty-snake]

Actually you can use any dns-leak test like https://browserleaks.com/dns or https://www.dnsleaktest.com/ though the results can be confusing.

There are two support pages, not sure if they are relevant.
https://support.mozilla.org/en-US/kb/firefox-dns-over-https
https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs

https://www.cloudflare.com/ssl/encrypted-sni/

Since firefox remove esni, ...