I've noticed that when upgrading to the latest release ( I think from yesterday or today ) , dnscrypt stops working after reboot, if you use any of the options that come commented in the base package. I was using this options:
config dnscrypt-proxy ns1
option address '127.0.0.1'
option port '5353'
option resolver 'cisco-familyshield'
option resolvers_list '/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv'
# ephemeral keys option requires extra CPU cycles and can cause huge system load
# option ephemeral_keys '0'
# more details at https://github.com/jedisct1/dnscrypt-proxy#public-key-client-authentication
# option client_key '/path/to/client_key'
**option syslog '1'**
** option syslog_prefix 'dnscrypt-proxy'**
** option query_log_file '/mnt/sda1/dnslogs/dnsqueries.log'**
# enable cache may speed up dnscrypt-proxy, see https://github.com/jedisct1/dnscrypt-proxy/wiki/Go-faster
**option local_cache '1'**
# disable IPv6 may also speed up dnscrypt-proxy, see https://github.com/jedisct1/dnscrypt-proxy/wiki/Go-faster
**option block_ipv6 '1'**
# Blacklists allow you to block domains, ip, ... see https://github.com/jedisct1/dnscrypt-proxy/wiki/Filtering
**list blacklist 'domains:/usr/share/dnscrypt-proxy/dnscrypt-blacklist-domains.txt' 'logfile:/mnt/sda1/dnslogs/dnscrypt-blocked.log'**
I tried several combinations, and for example , running the latest version ( 1.9.5-1 ) , I was able to enable option syslog '1' and option syslog_prefix, but not the others.
Running a dnscrypt-proxy restart logs in the system log something like "plugins are not implemented", and the router is left with no capability to resolve DNS Addresses ( therefore, the whole network goes down )
Not sure how to post this in the maintainer of the package site at github, I would have if I knew how
Here is the PR where you can open an issue, use an @maintainer to get attention drawn. Or the github under issue; in this case probably go with the first option.
You are right in your observation. I just tested with a build and you now have to select the dnscrypt-proxy plugin option in your build config or things will be broken as described. So, not a bug per se, but a change that is going to catch people out.
I would say that for anyone doing an upgrade without looking into the details this would be disastrous... Immediate loss of Internet connectivity on no apparent reason
I don't think this is a result of conversion to 1.9.5-1, I believe it's a result of the earlier commit that enabled plugin functionality (that was me). The history:
The original init script included plugin support but plugins weren't enabled at compile time. I added the capability to enable the plugins supported by the init script but it appears that the init script now needs a modification to ignore those specific config file lines if plugins are not enabled (or the package could be modified to default to Y for plugins, or eliminate the choice altogether -- but there are overall package size implications so this was left as a choice, default N).
I'll look at this when I have a chance but I'm busy / travelling for the next few days so it will be a while before I can get to it but I'm guessing it will be a very simple change that anyone can handle. Famous last words...
@InkblotAdmirer , glad to know it was you and that you can fix this
Seriously, I loved the functionality to log the DNS queries, and the ability to block ipv6 requests to save time ... so I think others would love that too.... why not keeping them? Our routers evolve every day so package size shouldn't be a problem moving forward (and you can always do an extroot) .
One thing that was never working tough was the functionality to log the BLOCKED DNS requests, with the second argument of the code below, can you take a peek at that when you return from travel?
list blacklist 'domains:/usr/share/dnscrypt-proxy/dnscrypt-blacklist-domains.txt' 'logfile:/mnt/sda1/dnslogs/dnscrypt-blocked.log'
@mariano.silva Are you using a custom build that was compiled with plugins enabled? If not then those functions won't work (even though the init script accepts them).
It appears the issue is that dnscrypt-proxy now doesn't want to start (v1.9.5) if those options are selected in the config but plugins aren't enabled. See: https://wiki.openwrt.org/inbox/dnscrypt about halfway down the page, the options that are accepted by the init script but won't work without plugins enabled.
See the original pull request text, I tested the blacklist before submitting the PR and it was working. I don't actually use that function right now so I can't say off-hand if it's still working with 1.9.5.
As to just enabling plugins by default, there was a long thread a while back discussing whether to support 4M or 8M min flash and I don't recall the outcome but arbitrarily adding 125kB to all builds doesn't seem right. If every package makes decisions like that it adds up quickly.
@InkblotAdmirer, I'm using @davidc502 's LEDE's build based on kernel 4.9.20 ( Lede Reboot SNAPSHOT r4114-6704410 / LuCI Master (git-17.136.70777-41d604f) ) . The dnscrypt-proxy version that comes with the latest build are>
On those versions, the plugins are enabled (the author of the pull acknowledge it on another forum). Now in version 1.9.5-1 , the plugin support is not enabled anymore, as you pointed out, that should be the normal behavior.
Anyway, I'm staying with 1.9.4-3 for as long as I can, if the blacklisting functionality is not put back in, as I don't want to deal with adblock or other similar piece of software just to block a couple of sites in a text file
