Unable to resolve: connection refused

[elXames]

Hi @elXames,

I don't run Mint, but I'll try and help ( in lieu of someone stepping in who knows better).

I might be tempted to set 127.0.0.53 in the dnscrypt-proxy.toml file
(I prefer to keep it simple)

The way to stop nm overwrting resolv.conf is to edit
/etc/NetworkManager/NetworkManager.conf
and add a line dns=none to the [main] section

QQ:
when you were following the instructions and got to the part where you run

./dnscrypt-proxy

Were there any error messages? Was that part clean?
If you leave that running in one terminal window, and open another, what do you see if you run
ss -lp 'sport = :domain'

I have a mini ubuntu server - that has resolv.conf set to 127.0.0.53 rather than the expected 127.0.0.1
Trying these can help debug a little, depending on the result from the ss command output and what you have in dnscrypt-proxy.toml

dig www.google.com @127.0.0.53
dig www.google.com @127.0.0.1

Originally posted by @ianbashford in #1692 (comment)

Hello again. Sorry, I didn't reply immediately...
I set up a new system - Debian Bullseye this time. But this shouldn't get in the way of things.

I'm going to mention every detail of my dnscrypt-proxy setup process, hoping it'll help.
First of, this time ss -lp 'sport = :domain' didn't spit out anything when I initially typed it in. So then I went looking for /etc/resolvconf but only found the file resolv.conf which had the following contents:

# Generated by NetworkManager
nameserver 192.168.0.1

Before heading on to deleting this file and creating a new one, I ran ./dnscrypt-proxy. That went smoothly, meaning no error outputs. After doing that, I went on to actually creating the new resolv.conf contains only the things mentioned in the wiki. So, I then tried to resolve example.com... Same error output as last time of course. Following your advice, I ran ./dnscrypt-proxy again and simultaneously ran ss -lp 'sport = :domain' in another terminal window. This time it gave me the following output:

udp UNCONN 0 0 127.0.0.1:domain 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.1:Domain 0.0.0.0:*

Additionally, I added dns=none to the main section of NetworkManager.conf. As I couldn't connect to the net I couldn't try out your other suggested commands. So I restarted and firstly checked resolv.conf only to find out that it was being reset - only this time it was completely empty except for that one line # Generated by NetworkManager.
Restarting didn't get me anywhere as I still couldn't connect to the net...

[elXames]

Sorry for the formatting gore. I'm still kinda new to markup :/

[elXames]

Fixed it :)

[hnnnhl]

Hey if you're still struggling, I had the same issue on CentOS 7 (linux-x86-64). My solution was to skip ahead to installing and starting dnscrypt-proxy, and then it worked. I don't know if it's supposed to work before installation, but it definitely worked after.

[elXames]

Hi! I had a lot to do the last couple of weeks so I didn't really get to work on this. But now that I had some time I went ahead and tried installing it. No problems occurred doing that. So, I then verified whether it was working properly or not by going on this website you mentioned. I don't know why but dnsleaktest.com still shows me my provider and not any of the resolvers names.
I opened port 53/udp with ufw - maybe that wasn't the right way to do it, although I doubt that. Mind that I used a pre-configured "dnscrypt-proxy.toml" file which already worked on Windows 10 - I edited that though so that the file paths work on Debian. Are there any other ways I can verify if it is working or not? On Windows dnsleaktest.com gave me same information as it did on Linux but dnscrypt-proxy worked without any problems - I used the query log and task manager as means to verify that the service was running in the background. So maybe it is working on Debian but I don't really know what to look for. Maybe a query log?

[hnnnhl]

Sorry, I don't understand. Are you saying that the resolver works fine from your windows client? Or that it doesn't work with either your Windows or Debian clients? Where are you setting your DNSCrypt-proxy resolver (Router? Client? Browser? Etc)

It might be that your default DNS somewhere is overriding wherever you've set your DNSCrypt-proxy resolver. On windows, its usually the default DNS on your internet connection (which may be taking its defaults from somewhere else). Your browser's dns settings will also likely override any others.

I would check to see if your clients are connecting to your DNSCrypt-Proxy server by running "tcpdump port 53" from your server; then browse the internet from one of your clients to see if the traffic shows up on tcpdump. If you don't see any traffic, that means your clients aren't communicating with the server. This could mean another DNS setting is overriding your DNSCrypt-proxy resolver (as mentioned above), or the connection is being blocked. For the later, check /var/log/syslog.

[elXames]

The resolver works fine from my Windows client. And I only use the resolver as a client.

[hnnnhl]

The steps above should work even if the client and server are the same machine. Just check "tcpdump port 53" to see which servers the dns traffic are being sent to. If you're just trying to check whether or not the service is running, run "systemctl status dnscrypt-proxy"

[elXames]

Okay... according to systemctl dnscrypt-proxy.service is active and "tcpdump port 53" shows that the client is communicating with multiple servers from the resolver list. But this works only with the default configuration file. When I use my personal settings no servers show up - only the log file shows me something. I can put my personal settings here for troubleshooting if you like. However, firstly I'll use the default configuration file to sort things out. So, I checked tcpdump when I browsed the internet but couldn't see any of the names of the servers. I would put the output here for you to have a better insight but I don't know if any of tcpdumps' output contains sensitive information...

[elXames]

I solved the problem with the help of a friend of mine. We just used apts dnscrypt-proxy package and made the following adjustments in a root shell:

systemctl enable systemd-resolved
mkdir /etc/systemd/resolved.conf.d
cat << EOF > /etc/systemd/resolved.conf.d/dns_servers.conf
[Resolve]
DNS=127.0.2.1
EOF
rm /etc/resolv.conf
ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved

[taicaile]

I solved the problem with the help of a friend of mine. We just used apts dnscrypt-proxy package and made the following adjustments in a root shell:

systemctl enable systemd-resolved
mkdir /etc/systemd/resolved.conf.d
cat << EOF > /etc/systemd/resolved.conf.d/dns_servers.conf
[Resolve]
DNS=127.0.2.1
EOF
rm /etc/resolv.conf
ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved

Hello, this is not working for Ubuntu 20.04, I have to manually set my each WiFi connection's DNS to 127.0.2.1.