Problems with Unbound

Hello,

Unbound does not want to run for me. I just reinstalled it on my Raspberry Pi 4 running DietPi v8.3.1 with AdGuard.
A dig request via SSH already does not work, it comes

Command not found

.

service unbound status
● unbound.service - Unbound DNS server
     Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/unbound.service.d
             └─dietpi.conf
     Active: active (running) since Sun 2022-04-10 11:37:28 CEST; 6min ago
       Docs: man:unbound(8)
    Process: 3370 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
    Process: 3373 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
   Main PID: 3376 (unbound)
      Tasks: 1 (limit: 4915)
        CPU: 161ms
     CGroup: /system.slice/unbound.service
             └─3376 /usr/sbin/unbound -d -p

Apr 10 11:37:28 DietPi systemd[1]: Starting Unbound DNS server...
Apr 10 11:37:28 DietPi package-helper[1872]: /var/lib/unbound/root.key does not exist, copying from /usr/share/dns/root.key
Apr 10 11:37:28 DietPi unbound[3376]: [3376:0] info: start of service (unbound 1.13.1).
Apr 10 11:37:28 DietPi systemd[1]: Started Unbound DNS server.

This is what /etc/unbound/unbound.conf.d/dietpi.conf looks like:

# https://nlnetlabs.nl/documentation/unbound/unbound.conf/
server:
	# Do not daemonize, to allow proper systemd service control and status estimation.
	do-daemonize: no

	# A single thread is pretty sufficient for home or small office instances.
	num-threads: 1

	# Logging: For the sake of privacy and performance, keep logging at a minimum!
	# - Verbosity 2 and up practically contains query and reply logs.
	verbosity: 0
	log-queries: no
	log-replies: no
	# - If required, uncomment to log to a file, else logs are available via "journalctl -u unbound".
	#logfile: "/var/log/unbound.log"

	# Set interface to "0.0.0.0" to make Unbound listen on all network interfaces.
	# Set it to "127.0.0.1" to listen on requests from the same machine only, useful in combination with Pi-hole.
	interface: 127.0.0.1
	# Default DNS port is "53". When used with Pi-hole, set this to e.g. "5335", since "5353" is used by mDNS already.
	port: 5335

	# Control IP ranges which should be able to use this Unbound instance.
	# The DietPi defaults permit access from official local network IP ranges only, hence requests from www are denied.
	access-control: 0.0.0.0/0 refuse
	access-control: 10.0.0.0/8 allow
	access-control: 127.0.0.1/8 allow
	access-control: 172.16.0.0/12 allow
	access-control: 192.168.0.0/16 allow
	access-control: ::/0 refuse
	access-control: ::1/128 allow
	access-control: fd00::/8 allow
	access-control: fe80::/10 allow

	# Private IP ranges, which shall never be returned or forwarded as public DNS response.
	# NB: 127.0.0.1/8 is sometimes used by adblock lists, hence DietPi by default allows those as response.
	private-address: 10.0.0.0/8
	private-address: 172.16.0.0/12
	private-address: 192.168.0.0/16
	private-address: 169.254.0.0/16
	private-address: fd00::/8
	private-address: fe80::/10

	# Define protocols for connections to and from Unbound.
	# NB: Disabling IPv6 does not disable IPv6 IP resolving, which depends on the clients request.
	do-udp: yes
	do-tcp: yes
	do-ip4: yes
	do-ip6: yes

	# DNS root server information file. Updated monthly via cron job: /etc/cron.monthly/dietpi-unbound
	root-hints: "/var/lib/unbound/root.hints"

	# Maximum number of queries per second
	ratelimit: 1000

	# Defend against and print warning when reaching unwanted reply limit.
	unwanted-reply-threshold: 10000

	# Set EDNS reassembly buffer size to match new upstream default, as of DNS Flag Day 2020 recommendation.
	edns-buffer-size: 1232

	# Increase incoming and outgoing query buffer size to cover traffic peaks.
	so-rcvbuf: 4m
	so-sndbuf: 4m

	# Hardening
	harden-glue: yes
	harden-dnssec-stripped: yes
	harden-algo-downgrade: yes
	harden-large-queries: yes
	harden-short-bufsize: yes

	# Privacy
	use-caps-for-id: yes # Spoof protection by randomising capitalisation
	rrset-roundrobin: yes
	qname-minimisation: yes
	minimal-responses: yes
	hide-identity: yes
	identity: "Server" # Purposefully a dummy identity name
	hide-version: yes

	# Caching
	cache-min-ttl: 300
	cache-max-ttl: 86400
	serve-expired: yes
	neg-cache-size: 4M
	prefetch: yes
	prefetch-key: yes
	msg-cache-size: 50m
	rrset-cache-size: 100m

