How can I make sure that dnscrypt-proxy is properly setup?


Following this article in ArchWiki, I have tried to set up dnscrypt-proxy . Now I would like to verify that it is working as intended. How can I do this?

systemctl status dnscrypt.service outputs:

 dnscrypt-proxy.service - DNSCrypt-proxy client
     Loaded: loaded (/usr/lib/systemd/system/dnscrypt-proxy.service; enabled; vendor preset: disabled)
     Active: active (running) since Fri 2020-09-04 11:55:17 CEST; 13s ago
   Main PID: 303867 (dnscrypt-proxy)
      Tasks: 13 (limit: 19068)
     Memory: 18.6M
     CGroup: /system.slice/dnscrypt-proxy.service
             └─303867 /usr/bin/dnscrypt-proxy --config /etc/dnscrypt-proxy/dnscrypt-proxy.toml

sep 04 11:55:17 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:17] [NOTICE] Now listening to [UDP]
sep 04 11:55:17 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:17] [NOTICE] Now listening to [TCP]
sep 04 11:55:17 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:17] [NOTICE] Now listening to [::1]:53 [UDP]
sep 04 11:55:17 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:17] [NOTICE] Now listening to [::1]:53 [TCP]
sep 04 11:55:17 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:17] [NOTICE] Source [relays] loaded
sep 04 11:55:17 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:17] [NOTICE] Source [public-resolvers] loaded
sep 04 11:55:17 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:17] [NOTICE] Firefox workaround initialized
sep 04 11:55:18 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:18] [NOTICE] [cloudflare] OK (DoH) - rtt: 67ms
sep 04 11:55:18 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:18] [NOTICE] Server with the lowest initial latency: cloudf>
sep 04 11:55:18 eos dnscrypt-proxy[303867]: [2020-09-04 11:55:18] [NOTICE] dnscrypt-proxy is ready - live servers: 1

There is some checking method described here.

Thanks for quick reply and the info! I’ll look into it.

But now after the reboot the content of the /etc/resolv.conf which according to the Wiki post should be replaced by:

nameserver ::1
options edns0 single-request-reopen

is back to the original:

# Generated by NetworkManager

What should I do to make it survive a reboot?

Would it be possible to simply lock it by chattr +i /etc/resolv.conf?

1 Like

Great, I’ll try that!

This worked!

I’ll check out the link you posted earlier, a bit later this evening. Hopefully it is working as expected.

Thank you!

1 Like

A much better solution [1] is to edit NetworkManager config, by creating a file /etc/NetworkManager/conf.d/dns.conf with the following content:


If you want to check if dnscrypt-proxy is running, simply go to or or similar sites.



Great, thanks!
Do I need to revert this chattr +i /etc/resolv.conf? Is it done by changing the + to - ?

Note that the chattr method is fine enough, it’s just a little “dirty”.


Sure. I will make the change as per your suggestion. And thanks for the link, I’ll look at it.

Yeah NetworkManager is a beast, has tons of options. Same as for DNS resolving methods. I found it to be quite hard to understand how they interact.

By the way, now that you have dnscrypt-proxy, you can add an “ad-blocker” list to it. It works in a similar way to an /etc/hosts file.
It’s in the config file under “pattern-based blocklist”, you just to have to add your existing list to it.

You can also create one yourself with a python script:


Thanks @anon31687413 for all the suggestions and help! This is a new area for me so I will need to do some homework. The possibility to add an “ad-blocker” list is great. I’ll certainly look into it. But will this eliminate the need of ad-blocker addons for the browser?

1 Like

I keep the Firefox add-ons in case something gets through :wink:
The advantage of dnscrypt-proxy’s blocklist feature is that is active system-wide.

1 Like

Great, thanks for the explanation!

I use uBlock Origin, and lately I have added uMatrix as well. With the latter I am making small progresses everyday and sometimes I have to switch it off to make some things work on some sites. But that is mostly because I am still learning how it works. uBlock is much more straight forward.

1 Like

Good choice :slight_smile: I have both, too. Have fun!

1 Like

Thanks! You too! I may very well come back to this thread if I have some more questions, until then I wish you and @csteinforth a nice weekend. Thanks again to you both for helping out!

1 Like

I did not configure any server_names, so I get a couple of servers listed on those pages. How I do I have to interpret those servers?

is dnscrypt the best option to enable DoH or DoT systemwide?
it seems not so easy to configure :slight_smile:

I checked with and it seems to be working.

With server_names = ['Cloudflare'] I get only one IP address for DNS server belonging to Cloudflare. However when I comment out the server_names line, dnscrypt-proxy uses the servers specified in a remote list.

servers from remote list




Remote lists of available servers

Multiple sources can be used simultaneously, but every source

requires a dedicated cache file.

Refer to the documentation for URLs of public sources.

A prefix can be prepended to server names in order to

avoid collisions if different sources share the same for

different servers. In that case, names listed in server_names

must include the prefixes.

If the urls property is missing, cache files and valid signatures

must already be present. This doesn’t prevent these cache files from

expiring after refresh_delay hours.


An example of a remote source from

urls = [‘’, ‘’]
cache_file = ‘/var/cache/dnscrypt-proxy/’
minisign_key = ‘RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3’
prefix = ‘’

Checking again with, I get 13 IP adresses for DNS servers from almost all over the world. I believe this is the same as mentioned above by @csteinforth. Is this ok?

By the way, is Cloudflare ok to use as DNS server? Do you have some recommendation on “privacy respecting” servers? Or I could just trust the ones from the remote file?

Yep, this is my question, too.

1 Like