Hacker News new | past | comments | ask | show | jobs | submit login
DNSCrypt encrypts communications between a DNS client and a DNS resolver (dnscrypt.info)
101 points by zdw 9 months ago | hide | past | favorite | 60 comments

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


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.

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"

He is right though. The NAT comparison is apt.

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

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

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


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.

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.

What a mess.

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?

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?

No. If it was, the tutorial would be focused on authoritative DNS providers, at least in part.

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.

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, serving root.zone from ftp.internic.net
   # dnscrypt-wrapper listening on
   # dnscrypt-proxy listening on
   # 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=
   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 -a --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 -r --provider-name=2.dnscrypt-cert.root.zone -p 2.pid &
   drill example.com -p5300 @
   read a < 1.pid
   read b < 2.pid
   rm 1.key 1.cert public.key secret.key 1.pid 2.pid
   kill $a
   kill $b


I use CoreDNS as a stub resolver to do DNS over TLS. It works great. https://coredns.io/

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.

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.

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.

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

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.

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

[1] https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscr...

DNS traffic is often resolved through ISPs even if you use a VPN.


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.

Wouldn't you be much less personally identifiable one hop upstream?

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

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.

Good thing someone make a user-friendly version of it on Windows


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

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.

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

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

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.

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.

The arch wiki actually has a section on using unbound, dnsmasq, pdnsd with dnscrypt:


I do this on my router, and then force all of it over the VPN with a socks proxy.

Any chance you could setup that in a Docker contaienr?

It would be very trivial to do. I currently use AlpineLinux and have mine setup like so:


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

What if the DoH IP is running via Cloudflare? How do you block their IPs?

I agree about 1st party domains.

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.

I think the cat-and-mouse game is already over at "If TLS requests and responses could be intercepted".

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.

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

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

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.

And mobile apps?

> And mobile apps?

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.

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact