Given Cloudflare's new 1.1.1.1 DNS service
supports dnscrypt-proxy 2.0 is anyone considering supporting the new release in LEDE? I know about the dnscrypt-proxy 1.9.x pkg.
The new reference 2.0 server appears to be written in Go which is likely a problem. And it appears that dnscrypt-proxy 2.0 is required to use the 1.1.1.1 service if you want end-to-end encryption given the new method of identifying dnscrypt capable DNS servers.
I asked about it in another thread when the creator had supposedly abandoned the project.
The new cloudfare dns service supports DNS over TLS and DNS over HTTPS. The latter one will be supported by dnscrypt-proxy 2, too. The former one is supported today in OpenWrt by unbound & stubby, e.g. https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby.
I have been looking at 2.0 and it's promising enough that I have a package with feature parity to the released package (v1.9.5). There's a custom package on github at:
This is the source for a custom package, so must be built.
The buildroot does not support Go cross-compile (yet) so the binary blob is downloaded for ARM. If you run a different platform, simply download the appropriate blob and replace in /usr/sbin.
The package is HUGE (2.7M compressed, 6M uncompressed). Barring size reduction through patching when Go is an option, I'm not sure this will ever see trunk.
Read the README in the custom_feed folder (Github) for notes on how it's implemented, there are some differences in this upgrade.
I have no idea if this will bear any resemblance to any package that would eventually be committed -- but if you want to play with v2.0, this is an option.
Thank you for this.
Works great =)
But there is bug in the init script.
E.g.
cache setting is always true.
Because it is already set to true in the config.
And the init script only sets cache to true if not 0.
And because off that it never gets set to false.
[ "${local_cache}" -ne '0' ] && {
sed -i "/cache = / c\cache = true" $CFGRUN
I think it is better to add an else here (set cache to false ).
Maybe also do this for all other options.
And one time i ended up with an empty cloaking rules file in root directory ( / )
Thanks for the note. I fixed the cache logic -- I didn't notice that the default was set to true in the example config.
I prefer to minimize the changes to the config file -- if user choice matches example config default, then just leave the file alone and only modify it on changes. Your method would future proof the init, of course.
After looking at any place config files can be generated it's of course obvious where the "empty cloaking rules file in root directory" came from. This should be fixed as well.
Thanks for alpha testing!
Looking at the OpenWrt's setup I'd say that https://github.com/aarond10/https_dns_proxy and/or https://github.com/vaapicon/doh-proxy would be the easiest way to add TLS support.
Apparently you could in theory use whatever you want as long as it does tcp requests as you (from that I can tell) can use stunnel and/or hitch to add SSL capability.
it appears there have been a lot of active development with dnscrypt-proxy v2.
Installation OpenWRT/LEDE
The instructions at github for OpenWrt are super easy, versatile and clear to understand. I like that.
i agree the posted instructions is very easy to follow provided you know which binary file is right for your router. the binary file is huge though but fortunately there is an option to compress its file size before transferring the binary file to the router. it's relatively easier to install and configure, compared to unbound, but perhaps it could be just a matter of personal preference.
From what I read. DNSCrypt v2 offers the best performance when using DoH (DNS-Over-HTTPS). There is also... well DNSCrypt servers so that's also a plus. The implementation with dnsmasq is well documented and tested. No need for unbound, caching is provided by both DNSCrypt and dnsmasq.
The drawback is the package size. Even after the compression, 2 MB is quite a lot for a single package. The whole kernel partition in 18.06 is about 4 MB.
Yet another reason to heed the https://openwrt.org/supported_devices/432_warning as well as considering a minimum of 32 MB flash and 256 MB RAM for purchase of new devices (along with comparatively powerful, multi-core CPUs).
As users "demand" fully encrypted connections and, where possible, authenticated, the demands on flash, RAM, and CPU power will only continue to increase.
I disagree.
The "minimum" should stand for all the basic services required to provide a satisfactory operation. I think 16 MB of Flash and 128 MB of RAM is more then enough for most use-cases. I would even consider 64 MB of RAM as "minimum".
If people want to install additional software and put more services on their routers, then they should get the "recommended" device. At that level I could agree with 32 MB of Flash and 256 MB of RAM.