Dnscrypt-proxy - 1.9.4-3 vs 1.9.5-1

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 ''
        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 :slight_smile:

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 :frowning:


Oh, looks like @hnyman did the commit ! Please guru, can you look into this?

The best place to discuss that directly with the dnscryptproxy package maintainer is the Github pull request that was linked above.

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 :slight_smile:

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>

dnscrypt-proxy - 1.9.4-3
dnscrypt-proxy-resolvers - 1.9.4+git-20161129-f17bace-3

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 :slight_smile:

1 Like