What is my problem?

Sorry, for my bad english.

Honestly I don’t understand the problem? The issue is that dig is not working? This is correct as dig is part of dnsutils package, which is not intalled by default. You need to install it manually

apt install dnsutils

According your information unbound service is working fine > Active: active (running)

Ok, have DiG now installed here, but on my other Pi (also with DietPi) was already on it.
If I check Unbound here now, it does not work:

dig dietpi.com @127.0.0.1

; <<>> DiG 9.16.27-Debian <<>> dietpi.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12578
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dietpi.com.                    IN      A

;; Query time: 4999 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 10 13:14:07 CEST 2022
;; MSG SIZE  rcvd: 28

This is how it should look:

root@DietPi:/home/dietpi# dig dietpi.com @127.0.0.1

; <<>> DiG 9.16.27-Debian <<>> dietpi.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13185
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dietpi.com.                    IN      A

;; ANSWER SECTION:
dietpi.com.             131     IN      A       188.114.96.7
dietpi.com.             131     IN      A       188.114.97.7

;; Query time: 10 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 10 13:18:26 CEST 2022
;; MSG SIZE  rcvd: 71

It just does not work!

can you share the LISTEN processes

ss -tulpn | grep LISTEN

Clear

 ss -tulpn | grep LISTEN
tcp   LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=379,fd=3))
tcp   LISTEN 0      256        127.0.0.1:5335      0.0.0.0:*    users:(("unbound",pid=378,fd=4))
tcp   LISTEN 0      256        127.0.0.1:8953      0.0.0.0:*    users:(("unbound",pid=378,fd=6))
tcp   LISTEN 0      4096               *:8083            *:*    users:(("AdGuardHome",pid=363,fd=14))
tcp   LISTEN 0      4096               *:53              *:*    users:(("AdGuardHome",pid=363,fd=13))
tcp   LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=379,fd=4))
tcp   LISTEN 0      256            [::1]:8953         [::]:*    users:(("unbound",pid=378,fd=5))

Your challenge seems to be AGH or the communication between AGH and Unbound. As you can see you have AGH running on port 53.

tcp   LISTEN 0      4096               *:53              *:*    users:(("AdGuardHome",pid=363,fd=13))

Means your dig command will ask AGH instead of Unbound. To check Unbound, you would need to specify the port 5335 Unbound is running on:

dig @127.0.0.1 -p 5335 dietpi.com

I had already tried

dig dietpi.com @127.0.0.1 -p 5335

; <<>> DiG 9.16.27-Debian <<>> dietpi.com @127.0.0.1 -p 5335
;; global options: +cmd
;; connection timed out; no servers could be reached

It does not work over port 53 either.

One addition, when I am in the Adguard interface I always get an error:

Error: control/version.json | Couldn't get version check json from https://static.adguard.com/adguardhome/release/version.json: *fmt.wrapError updater: HTTP GET https://static.adguard.com/adguardhome/release/version.json: Get "https://static.adguard.com/adguardhome/release/version.json": read udp 127.0.0.1:48380->127.0.0.1:5335: i/o timeout | 502

It doesn’t make sense to test on port 53 if you are failing to test 5335. Because nothing else AGH will do. To ask Unbound running on 5335.

You performed the test of Unbound on the system hosting Unbound? Just to be sure :wink:

Can you do a reboot and check unbound logs afterwards

journalctl -u unbound

Did you have done any configuration changes to Unbound? e.g. activating some other features like DoT?

