DNS over HTTPS

[jumde]

Test plan

See brave/brave-core#4314

Description

DoH is gaining traction:

https://chromium.googlesource.com/chromium/src.git/+/786929ad1cfbc97962ff5672e2469460ff535f41

https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/

Consider enabling DoH for Brave.

[rht]

There is a flag to enable DoH on Bromite: https://github.com/bromite/bromite/blob/ac44ac738f31a336a00880bdb20a321f04f62c89/patches/BRM061_Add-a-flag-for-DNS-over-HTTPS.patch (note: GPLv3 licensed).

[fmarier]

Cloudflare also offers a Tor hidden service for their DoH resolver: https://blog.cloudflare.com/welcome-hidden-resolver/

[fmarier]

I tested the latest Bromite patch in fmarier/brave-core@fab95d9 and noticed that the DoH stack in Chrome actually falls back to the OS-provided DNS server when the DoH server fails, which was confirmed by
https://www.dnsleaktest.com/. Perhaps it's doing the DNS lookups in parallel, systemd-style.

Do we want to ship this as-is or do we want to ensure that requests are only done via the DoH provider when a user configures it like that? /cc @diracdeltas

[rht]

IMO, in the worst case, if the DoH is doing what systemd DoT does, it still increases redundancy in the resolving method but it would still be better to know the situation: whether Chrome's DoH does the parallel lookup or not.

[diracdeltas]

Nice find @fmarier. Seem that it would be best to offer the user an option of whether they want to fallback to the system DNS (assuming it's falling back, not doing lookups in parallel). If it is doing lookups in parallel, we could clearly communicate it as opportunistic DOH in the UI so people are not surprised by the leaks.

cc @tomlowenthal for thoughts

[tildelowengrimm]

IMO, the default we should be aiming for is DoH without any local resolver use. We should ensure that there are no local leaks. But there should be an easy switch to move to a local resolver instead. Opportunistic DoH feels like the worst of both worlds.

[mKoonrad]

Why DoH, not DoT? DoH is better? This is my general question about encrypted DNS service.

[tildelowengrimm]

There's a small minority of people for whom running Tor can be a hazardous proposition, so we're not planning to default to that. DoHoT makes sense when using private windows with Tor, though.

[mKoonrad]

So will Brave have DoH or DoT? If yes, which version?

[tildelowengrimm]

My plan is to implement DoH for general browsing, and DoHoT for private windows with Tor and other backend services if someone flips the "Use Tor for background connections." switch. But that's only a plan so far — we haven't started implementing and things can change based on the technical realities.

[tildelowengrimm]

@fmarier How're these changes going to be affected by the NetworkService migration in Chromium (#2351)?

References:

• https://www.chromium.org/servicification
• https://bugs.chromium.org/p/chromium/issues/detail?id=598073

[csagan5]

I tested the latest Bromite patch in fmarier/brave-core@fab95d9 and noticed that the DoH stack in Chrome actually falls back to the OS-provided DNS server when the DoH server fails, which was confirmed by
https://www.dnsleaktest.com/. Perhaps it's doing the DNS lookups in parallel, systemd-style.

Do we want to ship this as-is or do we want to ensure that requests are only done via the DoH provider when a user configures it like that? /cc @diracdeltas

I actually noticed this some time ago in the Chromium codebase and played around a bit trying to disable it or make it an option, without success; looks like somebody else upstream was aware too because there is now this patch available: https://chromium.googlesource.com/chromium/src/+/c7bed520a42ee26aa3be1da89aad737bb54c0fab

Starting from Bromite 73.0.3683.79 it will be shipped in the SECURE mode by default, as I could not easily find a way to have a flag for it (possible modes are: OFF, SECURE, AUTOMATIC).

Perhaps it's doing the DNS lookups in parallel, systemd-style.

@fmarier no, from my interpretation of the retry loops (see dns_transaction.cc) it uses the UDP/TCP attempt as a fallback when the HTTP attempt fails (this is confirmed by some source code comments there); it is however not clear how/when the HTTP attempts would be tried again. From empirical evidence I can see that switching networks is one way to trigger them anew.

All of this is thankfully no more relevant with the secure mode enabled by default.

[fmarier]

Thanks for the extra pointers @csagan5.

Noting that the patch landed in chromium 74.0.3705.0.

[csagan5]

This is the tiny patch I wrote to enable secure mode by default (to be used after the upstream patch previously mentioned):

• https://github.com/bromite/bromite/blob/73.0.3683.79/build/patches/Enable-secure-DNS-mode-by-default-in-DnsTransaction.patch

It will be used in Bromite until there is either a chrome://flags flag or some other configurable user option.

[fmarier]

This might be relevant too: https://www.chromium.org/administrators/policy-list-3#BuiltInDnsClientEnabled

[fmarier]

No word on linux support.

According to this Chromium blog post, support for Android and Linux is coming soon.

[tunnckoCore]

@fmarier thanks :)