* DNS over HTTPS (DoH)
* DNS over TLS (DoT)
TL;DR: It looks like DoT probably achieves much the same thing but may have more support through standardized implementations at least compared to DNSCrypt. I disregarded the top comment's opinion about DoH since their position is likely influenced by their state of competition with Cloudflare.
DoH back then I think only have a Google DNS flavor which send request as human readable POST data or query string and respond in JSON.
Since then the DoH has been standardized under RFC 8484 (not final yet) and switched to use DNS wire format.
DoT may have wider support right now due to 1) Android P have built-in support, and 2) Debian 10 uses subby as local DNS cache which send upstream request over DoT.
But I think DoH is catching up since Firefox and now Chrome are going to support it. I would assume Apple and Microsoft would follow along and add the DoH support to their browsers.
I think DoHs will end up being the standard that 'wins' as such because DoT can be banned by governments who do not want you doing it.
In addition to that I can see at some point DoHs becoming DNS over QUIC. It seems as if QUIC is now a part of HTTP/3 so that's quite likely.
When the standards finalize:
What is interesting is DNSCrypt https://dnscrypt.info/faq also acknowledge that fact under the section for DoHS:
"Will automatically benefit from improvements made to HTTP/2 and, eventually, QUIC"
Web sites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for curvedns.on2it.net. The certificate is only valid for the following names: www.github.com, .github.io, .githubusercontent.com, *.github.com, github.com, github.io, githubusercontent.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN
It appears that DNSCurve is the protocol, and CurveDNS is an implementation.
And the official page for the protocol seems to reside at http://www.dnscurve.org.
What a mess.
The official GH docs at https://help.github.com/en/articles/using-a-custom-domain-wi... don't seem to talk about it (any more?) as opposed to the web UI way of setting the custom domain. There is a small mention at https://help.github.com/en/articles/troubleshooting-custom-d...
If true, anyone have some examples of who is doing that?
See code, documentation and examples at https://github.com/Cofyc/dnscrypt-wrapper
# send end-to-end encypted DNS queries to/from an authoritative DNS server
# send query for example.com to root server using stub resolver (drill)
# authoritative DNS server (e.g., tinydns, nsd, etc.) listening on 127.0.0.1:53, serving root.zone from ftp.internic.net
# dnscrypt-wrapper listening on 127.0.0.1:530
# dnscrypt-proxy listening on 127.0.0.1:5300
# could have dnscache or unbound forwarding to the dnscrypt-wrapper listening address
dnscrypt-wrapper --gen-provider-keypair --provider-name=2.dnscrypt-cert.root.zone --ext-address=127.0.0.1:530
dnscrypt-wrapper --gen-crypt-keypair --crypt-secretkey-file=1.key
dnscrypt-wrapper --gen-cert-file --crypt-secretkey-file=1.key --provider-cert-file=1.cert --provider-publickey-file=public.key --provider-secretkey-file=secret.key
dnscrypt-wrapper -r 127.0.0.1:53 -a 127.0.0.1:530 --provider-name=2.dnscrypt-cert.root.zone --crypt-secretkey-file=1.key --provider-cert-file=1.cert -p 1.pid &
k=$(dnscrypt-wrapper --show-provider-publickey|sed 's/Provider public key: //');
dnscrypt-proxy --provider-key=$k -a 127.0.0.1:5300 -r 127.0.0.1:530 --provider-name=2.dnscrypt-cert.root.zone -p 2.pid &
drill example.com -p5300 @127.0.0.1
read a < 1.pid
read b < 2.pid
rm 1.key 1.cert public.key secret.key 1.pid 2.pid
Wish it was bundled with the official build though.
Using someone else's resolver (secure transport or not) just changes who you're leaking the information to, not the fact that you're leaking.
They don't. As you can leak all your information to a single party or leak smallest necessary bits of information to each of many independent parties to the point where no single party can make any use of it or even decode it alone.
Naturally for DNS encrypting communications to authoritative servers can actually improve privacy, while encrypting communications to a big centralized third party resolver and using it only has a negative effect on privacy.
1. securing client - recursive resolver traffic 2. trusting the recursive resolver 3. securing recursive-authoritative traffic.
1. and 2. can both be solved by running your own resolver, either locally, on your gateway or on a VPS reachable via VPN. But doing so makes you more vulnerable to 3. since fewer devices will be pooled behind a single resolver. Thus fixing 3 gives fundamentally a better improvement than futzing around with 1 or 2 where you're still at the mercy of a 3rd party.
If you're serious about privacy then DoH/DNSCrypt-via-quad9/cloudflare/etc. just seem like a distraction. I mean sure, encrypting that traffic by default is not bad, but it's not a fundamental improvement.
Also, I wouldn't say I trust my ISP, but at least it is under a GDPR jurisdiction. All the big resolvers that advertise encryption are under US jurisdiction, which makes any privacy promises seem hollow.
DNS is really the last bastion of government interference. The UK is supposed to be rolling out a nation-wide porn block at some point but it will be totally defeated by encrypted DNS.
Firefox shows the error "Secure Connection Failed. An error occurred during a connection to 'site url'. PR_CONNECT_RESET_ERROR". When I search for this error, one of the first results say "this behavior is fairly typical for DPI firewalls".
To anyone knowledgeable about this: How can I confirm if my ISP is using DPI?
In about:config set network.trr.mode=3, network.security.esni.enabled=true, security.OCSP.enabled=0, security.tls.version.max=4, security.tls.version.min=4.
Exit, open Firefox again; if the website loads, then your ISP is using a DPI middlebox.
I checked 3 blocked sites after enabling the options you suggested. They were still blocked. I confirmed all 3 didn't have TLS 1.3 by testing them with ssllabs ssltest. All had results show TLS 1.3 as "No".
Or.. your ISP might be blocking the IPs.
Remember to revert the settings to the original values.
Except in practice, you as an end-user seldomly have enough information or knowledge to determine if you should trust an entity or not - in fact, is often already expert knowledge to know how many entities are involved.
Which is why practically, this question is decided by who has the most power - such as Mozilla in this case deciding all their users should trust Cloudflare.
You're absolutely right, in the end, trust is what everything boils down to. I'd consider this an open issue and one of the root causes of many of the internet's problems.
If you're using a VPN for privacy reasons you have to set it up properly of course. On linux network namespaces can help with that where you can make sure that default namespace goes through your VPN and your ethernet device gets moved to a separate namespace that applications don't even see by default.
I might look at trying Pi-hole eventually instead of Unbound to do DNS level ad/tracker blocking but I'll keep Stubby there to do the DoT.
It’s useful Firefox has the option to enable dns over https for users who do not run their own dns, dnscrypt, stubby servers etc but it should absolutely be opt in otherwise it’s bypassing any custom dns servers setup already.
I run a small OpenBSD router with stubby for dns over tls and unbound for caching. Unbound is also loaded with a dns blocklist for adblocking/malicious site blocking which unfortunately would get bypassed automatically by browser defaults.
OpenBSD just patched Firefox to disable doh by default.
Good news you can add DNS records which informs Firefox to disable DoH: https://news.ycombinator.com/item?id=20913248
> OpenBSD just patched Firefox to disable doh by default.
People never seem to get it or admit it up front, but OpenBSD consistently seem to be making the right choices all the way.
It's also worth noting that OpenBSD is used by a relevantly small number of users, when you consider everyone in the world. Out of those users I would bet close on 100% of them actually know what DNS is.
So just because they do something with their default packaging does not mean it is right for everyone everywhere. Take something like Ubuntu for example.
No, this is absolutely terrible. The reason being is because it leaves pleb users who don't even know what DNS is unprotected.
It's also only really okay, when you control the DNS server on your network otherwise you're unprotected.
Advanced users which have their own local DNS servers and have those set up to do lookups over DoT/DoHS etc are certainly in the minority.
Getting all operating systems to include support for DoHs and all unsupported ones to include it isn't going to happen, so I think at this point it's certainly justifiable to include support in the browser.
In the future we may see every OS will have support for something like DNS over QUIC (where DoHs will lead to).
We see with Android 9 support for DoT, but that is just Android 9 (10.4% in May 2019) https://www.androidauthority.com/android-version-distributio...
We know there's plenty of older android devices out there which will likely never see an update.
I do this on my router, and then force all of it over the VPN with a socks proxy.
The biggest DNS servers for application level DoH are going to be run by ad companies and the future of tracking is via DNS (over HTTPS) queries.
One way to counter this could be to run the apps in a sandbox where one can restrict them from using certain APIs or fool them into thinking all is right with the world but content-block them anyway (like uBlockOrigin). Developing a sandbox is already possible in Android (see ParallelSpace), but likely requires a lot of work.
It'd be interesting to see what WASM does to content blockers. If uBlockOrigin et al are still effective with WASM apps, one could simply run most, if not all apps from the browser and achieve content-blocking to their heart's content (no pun).
I agree about 1st party domains.
Also, requests outgoing to dns.cloudflare.com/dns-query or dns.adguard.com/dns-query are blockable using URL rules.
As the standard for DoH evolves (DoH resolver names might not require URLs, like how DoT doesn't, to eliminate the need for a bootstrap DNS resolver), URL blocking will be ineffective, as well. I guess, it is a cat and mouse game from here on.
You need the cooperation of the app/device to do that. If it offers some way to do that, it will probably also have an option to just disable DoH.
If it doesn't, you're back to blocking all Cloudflare (and Google) IPs.
It is to prevent against ISP filtering and censorship.
A lot of governments do it with DNS rather than deep packet inspection in a full-on china style way.
> The biggest DNS servers for application level DoH are going to be run by ad companies and the future of tracking is via DNS (over HTTPS) queries.
Adblocking is better done with things like uBlock anyway. The reason is because you can manipulate the document object model with that to actually block the thing popping up.
Adblocking with DNS is pretty crappy, you end up getting huge white squares and blank popups anyway.
While true it has a very restricted use case: only on (some) browsers. Doesn't take into account any other application or device. And even uBlock will take a hit soon, at least on the most popular browser today.  So you can bet that the likes of Google will put their full weight behind any solution that prevents or at least severely inconveniences adblocking.
I don't have Chrome on my machine. What can you expect when the browser is made by an advertising company.
Well Fennec on Android supports extensions mostly.
I currently have:
• CleanURLs https://addons.mozilla.org/addon/clearurls/
• Cookie AutoDelete https://addons.mozilla.org/addon/cookie-autodelete/
• CSS Exfil Protection https://addons.mozilla.org/addon/css-exfil-protection/
• Decentraleyes https://addons.mozilla.org/addon/decentraleyes/
• ETag Stoppa https://addons.mozilla.org/addon/etag-stoppa/
• HTTPS Everywhere https://addons.mozilla.org/addon/https-everywhere/
• Redirect AMP to HTML https://addons.mozilla.org/addon/amp2html/
• uBlock Origin https://addons.mozilla.org/addon/ublock-origin/
• uMatrix https://addons.mozilla.org/firefox/addon/umatrix/
On my workstation/laptop I don't use Cookie Autodelete or Etag Stoppa because I have
• Firefox Multi-Account Containers https://addons.mozilla.org/addon/multi-account-containers/
• Temporary Containers https://addons.mozilla.org/addon/temporary-containers/
Oh and Tridactyl https://github.com/tridactyl/tridactyl, I found this to be a better solution on my 13" laptop because Tree Style Tab https://addons.mozilla.org/addon/tree-style-tab takes up too much screen real estate.
I am hoping when Fenix comes up to parity on the extensions front we will have a solution to https://bugzilla.mozilla.org/show_bug.cgi?id=1398097, which will allow for Container support.