What is the output of
unbound -d -vvvv

No, I set up everything new without any customizations.
After the reboot:

root@DietPi:~# journalctl -u unbound
-- Journal begins at Sun 2022-04-10 14:12:51 CEST, ends at Sun 2022-04-10 14:13:05 CEST. --
Apr 10 14:12:52 DietPi systemd[1]: Starting Unbound DNS server...
Apr 10 14:12:52 DietPi unbound[379]: [379:0] info: start of service (unbound 1.13.1).
Apr 10 14:12:52 DietPi systemd[1]: Started Unbound DNS server.
unbound -d -vvvv
[1649593027] unbound[968:0] notice: Start of unbound 1.13.1.
[1649593027] unbound[968:0] debug: increased limit(open files) from 1024 to 4140
[1649593027] unbound[968:0] debug: creating udp4 socket 127.0.0.1 5335
[1649593027] unbound[968:0] debug: creating tcp4 socket 127.0.0.1 5335
[1649593027] unbound[968:0] debug: creating tcp6 socket ::1 8953
[1649593027] unbound[968:0] error: can't bind socket: Address already in use for ::1 port 8953 (len 28)
[1649593027] unbound[968:0] error: cannot open control interface ::1 8953
[1649593027] unbound[968:0] fatal error: could not open ports

What is the output of
unbound -d -vvvv

You can’t start another instance of unbound as the service already running. You would need to stop unbound service first before running from CLI. Therefore you get address already in use.

let’s try to debug it further and install tcpdump

apt install tcpdump

once done, you can do some tracing on DNS server ports

tcpdump -i any -c500 -nn port 53 or port 5335 or port 853

This will capture 500 lines before it stop automatically. Or once cancelled by user.

Open a 2nd SSH session to perform the test using dig

dig @127.0.0.1 -p 5335 dietpi.com

OK:

