Good reddit thread discussing the differences between the following (I googled it specifically to find out what practical differences existed between DNS over TLS and DNSCrypt):
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.
Most of the top comments in the thread are 1 years old now.
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.
> 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.
Firefox doesn't like the certificate there, which is rather ironic:
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
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.
True or false: dnscrypt-wrapper can be put in front of an authoritative server (instead of a recursive resolver), thereby enabling end-to-end encrypted DNS packets for a user running dnscrypt-proxy (in front of the user's cache, e.g. unbound).
If true, anyone have some examples of who is doing that?
I personally run CurveDNS but here is a quick and dirty script to show how DNSCrypt might be used to encrypt DNS traffic between stub resolvers or caches and authoritative servers, if authoritative DNS providers used dnscrypt-wrapper. To demonstrate we can pretend we are an authoritative DNS provider, e.g., a root server.
If you are on a trusted network or have a VPN into a trusted network this is not an issue, you can run your own recursive resolver. The real issue is the traffic between your resolver and the authoritative servers.
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.
This sounds profound but isn't really saying much, is it? 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). And, in the DoH/DNSCrypt case, almost nobody trusts their ISP, so these protocols are valuable.
> 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.
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.
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
To your caveat, I can access thepiratebay even though it is
supposedly IP blocked in the UK because the courts are not willing to order a block of the whole cloudflare IP range. With so many websites using cloud hosting, it has become very hard for the authorities to block IP ranges.
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.
My Indian ISP blocks certain sites. I use Firefox and has DNS over HTTPS with CloudFlare enabled. I also use CloudFlare's 1.1.1.1 DNS in my router. The sites are still blocked.
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?
Find an (allegedly) blocked website that is using CloudFlare and has TLS 1.3 enabled.
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.
Thank you. Unfortunately, I wasn't able to find a blocked site that has TLS 1.3 enabled.
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".
> 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.
DNSCrypt-proxy allows to send queries to random upstream DNS server or to better half of them. Spreading your queries along many servers makes them difficult to analyze.
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.
Yeah, I really like Stubby. Just last week I set up a Raspberry Pi with Stubby and Unbound, it was actually pretty easy. Stubby is doing DoT and DNSSEC validation, and Unbound handling caching and a local zone for my home devices, which is really nice.
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.
Applications should respect OS settings unless told otherwise by a user i.e opt in not opt out.
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.
> 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.
> 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).
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 use DNS over TLS at home, but at work I am glad that Firefox provides DoH since DNS over TLS is not supported by my work's corporate DNS servers and other common DNS servers are blocked on the network.
It's because DoH can't be blocked without breaking the internet. I don't understand the benefit to Mozilla, but pushing HTTPS + DoH + ESNI + a handful of huge CDN IPs guarantees the death of ad blockers.
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.
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).
If TLS requests and responses could be intercepted (again, not straight forward with cert-pinning), blackholing MIME-type application/dns-message should work.
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.
> 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.
> Adblocking is better done with things like uBlock 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. [0] 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.
* DNS over HTTPS (DoH)
* DNS over TLS (DoT)
* DNSCrypt
https://www.reddit.com/r/privacy/comments/89pr15/dnsoverhttp...
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.