
DNSCrypt encrypts communications between a DNS client and a DNS resolver - zdw
https://dnscrypt.info
======
eganist
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):

* DNS over HTTPS (DoH)

* DNS over TLS (DoT)

* DNSCrypt

[https://www.reddit.com/r/privacy/comments/89pr15/dnsoverhttp...](https://www.reddit.com/r/privacy/comments/89pr15/dnsoverhttps_vs_dns_overtls_vs_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.

~~~
yegle
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.

~~~
dngray
> _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-ietf-quic-transport/)

• [https://datatracker.ietf.org/doc/draft-huitema-quic-
dnsoquic...](https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/)

What is interesting is DNSCrypt
[https://dnscrypt.info/faq](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"

------
exabrial
And the best part is it's still based on UDP

~~~
bluejekyll
As DNS-over-Quic starts shaping up, this probably won’t matter, in terms of
latency.

------
3xblah
CurveDNS encrypts communications between a DNS resolver and an DNS
authoritative server.

[https://curvedns.on2it.net](https://curvedns.on2it.net)

~~~
iam-TJ
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

Error code: SSL_ERROR_BAD_CERT_DOMAIN

~~~
jfindley
I _think_ the project has moved to
[https://dnscurve.io/](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.

~~~
iosonofuturista
Seems to be a even more terrible than usual naming decision.

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](http://www.dnscurve.org).

What a mess.

------
jakeogh
[https://github.com/DNSCrypt/dnscrypt-
proxy](https://github.com/DNSCrypt/dnscrypt-proxy) works well

------
w8rbt
I use CoreDNS as a stub resolver to do DNS over TLS. It works great.
[https://coredns.io/](https://coredns.io/)

------
godzillabrennus
I’m going to give Pi-Hole a try at home. Seems like there are guides for dns
crypt to be enabled with it.

Wish it was bundled with the official build though.

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

~~~
tptacek
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.

~~~
vinniejames
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

~~~
mantap
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.

~~~
throwawaydoh
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?

~~~
tgragnato
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.

~~~
throwawaydoh
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".

~~~
tgragnato
Expected, without esni (which requires tls1.3) there’s no way to conceal the
domain from the boxes.

Or.. your ISP might be blocking the IPs.

Remember to revert the settings to the original values.

------
toortam
Stubby is another alternative, it uses DoT (DNS over TLS).

~~~
stephen_g
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.

------
techntoke
So this whole Firefox DoH is a moot point when these other options exist. Why
Mozilla must you insist on making this more difficult?

~~~
donmcronald
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.

~~~
dngray
> _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.

~~~
close04
> 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.

[0]
[https://news.ycombinator.com/item?id=20050173](https://news.ycombinator.com/item?id=20050173)

~~~
dngray
ehe yeah fuck google for doing that, clearly they care more about their bottom
line.

I don't have Chrome on my machine. What can you expect when the browser is
made by an advertising company.