root@DietPi:~# tcpdump -i any -c500 -nn port 53 or port 5335 or port 853
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
14:30:43.028826 lo    In  IP 127.0.0.1.55850 > 127.0.0.1.5335: UDP, length 51
14:30:43.029089 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.22255 > 2001:500:12::d0d.53: 8721% [1au] NS? . (28)
14:30:43.407480 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.58675 > 2001:500:12::d0d.53: 28337% [1au] NS? . (28)
14:30:43.790983 eth0  Out IP 192.168.178.55.4509 > 199.9.14.201.53: 51284% [1au] NS? . (28)
14:30:44.169610 eth0  Out IP 192.168.178.55.7947 > 199.9.14.201.53: 36476% [1au] NS? . (28)
14:30:44.547164 eth0  Out IP 192.168.178.55.48649 > 192.5.5.241.53: 15675% [1au] NS? . (28)
14:30:44.931124 eth0  Out IP 192.168.178.55.61089 > 192.5.5.241.53: 58234% [1au] NS? . (28)
14:30:45.309333 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.64588 > 2001:500:12::d0d.53: 36483% [1au] NS? . (28)
14:30:46.067336 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.29319 > 2001:500:12::d0d.53: 21588% [1au] NS? . (28)
14:30:46.827804 eth0  Out IP 192.168.178.55.8756 > 192.58.128.30.53: 1464% [1au] NS? . (28)
14:30:47.211363 eth0  Out IP 192.168.178.55.23644 > 192.58.128.30.53: 49626% [1au] NS? . (28)
14:30:47.589303 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.25731 > 2001:500:200::b.53: 37977% [1au] NS? . (28)
14:30:47.966744 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.12021 > 2001:500:200::b.53: 53697% [1au] NS? . (28)
14:30:48.037188 lo    In  IP 127.0.0.1.55850 > 127.0.0.1.5335: UDP, length 51
14:30:48.350123 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.31408 > 2001:500:2::c.53: 48841% [1au] NS? . (28)
14:30:48.727904 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.7122 > 2001:500:2::c.53: 17713% [1au] NS? . (28)
14:30:49.111418 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.34753 > 2001:503:c27::2:30.53: 42937% [1au] NS? . (28)
14:30:49.489206 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.58406 > 2001:503:c27::2:30.53: 42201% [1au] NS? . (28)
14:30:49.866787 eth0  Out IP 192.168.178.55.8505 > 199.9.14.201.53: 36125% [1au] NS? . (28)
14:30:50.629021 eth0  Out IP 192.168.178.55.36853 > 199.9.14.201.53: 58006% [1au] NS? . (28)
14:30:51.387272 eth0  Out IP 192.168.178.55.52746 > 192.33.4.12.53: 37214% [1au] NS? . (28)
14:30:51.771223 eth0  Out IP 192.168.178.55.60551 > 192.33.4.12.53: 43506% [1au] NS? . (28)
14:30:52.149030 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.41183 > 2001:7fe::53.53: 20611% [1au] NS? . (28)
14:30:52.526593 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.8381 > 2001:7fe::53.53: 14425% [1au] NS? . (28)
14:30:52.910749 eth0  Out IP 192.168.178.55.10855 > 198.41.0.4.53: 28103% [1au] NS? . (28)
14:30:53.047039 lo    In  IP 127.0.0.1.55850 > 127.0.0.1.5335: UDP, length 51
14:30:53.289788 eth0  Out IP 192.168.178.55.29787 > 198.41.0.4.53: 28391% [1au] NS? . (28)
14:30:53.667456 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.65327 > 2001:500:2d::d.53: 12324% [1au] NS? . (28)
14:30:54.051533 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.23557 > 2001:500:2d::d.53: 5624% [1au] NS? . (28)
14:30:54.429234 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.45297 > 2001:500:200::b.53: 25966% [1au] NS? . (28)
14:30:55.187323 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.51954 > 2001:500:200::b.53: 65151% [1au] NS? . (28)
14:30:55.947577 eth0  Out IP 192.168.178.55.51688 > 192.112.36.4.53: 34933% [1au] NS? . (28)
14:30:56.331559 eth0  Out IP 192.168.178.55.54690 > 192.112.36.4.53: 36441% [1au] NS? . (28)
14:30:56.709164 eth0  Out IP 192.168.178.55.35691 > 192.58.128.30.53: 37984% [1au] NS? . (28)
14:30:57.467363 eth0  Out IP 192.168.178.55.40337 > 192.58.128.30.53: 34337% [1au] NS? . (28)
14:30:58.228051 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.64073 > 2001:503:ba3e::2:30.53: 12276% [1au] NS? . (28)
14:30:58.611671 eth0  Out IP6 xxxx:xxxx:d473:9b00:dea6:32ff:fe66:8f2b.4487 > 2001:503:ba3e::2:30.53: 17303% [1au] NS? . (28)
14:30:58.989378 eth0  Out IP 192.168.178.55.26195 > 198.41.0.4.53: 62564% [1au] NS? . (28)
14:30:59.747519 eth0  Out IP 192.168.178.55.27506 > 198.41.0.4.53: 61948% [1au] NS? . (28)
14:31:00.508332 lo    In  IP 127.0.0.1.5335 > 127.0.0.1.55850: UDP, length 39
14:31:00.508454 lo    In  IP 127.0.0.1.5335 > 127.0.0.1.55850: UDP, length 39
14:31:00.508554 lo    In  IP 127.0.0.1.5335 > 127.0.0.1.55850: UDP, length 39

Hmm Unbound is sending the request to upstream root DNS server. But never get an answer / e.g. is timing out

14:30:43.790983 eth0  Out IP 192.168.178.55.4509 > 199.9.14.201.53: 51284% [1au] NS? . (28)
14:30:44.169610 eth0  Out IP 192.168.178.55.7947 > 199.9.14.201.53: 36476% [1au] NS? . (28)
14:30:44.547164 eth0  Out IP 192.168.178.55.48649 > 192.5.5.241.53: 15675% [1au] NS? . (28)

Do you have any network component that could block DNS traffic?

How does it looks like if you ask the root DNS server directly

dig @199.9.14.201 -p 53 dietpi.com

I have not changed now, but now the DNS query works.
Strange :roll_eyes:
Thank you :slight_smile:

indeed strange. Who knows what was blocking the DNS request.