DNSCrypt Proxy v1 replaced by v2 #384

New Issue

2018-01-09T02:45:46Z

NPN commented

2018-01-09 02:45:46 +00:00

(Migrated from github.com)

DNSCrypt has been abandoned by its creator, Frank Denis. On November 10, 2017, Denis tweeted that the project was looking for new maintainers. Some time later, the project repository was moved to Dyne, the new maintainers (edit: here is a tweet from them).

The README on Dyne's repository explains that DNSCrypt will continue to be maintained until "a viable and mature alternative arises," because Dyne relies on it for their project Dowse.eu. However, no new features will be added. Similarly, the first commit after the transfer states that:

We will likely work to keep dnscrypt around for another year at least, while evaluating if to shift our code to use other alternatives.

The domain dnscrypt.org is still registered under Denis, but now redirects to https://dnsprivacy.org/wiki/, the site for the "DNS Privacy Project." As the Dyne README explains:

The old webpage dnscrypt.org now points to a new domain, endorsing the usage of competing protocol "DNS-over-TLS" and competing software in particular the "getdns" library and an immature implementation that could substitute dnscrypt-proxy, called "stubby".
The new website also links a critical analysis of DNSCrypt vs DNS-over-TLS protocols by a company marketing their own open-source Android web browser and offering a new DNS resolver implemented in Go.

Denis has created a new repository under the same name as before, and is writing "a new implementation [of DNSCrypt] that sucks less."

I am uncertain of the status of the DNSCrypt resolvers. DNSCrypt is still working for me right now, so they probably haven't all shut down. The resolver list page is no longer available because the website is gone, but the CSV resolver list is still in Dyne's repository.

I don't have an answer for what to do here. This issue is more of a report to explain what has been going on. DNSCrypt could be kept on the website, as it will be maintained for a while. Denis's rewrite is still very young (as of writing this issue, the first commit was just a few hours ago), so it likely won't be an option for the forseeable future.

If DNSCrypt is kept, the link to dnscrypt.org should be removed or changed to point to the most recent Wayback Machine version, since the new site has nothing to do with DNSCrypt. Regarding the old website and GitHub wiki, Dyne says that they are willing to host them, but only if Denis gives them the archives.

Feel free to leave suggestions for what should be done, or for replacements for DNSCrypt. Perhaps DNS-over-TLS might be worth exploring?

