DNSCrypt encrypts communications between a DNS client and a DNS resolver

> 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:

• https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

• https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic...

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"

I think the project has moved to https://dnscurve.io/ - I can't say for certain this is the same project but it's the current website for github.com/curvedns/curvedns which I believe is the software behind GP's link.

It's https://curvedns.github.io/curvedns hosted on GitHub Pages giving a (301) redirect. How did they get a header based redirect via GitHub pages?

Is this what you had in mind?

• https://wiki.archlinux.org/index.php/Dnscrypt-proxy#Local_DN...

• https://wiki.alpinelinux.org/wiki/Linux_Router_with_VPN_on_a...

ISPs can still see the IP your requests resolves to, and in many cases can still track this info. Unless the site is using shared IP, like many behind caching services, etc

Fundamentally you have 3 problems

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.

> At some point, most Internet protocol privacy issues boil down to who you're willing to leak information to (which is to say, who you choose to trust).

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.

> At some point, most Internet protocol privacy issues boil down to who you're willing to leak information to

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.

That's configurable and depends on your VPN use. If you just want to reach some internal corporate network ranges and have everything else go directly to the internet that's perfectly fine.

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.

There probably already exists, but I would like to see a standardized Docker setup for encrypted DNS and running your own DNS with unbound. I run both Unbound and Nsd locally, but I probably have a lot I could improve upon. I just used what few informative tutorials I was able to find.

> I run a small OpenBSD router with stubby for dns over tls and unbound for caching.

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.

> Applications should respect OS settings unless told otherwise by a user i.e opt in not opt out.

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.

> don't understand the benefit to Mozilla, but pushing HTTPS + DoH + ESNI

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.

Cloudflare is not an ad company. Perhaps you are thinking of Google?

In case of DoH, one could firewall DoH servers and the fallback should be then to use OS defined resolvers. Of course, the app/ad-network could always complain abt connectivity and render the app unusable to get one to disable the firewall rules. Other way is to simply do all the advertisements and tracking through first-party domains / servers. I fully expect a standard here to take shape to let CDNs and 3Ps serve content from 1P domains (if it isn't already).

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).