Talk:DNSCrypt

From ArchWiki
Jump to: navigation, search

Revise or remove?

No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket and service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). quequotion (talk) 16:04, 25 January 2017 (UTC)

Draft

Redundant DNSCrypt providers

To use additional dnscrypt providers, copy /usr/lib/systemd/system/dnscrypt-proxy.service to a new file, /etc/systemd/system/dnscrypt-proxy-short-name.here.service and specify a different resolver using the -R flag with a short name from dnscrypt-resolvers.csv.

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.
[Service]
ExecStart=
ExecStart=/usr/bin/dnscrypt-proxy -R short-name.here

Then copy /usr/lib/systemd/system/dnscrypt-proxy.socket to a new file, /etc/systemd/system/dnscrypt-proxy-short-name.here.socket and, specify another port.

Comment: This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". quequotion (talk) 02:46, 26 March 2017 (UTC)

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 5353 for the original socket and 5354 for the new socket.

Comment: command-line options override the configuration file (when run as a systemd service at least) quequotion (talk) 15:29, 24 January 2017 (UTC)
Comment: If this is the case, it is a bug - the man page says OPTIONS (ignored when a configuration file is provided). -- 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. quequotion (talk) 13:34, 24 January 2017 (UTC)
Comment: Or simply have multiple config files and an instantiated service similar to this one to select the right config. -- Lahwaacz (talk) 13:45, 24 January 2017 (UTC)
Comment: Sounds good; putting this back into the proposal with some adjustments. 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. quequotion (talk) 15:07, 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.

—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)

I created new article about new version of Dnscrypt 2.x

I write about the flag on my article - Dnscrypt-proxy2.

Note: This article or section is a candidate for merging with DNSCrypt.

We have to have only one article about Dnscrypt.

Clorofilla (talk) 10:33, 14 May 2018 (UTC)

What is unclear? --Larivact (talk) 11:05, 14 May 2018 (UTC)
I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?
Clorofilla (talk) 11:51, 14 May 2018 (UTC)
Yes you can update DNSCrypt but be sure to do it gradually with edit summaries explaining your changes. --Larivact (talk) 12:19, 14 May 2018 (UTC)
I've updated Dnscrypt enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under [sources], and choosing their requirements with the require_dnssec, require_nolog, require_nofilter options. Or use server_names to choose a server from the [sources]. -- Wincraft71 (talk) 22:15, 15 May 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)