Fixing #304 doesn't look trivial
The service module needs to know the arguments right away.
The arguments haven't been parsed yet. And if we do, we will prevent
further arguments to be added to the set. Including the ones added
by the service module itself.
So, we have quite of a circular dependency here.
If someone with some Go knowledge can fix that, that would be amazing.
But it's probably never going to happen.
Meanwhile, we can try to save the current directory and document
that we have to be in that directory when running the install command.
Which is not going to work on Windows, so this is a big fucking mess
What's in the DNS packet is a better source of truth.
There was also an inconsistency between the TTL from the
max-age header (as returned in a response that wasn't cached) and
a response from the cache (using TTLs from the DNS packet).
So, just use what's in the packet.
Reported by @vavrusam, thanks!
* Adding nss-lookup.target to the socket Before and Wants directive. Adding current upstream wiki as documentation to service and socket file.
Adding DynamicUser=yes to the service file, alongside various hardening settings (Protect{ControlGroups,KernelModules}. Allowing the service to bind to ports below 1024 by setting CAP_NET_BIND_SERVICE. Adding {Cache,Logs,Runtime}Directory for dnscrypt-proxy. Removing (default) Type=simple. Adding a more default ExecStart location and usage of configuration.
* systemd/dnscrypt-proxy.socket: Adding back ipv6 functionality.
* systemd/dnscrypt-proxy.service: Updating Description to match project name.
Explicitely setting ProtectHome=yes. Adding information on the DynamicUser settings.
* systemd/dnscrypt-proxy.socket: Updating description to match project name.
* systemd/dnscrypt-proxy.service: Adding Requires= and Also= for dnscrypt-proxy.socket in favor of CAP_NET_BIND_SERVICE capabilities.
* dnscrypt-proxy/example-dnscrypt-proxy.toml: Clarifying how to set listen_addresses, when using systemd socket activation.
This reverts commit 91f97833a3.
The Internet has become a sad place.
People in China need to use resolvers in China.
People in the US would not trust resolvers in China.
People in the EU would not trust resolvers in the US.
Revert to Quad9 for now, and add some documentation about why
that might be changed (especially in China) later.
