Can't specify DNSCrypt-Proxy 2 Listen Address

Expected Behaviour:

After getting my Pi-Hole working with Cloudflared and Unbound on separate listening addresses, I installed DNSCrypt-Proxy 2.0.

After doing so, I changed the DNSCrypt listen_address flag to and expected it to work (my other proxies/resolvers are on .2:5552 and .3:5553).

Actual Behaviour:

It didn’t work. Sudo netstat -tulpen | grep 5554 showed nothing and running the command w/o the | showed that DNSCrypt wasn’t listening on any port.

I changed back to and it worked fine.

I would like to be able to change the address so I can name the proxy in Hosts and have it display separately in the Pi-Hole’s “Queries answered by” chart.

Having implemented similar changes for Cloudflared and Unbound, I’m not sure what is different about DNSCrypt.

Any advice would be appreciated.

Debug Token:!

I would inquire on the DNSCrypt support site/github.

Why do you run all of these in parallel? That would seem to negate any advantage that one method has over the others.

Thanks, I’ll do that. I had seen similar questions answered here.

I’m not running all three in parallel.

Right now, I’m running DNSCrypt-Proxy with Unbound (recursive only) as a back up using the “strict-order” flag in dnsmasq.

I am no longer using Cloudflared (it seems unstable) and I may stop using Unbound once I better understand how DNSCrypt handles fallback.

What I’ve been trying to accomplish from the beginning is using DoH/DoT upstream servers with a local recursive server as a fallback.

I thought Unbound would do this on its own and I believe later versions will. But the 1.6.0 version available on Raspbian Stretch doesn’t use tls-cert-bundles. So DoT isn’t implemented properly (can’t authenticate from what I understand).

Thanks for your help.



You may find that this method doesn’t work. I believe there is an open dnsmasq issue regarding strict order.

What do you see as the advantages of using encrypted DNS over unbound?

I agree. It’s difficult to test. If I stop my primary resolver/proxy, it appears to fall back. But I’m not sure what would happen if the primary simply failed.

When I was using Cloudflared with Unbound as a backup and Clouflared crashed, everything stopped working. No backup. Not sure where the issue was.

My only answer to this is that it seems that encrypted DNS is more private that running a local recursive resolver. Of course, I appreciate that once I actually browse to a website, this would go out the window (absent ESNI).

Also, sometimes I use a VPN without blocking outside DNS so that I get the benefit of my Pi-Hole. If I’m using encrypted DNS, both my DNS and my traffic are hidden. I’m under the impression that my DNS would be “in the clear” if I used a local recursive resolver under the same scenario.

Please feel free to set me straight if I’ve got any of this wrong.

Thanks for your help.



For the VPN, I agree with your conclusion. I don’t think that encrypted DNS gives you any more privacy without a VPN - the ISP sees all your IP traffic anyway, and with encrypted DNS you are entrusting your entire DNS history to a third party. With unbound, it stays local. For that reason, I believe that unbound gives you better privacy (and equal security) than encrypted DNS.

I’m glad we’re in agreement on this as it has been central to my configuration choices.

I agree with your comments about trusting DNS history to a third party being a downside of using encrypted DNS servers.

If you locally compile the current version of unbound, you should be able to have unbound do the whole thing for you with no backup.

Thank you for suggesting this.

I tried this and it was kind of a nightmare. I’ll probably try again sometime soon.

Hope you have a good weekend.



1 Like

This community here stepped up with some instructions for me when I asked.

you’ll find some instructions in this old article, showing how to run unbound, dnscrypt-proxy and stubby all on the same system.

partial content of my current unbound.conf:

	logfile: /unbound.log
	log-time-ascii: yes
	verbosity: 1
	do-ip4: yes
	do-udp: yes
	do-tcp: yes

partial content of /opt/dnscrypt-proxy/dnscrypt-proxy.toml:

server_names = ['scaleway-fr', '', '']
listen_addresses = ['']
ipv4_servers = true
dnscrypt_servers = true
doh_servers = true
require_dnssec = true
require_nolog = true
require_nofilter = true

output from sudo netstat -tulpen | grep 555 (list both port 5554 and port 5552)

pi@raspberrypi:~ $ sudo netstat -tulpen | grep 555
tcp        0      0*               LISTEN      0          13515      802/unbound
tcp        0      0*               LISTEN      0          12460      276/dnscrypt-proxy
udp        0      0*                           0          13514      802/unbound
udp        0      0*                           0          12459      276/dnscrypt-proxy

partial content of /etc/dnsmasq.d/01-pihole.conf:

# dnscrypt-proxy v2
# unbound


Thanks, @jpgpi250. I saw that post and had consulted it.

I had no issue changing the listening addresses for Unbound and Cloudflared in their respective config files and then conforming that change to dnsmasq.d and my hosts file.

DNSCrypt is the outlier. The same change doesn’t take.

I will keep playing with it.

Thanks again.



This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.