DNSCrypt has been abandoned by its creator, Frank Denis. On November 10, 2017, Denis [tweeted](https://twitter.com/jedisct1/status/928942292202860544) that the project was looking for new maintainers. Some time later, the [project repository](https://github.com/dyne/dnscrypt-proxy) was moved to [Dyne](https://github.com/dyne), the new maintainers (edit: here is a [tweet](https://twitter.com/DyneOrg/status/949957701114761216) from them). The [README](https://github.com/dyne/dnscrypt-proxy/blob/master/README.markdown) on Dyne's repository explains that DNSCrypt will continue to be maintained until "a viable and mature alternative arises," because Dyne relies on it for their project [Dowse.eu](https://dowse.eu/). However, no new features will be added. Similarly, the [first commit](https://github.com/dyne/dnscrypt-proxy/commit/45912417738ce38ce6dd04cc4173d276a17ef2d8) after the transfer states that: > We will likely work to keep dnscrypt around for another year at least, while evaluating if to shift our code to use other alternatives. The domain dnscrypt.org is still registered under Denis, but now redirects to https://dnsprivacy.org/wiki/, the site for the "DNS Privacy Project." As the Dyne README explains: > The old webpage dnscrypt.org now points to a new domain, endorsing the usage of competing protocol "DNS-over-TLS" and competing software in particular the "getdns" library and an immature implementation that could substitute dnscrypt-proxy, called "stubby". > The new website also links a [critical analysis of DNSCrypt vs DNS-over-TLS protocols](https://tenta.com/blog/post/2017/12/dns-over-tls-vs-dnscrypt) by a company marketing their own open-source Android web browser and offering a new DNS resolver implemented in Go. Denis has created a [new repository](https://github.com/jedisct1/dnscrypt-proxy) under the same name as before, and is writing "a new implementation [of DNSCrypt] that sucks less." I am uncertain of the status of the DNSCrypt resolvers. DNSCrypt is still working for me right now, so they probably haven't all shut down. The [resolver list page](https://dnscrypt.org/dnscrypt-resolvers.html) is no longer available because the website is gone, but the [CSV resolver list](https://github.com/dyne/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv) is still in Dyne's repository. -------- I don't have an answer for what to do here. This issue is more of a report to explain what has been going on. DNSCrypt could be kept on the website, as it will be maintained for a while. Denis's rewrite is still _very_ young (as of writing this issue, the first commit was just a few hours ago), so it likely won't be an option for the forseeable future. If DNSCrypt is kept, the link to dnscrypt.org should be removed or changed to point to the [most recent Wayback Machine version](https://wayback.archive.org/web/20171224003237/https://dnscrypt.org/), since the new site has nothing to do with DNSCrypt. Regarding the old website and GitHub wiki, Dyne says that they are willing to host them, but only if Denis gives them the archives. Feel free to leave suggestions for what should be done, or for replacements for DNSCrypt. Perhaps DNS-over-TLS might be worth exploring?

👍 1

Atavic commented

2018-01-10 21:01:29 +00:00

(Migrated from github.com)

Perhaps DNS-over-TLS might be worth exploring?

👍

> Perhaps DNS-over-TLS might be worth exploring? :+1:

beerisgood commented

2018-01-12 13:48:30 +00:00

(Migrated from github.com)

https://github.com/jedisct1/dnscrypt-proxy

👍 1

NPN commented

2018-01-12 19:58:51 +00:00

(Migrated from github.com)

@beerisgood Yes, I saw that when I was writing the issue, but at that time, the repository had just been created—it didn't even have a README yet. Now, it appears that work is proceeding quickly. So, dnscrypt-proxy v2 will likely be the replacement for v1.

However, there is still the issue of what to put on the website for the time being. Sometime between this issue being posted and this comment now, the domain dnscrypt.org was snapped up by a domain parker. Now, it points to nothing—the http version of the site returns a 403, and the https version can't even be loaded because the certificate is configured incorrectly.

I see two options if DNSCrypt is kept on the list of recommendations. Either we change the URL to point to Dyne's fork of v1, or we point it to Denis's v2 alpha. Which choice is best?

Keep in mind that the documentation for both versions is a spotty as of now, which may make it difficult for newcomers to use them. The only v1 documentation I know of is through the Wayback Archive of the website (the GitHub wiki was not archived), and the Arch wiki. For v2, there are some comments in its configuration file that explain how it works. v2 seems to be pretty similar to v1, though, so most of the documentation for v1 probably applies to v2 too.

@beerisgood Yes, I saw that when I was writing the issue, but at that time, the repository had just been created—it didn't even have a README yet. Now, it appears that work is proceeding quickly. So, dnscrypt-proxy v2 will likely be the replacement for v1. However, there is still the issue of what to put on the website for the time being. Sometime between this issue being posted and this comment now, the domain dnscrypt.org was snapped up by a domain parker. Now, it points to nothing—the http version of the site returns a 403, and the https version can't even be loaded because the certificate is configured incorrectly. I see two options if DNSCrypt is kept on the list of recommendations. Either we change the URL to point to Dyne's fork of v1, or we point it to Denis's v2 alpha. Which choice is best? Keep in mind that the documentation for both versions is a spotty as of now, which may make it difficult for newcomers to use them. The only v1 documentation I know of is through the Wayback Archive of the website (the GitHub wiki was not archived), and the [Arch wiki](https://wiki.archlinux.org/index.php/Dnscrypt). For v2, there are some comments in its configuration file that explain how it works. v2 seems to be pretty similar to v1, though, so most of the documentation for v1 probably applies to v2 too.

👍 1

Hillside502 commented

2018-01-12 21:36:59 +00:00

(Migrated from github.com)

Clearly, DNSCrypt should be removed forthwith until the situation described above settles.

This site should be listing reliable options --- not the up-in-the-air, transitory or unpredictable!

https://www.privacytools.io/#dns

Clearly, DNSCrypt should be removed **forthwith** until the situation described above settles. This site should be listing reliable options --- not the up-in-the-air, transitory or unpredictable! https://www.privacytools.io/#dns

NPN commented

2018-01-13 01:08:44 +00:00

(Migrated from github.com)

Yes, I agree with that. Here is some more information I've dug up on the situation:

This issue from snorkasaurus's fork of DNSCrypt was created around the time the original repo was archived. It provides an explanation for the other fork of the original DNSCrypt, which is housed under the new DNSCrypt organization, along with what seems to be the rest of the original DNSCrypt repos. Apparently, this organization was created by Denis himself. The only public member of the organization, though, is Fusl, who is a member of the OpenNIC (if that has anything to do with it).

Unlike Dyne's fork, which they promise to keep maintained (and feature freezed), this fork is only a clone of snorkasaurus's fork, which was updated on the day the original repo was set to read only.

So, the situation is as follows:

The original author has abandoned their project to rewrite it in Go (the protocol itself is not changing).
There are at least two forks of the orignal project. One is to be maintained by a company, and the other is part of an organization that was purportedly created by the original author. However, it's not clear if Denis is actually a part of it or related to it at all.
The dnscrypt.org website was first redirected to a site with a competing DNS privacy service, and is now broken and in the middle of being transferred (to a domain parker, as far as I can tell).

For all these reasons, DNSCrypt should be removed from the list of recommendations. When or if an official statement comes out about the status and future of the project (including the resolvers), or v2 is stable, then it might be added back. For now, it's best to explore alternatives like DNS-over-TLS or DNS-over-HTTPS. Any suggestions would be much appreciated (they should be filed in a separate issue, though).

Yes, I agree with that. Here is some more information I've dug up on the situation: This [issue](https://github.com/snorkasaurus/dnscrypt-proxy/issues/7) from [snorkasaurus](https://github.com/snorkasaurus)'s fork of DNSCrypt was created around the time the original repo was archived. It provides an explanation for [the _other_ fork](https://github.com/DNSCrypt/dnscrypt-proxy) of the original DNSCrypt, which is housed under the new [DNSCrypt organization](https://github.com/DNSCrypt), along with what seems to be the rest of the original DNSCrypt repos. Apparently, this organization was [created by Denis](https://github.com/snorkasaurus/dnscrypt-proxy/issues/7#issuecomment-354382192) himself. The only public member of the organization, though, is [Fusl](https://github.com/Fusl), who is a member of the OpenNIC (if that has anything to do with it). Unlike Dyne's fork, which they promise to keep maintained (and feature freezed), this fork is only a clone of snorkasaurus's fork, which was updated on the day the original repo was set to read only. So, the situation is as follows: - The original author has abandoned their project to rewrite it in Go (the protocol itself [is not changing](https://twitter.com/jedisct1/status/951934363985498113)). - There are at least two forks of the orignal project. One is to be maintained by a company, and the other is part of an organization that was purportedly created by the original author. However, it's not clear if Denis is actually a part of it or related to it at all. - The dnscrypt.org website was first redirected to a site with a competing DNS privacy service, and is now broken and in the middle of being transferred (to a domain parker, as far as I can tell). For all these reasons, DNSCrypt should be removed from the list of recommendations. When or if an official statement comes out about the status and future of the project (including the resolvers), or v2 is stable, then it might be added back. For now, it's best to explore alternatives like DNS-over-TLS or DNS-over-HTTPS. Any suggestions would be much appreciated (they should be filed in a separate issue, though).

👍 2

zero77 commented

2018-01-13 12:50:29 +00:00

(Migrated from github.com)

The problem with DNS over TLS is that it leaks the hostname in plain text by the Server Name Indication (SNI) extension for TLS.

DNSCrypt V2 may be better.
https://github.com/jedisct1/dnscrypt-proxy

The problem with DNS over TLS is that it leaks the hostname in plain text by the Server Name Indication (SNI) extension for TLS. DNSCrypt V2 may be better. https://github.com/jedisct1/dnscrypt-proxy

😕 1

hideamusha commented

2018-01-17 00:03:23 +00:00

(Migrated from github.com)

I think you're mixing HTTPS (HTTP over TLS) with DNS-over-TLS.

The purpose of DNS-over-TLS is to encrypt which hostname you are looking up, and as such it would make no sense to leak the hostname through SNI.
In the context of HTTPS, however, SNI allows a webserver to serve different domains on the same IP. Since the webserver needs to present a certificate in the TLS-protocol, SNI is needed so the server knows which one to send to the client.

DNS-over-TLS is the recommended way to secure your DNS-requests, and is used by companies like Google. Both DNS-over-TLS and DNSCrypt provides confidentiality (encrypting your requests) and authenticity (preventing tampering).
In my opinion, the preservation of the request's integrity is the most important factor since, as you have stated, SNI leaks the hostname anyway (this only applies to browsing the internet and HTTPS).

I think you're mixing HTTPS (HTTP over TLS) with DNS-over-TLS. The purpose of DNS-over-TLS is to encrypt which hostname you are looking up, and as such it would make no sense to leak the hostname through SNI. In the context of HTTPS, however, SNI allows a webserver to serve different domains on the same IP. Since the webserver needs to present a certificate in the TLS-protocol, SNI is needed so the server knows which one to send to the client. DNS-over-TLS is the recommended way to secure your DNS-requests, and is used by companies like Google. Both DNS-over-TLS and DNSCrypt provides confidentiality (encrypting your requests) and authenticity (preventing tampering). In my opinion, the preservation of the request's integrity is the most important factor since, as you have stated, SNI leaks the hostname anyway (this only applies to browsing the internet and HTTPS).

kewde commented

2018-01-17 00:30:38 +00:00

(Migrated from github.com)

Thanks @NPN

I haven't had the chance to look properly at the new DNSCrypt project, thanks for the detailed write up.
It is truly appreciated.

I've currently removed the links and added a warning not to refrain from using DNSCrypt for now.
At least until the dust settles.

Thanks @NPN I haven't had the chance to look properly at the new DNSCrypt project, thanks for the detailed write up. It is truly appreciated. I've currently removed the links and added a warning not to refrain from using DNSCrypt for now. At least until the dust settles.

kewde commented

2018-01-17 00:31:10 +00:00

(Migrated from github.com)

Further discussion about replacements should be held in a separate issue tho.

NPN commented

2018-04-02 01:54:27 +00:00

(Migrated from github.com)

Alright, it's been a while, and I think it's safe to add DNSCrypt back.

Changes since January:

dnscrypt-proxy 2 has hit version 2.0.8 (stable since 2.0.0)
The new website for DNSCrypt is at https://dnscrypt.info/ (dnscrypt.org is now parked by NameSilo).
Dyne's fork has remained stagnant, and will likely continue to remain so.
The DNSCrypt organization (which I was rather unfairly paranoid about last time), is, in fact, the real deal. Their fork of the original project has been deleted. They now host the repositories for the resolver list and website, among other things.

It's clear now, what with the steady releases, that DNSCrypt is back. The domain and forks issues have also been resolved, so I think there is nothing standing in the way of adding DNSCrypt back to the website.

Alright, it's been a while, and I think it's safe to add DNSCrypt back. Changes since January: * [dnscrypt-proxy 2](https://github.com/jedisct1/dnscrypt-proxy) has hit version 2.0.8 (stable since 2.0.0) * The new website for DNSCrypt is at https://dnscrypt.info/ (dnscrypt.org is now parked by NameSilo). * Dyne's fork has remained stagnant, and will likely continue to remain so. * The DNSCrypt [organization](https://github.com/DNSCrypt) (which I was rather unfairly paranoid about last time), is, in fact, the real deal. Their fork of the original project has been deleted. They now host the repositories for the resolver list and website, among other things. It's clear now, what with the steady releases, that DNSCrypt is back. The domain and forks issues have also been resolved, so I think there is nothing standing in the way of adding DNSCrypt back to the website.

sergeevabc commented

2018-04-02 08:04:45 +00:00

(Migrated from github.com)

Let’s show a courtesy by notifying @jedisct1, the maintainer of DNSCrypt, that his brainchild is on trial.

This repo is archived. You cannot comment on issues.