Unbound doesn't work with DNScrypt-proxy (ssl handshake failed crypto error)

[lbrooney]

Operating System

DietPi

Architecture

64-bit

Platform

Linux

Project

Unbound, DNScrypt

Browser

Firefox, Chrome, Other

Issue

Other (explain in description)

Issue Description

I believe I'm having the same issue as #59, but I didn't want to necro.

Both Unbound and DNScrypt-proxy are running on the same Pi. Unbound is running on port 5335, DNScrypt-proxy on 6053. If I dig google.com @127.0.0.1 -p 6053 Google resolves to an IP.

If I attempt to dig google.com @127.0.0.1 -p 5335 with the config below, I don't get an answer. I just trimmed it to what I believe is relevant. Only DNScrypt's forward-addrs are uncommented.

server:
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
forward-zone:
  name: "."
  forward-tls-upstream: yes
  # DNScrypt proxy
  forward-addr: 127.0.0.1@6053
  forward-addr: ::1@6053

Checking the logs with verbosity at 1, I get a lot of:

DietPi unbound[1944]: [1944:0] error: ssl handshake failed crypto error:00000000:lib(0)::reason(0)
DietPi unbound[1944]: [1944:0] notice: ssl handshake failed 127.0.0.1 port 6053
DietPi unbound[1944]: [1944:0] error: ssl handshake failed crypto error:00000000:lib(0)::reason(0)
DietPi unbound[1944]: [1944:0] notice: ssl handshake failed ::1 port 6053

If I set forward-tls-upstream to no, dig google.com @127.0.0.1 -p 5335 now resolves.

So what I suspect is that when forward-tls-upstream is yes, Unbound is correctly attempting to DoT to DNScrypt-proxy, but DNScrypt-proxy only works with regular DNS requests, giving us the ssl handshake failed crypto. I don't believe there is way to make it so Unbound does not attempt this for a single forward-addr, only at a forward-zone level and I think you can only have one "." forward-zone. Unbound correctly resolves domains when configured with the other forward-addrs (I can't speak for Stubby).

I am not intimately familiar with these technologies so I admit I could be entirely wrong about this. If I'm not, then Unbound and DNScrypt config section needs to be updated. Also if DNScrypt would then not be accessed only by Unbound, then probably best to enable DNScrypt's caching. Or maybe keep caching disabled and also disable Unbound and have Adguard Home/Pi-Hole handle caching.

If Unbound can make DoH requests then maybe you can setup DNScrypt to accept DoH requests and then still have DNScrypt handle the related. I believe you can make Unbound accept DoH requests, but I don't know if it can make DoH requests itself.

Thanks!

[welcome[bot]]

Thanks for opening your first issue here 🙋🕵️

[trinib]

hey @lbrooney sorry for late reply . I see you using diet pi , did you check to see anything service in diet pi is using port 5335 ??? Check port:

sudo netstat -anp | grep 5335 
or
sudo lsof -i :5335

Disable package:

sudo systemctl stop SERVICE_NAME && sudo systemctl disable SERVICE_NAME  
or
sudo apt-get remove SERVICE_NAME

Also you would need to follow this from readme

[!IMPORTANT] If using DietPi or other OS that do not auto insert nameserver 127.0.0.1 in resolv.conf(to check - sudo nano /etc/resolv.conf) and want to query cache on local hosts, just install resolvconf package and restart unbound-resolvconf.service which should be automatically set:

sudo apt-get install resolvconf -y && sudo systemctl restart unbound-resolvconf.service

Run ping -c 3 google.com to confirm localhost is reachable to internet. If not, set/add your default network's dns/gateway or whatever was the default🔗click here🔗

Confirm 127.0.0.1 address interface is up:

Install dig: sudo apt install dnsutils

dig google.com @127.0.0.1

---

More Optional Info

DietPi is a lightweight system optimized for low-resource devices like the Raspberry Pi, and it makes some system-wide adjustments that can affect networking, services, or packages. Here are possible areas in DietPi that could be causing the issue and suggestions for adjustments:

1. Firewall (IPTables) or DNS Redirection Settings

DietPi may have different firewall rules or DNS redirection mechanisms compared to a standard Raspberry Pi OS. These could interfere with how Unbound or DNScrypt-proxy communicates over specific ports (5335 for Unbound, 6053 for DNScrypt-proxy).

Solution: Check and adjust firewall rules

Verify that the necessary ports (5335 for Unbound and 6053 for DNScrypt-proxy) are open. You can check the current firewall rules with:

sudo iptables -L

If the ports are blocked, you can open them by adding rules like:

sudo iptables -A INPUT -p tcp --dport 5335 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 6053 -j ACCEPT

If using ufw, ensure the necessary ports are allowed:

sudo ufw allow 5335/tcp
sudo ufw allow 6053/tcp

2. Networking Stack

DietPi has a different set of optimizations for networking performance, including how DNS and network interfaces are managed. It might have changes that interfere with how Unbound or DNScrypt-proxy handle DNS requests, especially when using loopback addresses like 127.0.0.1 or ::1.

Solution: Check and adjust networking settings

Check the network stack for issues. Run the following command to ensure the loopback interface is correctly set up:

ifconfig lo

Make sure the loopback interface is active. If not, activate it:

sudo ifconfig lo up

Also, DietPi might be using systemd-resolved or dnsmasq for DNS caching. Ensure there’s no conflict between these services and Unbound/DNScrypt-proxy.

To check DNS services:

sudo systemctl status systemd-resolved
sudo systemctl status dnsmasq

If one of these is running and you don’t need it, you can disable it:

sudo systemctl disable dnsmasq
sudo systemctl stop dnsmasq

3. DietPi Optimizations

DietPi may apply system-wide optimizations during installation or setup that alter how services like Unbound or DNScrypt-proxy work. Some of these optimizations might involve energy-saving measures or service reductions that cause networking issues.

Solution: Disable or adjust DietPi optimizations

Check the system optimizations by running:

sudo dietpi-config

Go to "Performance Options" and ensure no aggressive power-saving measures or CPU throttling are enabled that might affect network performance.

[havardthom]

I also had this problem with Unbound + DNScrypt-proxy on an Adguard LXC (Debian 12) in Proxmox. Tried debugging the issue for a couple of hours but gave up and also ended up removing forward-tls-upstream: yes from unbound.conf. You're reasoning does seem correct and maybe the guide should be updated to address this. My queries are still resolved by both unbound (DoT) on 127.0.0.1:5335 and DNScrypt-proxy (DoH) on 127.0.0.1:53535 even though the forward-tls-upstream: yes option is removed from unbound.conf.

[trinib]

hmm its been a while I used Adguard Home. Interface UI and settings etc maybe changed a lot. Like what i told someone a while ago Github issues will be dead soon. Just use AI @havardthom ask just ask anything and copy and paste code etc and get results 1000x faster and better. I like Claude AI and ChatGPT. 🙏