Difference between revisions of "Talk:Dnscrypt-proxy"

From ArchWiki
Jump to navigation Jump to search
(→‎Revise or remove?: clearing closed discussion)
(43 intermediate revisions by 6 users not shown)
Line 1: Line 1:
== <s>Refactoring to include dnscrypt-wrapper information & configuration.</s> ==
+
== Backup DNSCrypt resolver - especially with the new configuration file ==
  
Hello, I'm new so bear with me if I get any of this wrong. I would like to refactor the page to reflect the addition of {{AUR|dnscrypt-wrapper}} to the AUR. dnscrypt-wrapper is the server-side wrapper for dnscrypt-proxy. Any advice on the best way to do this would be appreciated. Would adding sub-headings for both packages below Installation & Configuration be the best approach?
+
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).
  
Thanks
+
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).
[[User:MeZee|MeZee]] ([[User talk:MeZee|talk]]) 17:57, 10 January 2016 (UTC)
 
  
:Just add it to the Installation section and describe what it does. [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 17:13, 23 September 2016 (UTC)
+
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?
  
:: Closing  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 15:04, 24 January 2017 (UTC)
+
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.
  
== 1.8.1 Update: New /etc/dnscrypt-proxy.conf ==
+
{{unsigned|11:56, 30 December 2016‎|Utini2000}}
  
There's a new configuration file that is not reflected in the article, as well as a new systemd unit. Users should now use that configuration file, but at least for me, the update to 1.8.1 did not break my old units (since I used {{ic|systemd edit}}. This is a section for discussing modifications needed for the update.  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 22:45, 27 December 2016 (UTC)
+
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)
  
This may just need to be in an advanced section. [https://github.com/jedisct1/dnscrypt-proxy/blob/master/README-WINDOWS.markdown#advanced-configuration].  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 23:00, 27 December 2016 (UTC)
+
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}
 
 
It seems like the configuration file is not useful if using systemd: [https://github.com/jedisct1/dnscrypt-proxy/issues/528]  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 13:18, 28 December 2016 (UTC)
 
 
 
::You may be jumping to conclusions. Only the ListenAddress option is discussed there; it cannot be inferred that this means all of the options in the configuration file are ignored if they are already set in the systemd socket/service files. IMHO, if there is an independent configuration file that can set options (and use .pac{new,save}) then it is superior to use it rather than edit the sytemd files which are overwritten by every install and less confusing than putting custom options in places like cat /etc/systemd/system/dnscrypt-proxy.{service,socket}.d/override.conf
 
 
 
::If it can be done, I think it would be prudent to ship dnscrypt-proxy with systemd files that don't set options that can be set by its native configuration file, and change the wiki to describe setting it up by its own configuration file. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 12:23, 23 January 2017 (UTC)
 
 
 
:::And it appears this cannot be done for the socket. If one intends to use systemd to open the socket, the listen address must be set in the socket file or its override.conf. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 12:36, 23 January 2017 (UTC)
 
 
 
:::You will need to file a bug report / feature request if you want to make changes with what files are shipped with the package (possibly with both Arch and upstream). This is a place to discuss what needs to be done on the wiki page to reflect that a configuration file is available.  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 18:00, 23 January 2017 (UTC)
 
 
 
::::True, but since they'd need to be done simultaneously--and the bug report / feature request will be dismissed out of hand without a proposal here to back it up (and probably dismissed anyway just because), I'm going to go ahead and get started with a changes proposal here first. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 07:02, 24 January 2017 (UTC)
 
 
 
:::::I have no idea where you are going, but the current {{ic|dnscrypt-proxy.service}} looks [https://github.com/jedisct1/dnscrypt-proxy/blob/1.9.3/dnscrypt-proxy.service like this], i.e. it does not specify any option besides the config file path. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:13, 24 January 2017 (UTC)
 
 
 
::::::Oh. Is that what's shipping in arch's package? If so, the changes I'm proposing are ready for debate as a (partially) new page. The point is to avoid making changes to the .service file. This file will be overwritten when dnscrypt-proxy gets upgraded, potentially breaking internet connectivity; it's much safer to configure dnscrypt-proxy outside of this file. Furthermore the config file is quite user-friendly; the included dnscrypt-proxy.conf.example documents the options quite well (in English at least). Only users who want to do something special like instanced services should be editing the .service file. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:26, 24 January 2017 (UTC)
 
  
:::::::Nobody was suggesting anywhere to make changes to the service file in {{ic|/usr/lib/systemd/}} directly. All instructions use the [[edit]] link, which implies using {{ic|systemctl edit}} or {{ic|systemctl edit --full}}, which create either a drop-in snippet or an overriding service, both placed in {{ic|/etc/systemd/}}. Hence the argument about having the changes overwritten on package upgrades does not apply. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:42, 24 January 2017 (UTC)
+
== DNSCrypt download page and github project seems to be down ==
  
::::::::I understand your logic, but I can't be the only impatient person who didn't click there and edited it directly anyway. Regardless, having less to figure out is better. Maybe I'm old-fashioned, but I think it's easier to work with an ordinary config file in the text editor of my choice and not have to interact with systemctl whenever it can be avoided. There's no ''need'' to go that far under-the-hood in this case. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:40, 24 January 2017 (UTC)
+
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)
  
:::::::::If you want to use a local DNS cache like [[unbound]] you still have to edit the {{ic|.socket}} file, even when using the configuration file. Either way, I think the configuration file does need to be mentioned in the page, along with this limitation.  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 14:50, 24 January 2017 (UTC)
+
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)
  
