dnscrypt-proxy crashes during startup with a specific value for listen_addresses.

[aureq]

Who is the bug affecting?

Me. And any user who may have an unusual listen_addresses value in their configuration.

What is affected by this bug?

dnscrypt-proxy 2.0.42.
When the issue happens, dnscrypt-proxy start but fails to respond to any dns queries. In addition, there's an important CPU usage made by dnscrypt-proxy.

When does this occur?

This happens when:

1. I set listen_addresses = ['127.0.2.1:53'] in dnscrypt-proxy.toml
2. And then restart dnscrypt-proxy

Where does it happen?

Linux Debian 10, Kernel 4.19.

How do we replicate the issue?

1. Set listen_addresses = ['127.0.2.1:53'] in dnscrypt-proxy.toml
2. Then restart dnscrypt-proxy
3. Do dig @127.0.2.1 github.com (no response)
4. run top to see the CPU usage

Expected behavior (i.e. solution)

To work around this issue, I've set listen_addresses = [] in dnscrypt-proxy.toml and it works just fine. No other changes.

Other Comments

Some context... I have an internal gateway that I use to filter DNS queries and hide my DNS traffic from my ISP. Exposed to the internal machines, Bind9 answers all DNS queries (including a local domain) and for answers that aren't in the cache, the query is forwarded to 127.0.2.1. Dnscrypt-proxy receives the request and either uses its cache or forwards it upstream as expected.

# content for /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";

        forwarders {
                127.0.2.1; // dnscrypt-proxy
        };
        forward only;
        
        listen-on-v6 { any; };
        listen-on {
                127.0.0.1;
                192.168.2.254;
        };

        allow-recursion {
                127.0.0.0/8;
                192.168.2.0/24;
        };
};

While experiencing this bug and the high CPU usage, I noticed that dnscrypt-proxy doesn't logs the usual information related to doing a latency check on the selected upstream DNS. After a few seconds, the process appears to be crashing.

dnscrypt-proxy[30795]: [2020-03-28 04:24:36] [NOTICE] dnscrypt-proxy 2.0.42
dnscrypt-proxy[30795]: [2020-03-28 04:24:36] [NOTICE] Network connectivity detected
dnscrypt-proxy[30795]: [2020-03-28 04:24:36] [NOTICE] Source [public-resolvers] loaded
dnscrypt-proxy[30795]: [2020-03-28 04:24:36] [NOTICE] Source [relays] loaded
dnscrypt-proxy[30795]: [2020-03-28 04:24:36] [NOTICE] Firefox workaround initialized
dnscrypt-proxy[30795]: [2020-03-28 04:24:36] [NOTICE] Loading the set of blocking rules from [/var/lib/dnscrypt-proxy/blacklist.txt]
dnscrypt-proxy[30795]: [2020-03-28 04:24:40] [NOTICE] Loading the set of cloaking rules from [/etc/dnscrypt-proxy/cloaking-rules.txt]
dnscrypt-proxy[30795]: [2020-03-28 04:24:40] [NOTICE] Error parsing IPv6 response given in blocked_query_response option, defaulting to IPv4
dnscrypt-proxy[30795]: [2020-03-28 04:24:40] [FATAL] listen udp 127.0.2.1:53: bind: permission denied
systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=255/EXCEPTION

In addition, the problem occurs regardless of Bind9 running or not.

When I revert the configuration to listen_addresses = [], then

1. dnscrypt-proxy starts normally
2. running dig @127.0.2.1 github.com returns an answer even with Bind9 not running showing that dnscrypt-proxy actually listens on that address/interface.

Finally, this could be related to #1250 but I'm not 100% sure.

I hope this is helpful but feel free to ask for more details.

Thanks.

[jedisct1]

You probably installed a 3rd party package or followed a tutorial on some random website that told you to install a systemd socket.

This is completely unsupported and the installation instructions do not make you install this.

Remove it:

sudo systemctl stop dnscrypt-proxy.socket 
sudo systemctl disable dnscrypt-proxy.socket

Then listen_addresses will work normally.