Talk:Dnscrypt-proxy

"CapabilityBoundingSet" in /* Sandboxing */

With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:

archlinux systemd[1]: Started DNSCrypt-proxy client.

archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted

archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted

archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES

archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.

-- Wincraft71 (talk) 21:01, 27 May 2018 (UTC)

That has nothing with the "newest update" (whatever that means today), AmbientCapabilities=CAP_NET_BIND_SERVICE appeared in [1]. -- Lahwaacz (talk) 21:47, 27 May 2018 (UTC)

Well the only way I can get it to work when starting directly or from the socket dnscrypt-proxy.socket is by adding CAP_NET_BIND_SERVICE to the end of CapabilityBoundingSet=. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- Wincraft71 (talk) 22:21, 27 May 2018 (UTC)

Startup method when using Unbound

It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the DNSCrypt#Startup section and upstream [2].

Something along the lines of "When forwarding queries with Unbound, dnscrypt-proxy should be started through dnscrypt-proxy.socket" in the DNSCrypt#Startup section. As it is now, the dnscrypt-proxy.toml file contains listen_addresses = ['127.0.0.1:53', '[::1]:53'] so for an average user following DNSCrypt#Unbound (especially when coming directly from the Unbound page) this would lead to a misconfiguration. -- Wincraft71 (talk) 15:34, 28 May 2018 (UTC)

You need to 1. configure unbound, and 2. configure DNSCrypt, so you should read both pages (from the start). Why is that not clear? -- Lahwaacz (talk) 20:11, 28 May 2018 (UTC)

Okay, let's say the reader starts from Unbound then follows the link to DNSCrypt or DNSCrypt#Unbound from Unbound#Forwarding_queries. Nowhere in DNSCrypt now does it explicitly say "Use the socket method for Unbound and DNSCrypt". But you need to use the socket method for Unbound + DNSCrypt to work. Why are you acting like it's so perfectly clear when it's not? Not every reader is going to be able to surmise that forwarding queries to DNSCrypt requires the socket method and editing the config to work. Would it really kill you to make a brief mention that Unbound uses the socket method in DNSCrypt#Startup? Either way the readers should have examples of which option to choose based on different uses. -- Wincraft71 (talk) 21:05, 28 May 2018 (UTC)

If you still haven't seen the need, this is a matter of config files and systemd. In the old dnscrypt the listen address was configured as expected:

If the socket is created by systemd, the proxy cannot change the address using this option. You should edit systemd's dnscrypt-proxy.socket file instead.

The user could have followed DNSCrypt#Change_port and it worked as expected.

In the first versions of the new dnscrypt-proxy the listen_addresses = [ ] was blank so it did not interfere. Now the config comes with listen_addresses filled in so that the user has to manually empty it or the .service will listen on those addresses[3]. Not only does this interfere with existing setups (such as using DNSCrypt with Unbound), but it is also a caveat that new users deserve to know about. -- Wincraft71 (talk) 22:04, 28 May 2018 (UTC)

In any case, users can get to know about this in DNSCrypt#Startup (see the note). -- Lahwaacz (talk) 22:40, 28 May 2018 (UTC)

The users should at least have a hint that it's related to DNSCrypt + Unbound working successfully, such as "unix socket activation" being given an example: "when using unix socket activation (such as when forwarding to a local DNS cache)" -- Wincraft71 (talk) 23:42, 28 May 2018 (UTC)

It's not related to DNSCrypt + Unbound, the startup method of DNSCrypt is irrelevant for Unbound. If you enable dnscrypt-proxy.service (and disable dnscrypt-socket.service) and set listen_addresses = ['127.0.0.1:53000', '[::1]:53000'] in dnscrypt-proxy.toml, it will too. -- Lahwaacz (talk) 07:47, 29 May 2018 (UTC)

Since that is a possible alternative, shouldn't that be stated in DNSCrypt#Change port as another option? -- Wincraft71 (talk) 09:48, 29 May 2018 (UTC)

dnscrypt-proxy resolution broken by every upgrade.

This may not have a place on the page, as it is mostly a complaint, but users should perhaps be warned that dnscrypt-proxy's DNS resolution is broken by nearly every upgrade. I have been using it for many years, and every upgrade as long as I have used it resulted in dns failing to resolve in the next session. The cause seems to be that every upgrade does something different to the systemd service/socket arrangement or configuration of dnscrypt-proxy. Upstream has dropped support for socket activation (they even deleted their example dnscrypt-proxy.service); and it is possible that this could stabilize functionality (while at the same time it broke functionality), but the AUR package still ships a set of both .service and .socket files (that do not appear to work out of the box).

One thing users can do, when they find dnscrypt-proxy broken by an upgrade, is to temporarily activate systemd-resolved, and provide an alternate dns server for their connection, until they can figure out what's gone wrong this time:

systemctl start systemd-resolved
resolvectl dns enp12s0 8.8.8.8

quequotion (talk) 06:45, 10 October 2019 (UTC)