::::::::::I think it would be best to recommend using the config file for the most obvious, single-instance configuration and spare the details of editing the service file for things like instanced implementations. If we can get {{Bug|49881}} resolved, I'd be happy to do away with the whole section about specifying a user. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:38, 24 January 2017 (UTC)
+
== "CapabilityBoundingSet" in /* Sandboxing */ ==
  
==Proposal: Configuration by config file==
+
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:
It seems more sane to me that users should not edit the .service file to change options except for advanced needs like multiple instances. This way users avoid several {{ic|systemctl daemon-reload}}s and the package maintainer could use .pac{new,save} to protect user configurations across upgrades. Note, rather than copy and paste the entire page here, I have only posted the specific sections I intend to change; do not take the absence of a particular piece of information to explicitly imply its intended deletion. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:37, 24 January 2017 (UTC)
 
  
== Configuration ==
+
{{bc|1=
 +
archlinux systemd[1]: Started DNSCrypt-proxy client.
  
{{Tip|A thorough example configuration file, {{ic|/etc/dnscrypt-proxy.conf.example}} is included, but note that systemd overrides the {{ic|LocalAddress}} option with a [[#Change_port|socket file]]}}
+
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted
  
To configure ''dnscrypt-proxy'', perform the following steps:
+
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted
  
=== Select resolver ===
+
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES
  
Select a resolver from {{ic|/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv}} and edit {{ic|/etc/dsncrypt-proxy.conf}}, using a short name from the csv file's first column, {{ic|Name}}. For example, to select ''dnscrypt.eu-nl'' as the resolver:
+
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}
 +
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)
  
ResolverName dnscrypt.eu-nl
+
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)
{{Comment|I think the language change regarding the csv file should go in regardless, but I didn't just go ahead with it in case that only sounds less confusing to me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}
 
  
 +
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)
  
{{Comment|Looks good to me.  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 18:20, 24 January 2017 (UTC)}}
+
== Startup method when using Unbound ==
  
=== Redundant DNSCrypt providers ===
+
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[DNSCrypt#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].
  
To use additional dnscrypt providers, you may copy {{ic|/etc/systemd/system/dnscrypt-proxy.service}} and {{ic|/etc/systemd/system/dnscrypt-proxy.socket}} to new files.
+
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[DNSCrypt#Startup]] section. As it is now, the {{ic|dnscrypt-proxy.toml}} file contains {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}} so for an average user following [[DNSCrypt#Unbound]] (especially when coming directly from the [[Unbound]] page) this would lead to a misconfiguration. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 15:34, 28 May 2018 (UTC)
  
Specify a different resolver using the {{ic|-R}} flag and a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] in the new service file.
+
:You need to 1. configure [[unbound]], and 2. configure [[DNSCrypt]], so you should read both pages (from the start). Why is that not clear? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:11, 28 May 2018 (UTC)
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}
+
::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. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:05, 28 May 2018 (UTC)
  
[Service]
+
::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:
ExecStart=
 
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''
 
  
Then specify a different port in the new [[#Change_port|{{ic|socket file}}]].
+
::{{bc|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.}}
  
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.
+
::The user could have followed [[DNSCrypt#Change_port]] and it worked as expected.
  
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}
+
::In the first versions of the new dnscrypt-proxy the {{ic|<nowiki>listen_addresses = [ ]</nowiki>}} was blank so it did not interfere. Now the config comes with {{ic|listen_addresses}} filled in so that the user has to manually empty it or the {{ic|.service}} will listen on those addresses[https://raw.githubusercontent.com/jedisct1/dnscrypt-proxy/master/dnscrypt-proxy/example-dnscrypt-proxy.toml]. 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. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:04, 28 May 2018 (UTC)
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}
 
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}
 
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}
 
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}
 
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}
 
===== Add dnscrypt-sockets =====
 
  
For the first dnscrypt-proxy socket, listening on 127.0.0.1@5353 and connecting to the example ''dnscrypt.eu-nl'' provider, copy {{ic|/lib/systemd/system/dnscrypt-proxy.socket}} to {{ic|/etc/systemd/system/dnscrypt-proxy@''dnscrypt.eu-nl''.socket}} and edit the file to reflect the [[#Change_port|correct port]] (5353 in this case).
+
:::In any case, users can get to know about this in [[DNSCrypt#Startup]] (see the note). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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)" -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 23:42, 28 May 2018 (UTC)
  
For additional dnscrypt-proxy sockets, copy {{ic|/lib/systemd/system/dnscrypt-proxy.socket}} to {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and change the port to 5354 and so forth.
+
:::::It's not related to DNSCrypt + Unbound, the startup method of DNSCrypt is irrelevant for Unbound. If you enable {{ic|dnscrypt-proxy.service}} (and disable {{ic|dnscrypt-socket.service}}) and set {{ic|1=listen_addresses = ['127.0.0.1:53000', '[::1]:53000']}} in {{ic|dnscrypt-proxy.toml}}, it will too. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:47, 29 May 2018 (UTC)
  
{{Comment|Decided to withdraw proposal for instanced config files; although there might be some edge use-case for the idea it isn't practical considering someone who wants instanced dnscrypt-services probably won't be uncomfortable with editing service files and specifying command line options. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:31, 24 January 2017 (UTC)}}
+
::::::Since that is a possible alternative, shouldn't that be stated in [[DNSCrypt#Change port]] as another option? -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 09:48, 29 May 2018 (UTC)
:{{Comment|If there are no complaints I might just put this part in--it isn't dependent on the rest of the proposal and is mostly just a streamlining of the two subsections on the page. I intend to keep the example that follows as-is. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 17:49, 24 January 2017 (UTC)}}
 
 
 
=== dnscrypt runs with root privileges ===
 
 
 
See {{Bug|49881}}. To work around this, create an unprivileged user manually.
 
 
 
[[Users_and_groups#User_management|Create the user]] as follows:
 
 
 
# useradd -r -d /var/dnscrypt -m -s /sbin/nologin dnscrypt
 
 
 
Edit {{ic|/etc/dnscrypt-proxy.conf}}, appending the new user:
 
 
 
User dnscrypt
 
 
 
{{Comment|If you use an unprivileged port (e.g. 5353) you can let systemd handle the user as in the current version of the wiki page. This version above has the systemd unit running as root still and doesn't drop it until dnscrypt runs. By using {{ic|1=User=}} in the systemd unit the entire unit runs without root privileges.  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 14:58, 24 January 2017 (UTC)}}
 
:{{Comment|Which is why I've proposed no changes to that subsection. This is intended only to replace the lines that demontrate specifying the user on the command line in the service file. In fact, I suppose those lines could be removed from the wiki, but that would have users editing service files again (until {{Bug|49881}} is resolved; not sure what's holding it back). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:20, 24 January 2017 (UTC)}}
 
::{{Comment|Got it. Looks good to me. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 18:20, 24 January 2017 (UTC)}}
 
 
 
== Backup DNSCrypt resolver - especially with the new configuration file ==
 
 
 
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).
 
 
 
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).
 
 
 
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?
 
 
 
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.
 
 
 
{{unsigned|11:56, 30 December 2016‎|Utini2000}}
 
 
 
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)
 
 
 
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}
 

Revision as of 13:54, 14 June 2019

Backup DNSCrypt resolver - especially with the new configuration file

Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).

I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).

I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?

Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.

—This unsigned comment is by Utini2000 (talk) 11:56, 30 December 2016‎. Please sign your posts with ~~~~!

It already describes that: DNSCrypt#Redundant_DNSCrypt_providers -- Lahwaacz (talk) 12:02, 30 December 2016 (UTC)
But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? —This unsigned comment is by Utini2000 (talk) 16:21, 30 December 2016. Please sign your posts with ~~~~!

DNSCrypt download page and github project seems to be down

All I could find was this Reddit thread [1] and a new Github project here and here -- Wincraft71 (talk) 03:23, 8 January 2018 (UTC)

The "dyne" link seems to have an updated resolvers.csv [2] -- Wincraft71 (talk) 03:23, 8 January 2018 (UTC)

"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 [3]. -- 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 [4].

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[5]. 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)