Unable to make unbound work

I recently installed Pi-hole on a Raspberry PI 3 Model B.

Everything is working as expected and I decided to start using unbound. I followed the instructions from the official guides.

Unfortunately, I haven't been able to make unbound work as expected and every time I use the dig command I get a status: SERVFAIL

I have been reading a bunch of threads within the discourse to make sure I'm able to fix it on my own, but I haven't being able to do so :sob:

Here are some of the post I have read:

Here are some of the typical output requested to helping debugging unbound issues run on my machine:

unbound-checkconf

unbound-checkconf: no errors in /etc/unbound/unbound.conf

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*

/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:    auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:logfile: "/var/log/unbound/unbound.log"
/etc/unbound/unbound.conf.d/pi-hole.conf:log-time-ascii: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:verbosity: 5
/etc/unbound/unbound.conf.d/pi-hole.conf:interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf:port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf:do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf:edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf:prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf:so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: fe80::/10

cat /etc/resolv.conf

# Generated by resolvconf
nameserver 127.0.0.1

I manually updated /etc/resolv.conf to not use my home router IP

I found something a bit strange when running dig and checking the unbound logs. When running dig crosstalksolutions.com @127.0.0.1 -p 5335 I get:

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

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

;; Query time: 55 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Tue Dec 26 19:34:08 CET 2023
;; MSG SIZE  rcvd: 51

But from the inbounds logs, I can see that there are valid answers:

Dec 26 19:34:08 unbound[16607:0] info: incoming scrubbed packet: ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
crosstalksolutions.com.	IN	A

;; ANSWER SECTION:
crosstalksolutions.com.	12	IN	A	34.120.190.48

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE  rcvd: 56

Dec 26 19:34:08 unbound[16607:0] debug: iter_handle processing q with state QUERY RESPONSE STATE

To avoid having too much noise, I will attach the full log output to as part of this post :smile:
unbound logs.txt (44.4 KB)

Running dig without using unbound

dig crosstalksolutions.com

; <<>> DiG 9.16.44-Debian <<>> crosstalksolutions.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39629
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
crosstalksolutions.com.	19	IN	A	35.190.31.54

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Dec 26 19:51:48 CET 2023
;; MSG SIZE  rcvd: 67

Lastly, running nslookup in the host machine

nslookup crosstalksolutions.com

Server:		192.168.0.31
Address:	192.168.0.31#53

Non-authoritative answer:
Name:	crosstalksolutions.com
Address: 35.190.31.54

I'm not sure what else to do. Any help with this issue would be gladly appreciated.

Thanks

what does your /etc/hosts file looks like?

Check the date and time on the Pi and ensure it is correct for your location. Inaccurate time foils the DNSSEC algorithm:

date

cat /etc/hosts

127.0.0.1	localhost
::1		localhost ip6-localhost ip6-loopback
ff02::1		ip6-allnodes
ff02::2		ip6-allrouters

date

Tue Dec 26 20:45:58 CET 2023

This client is using unbound indirectly - assuming you still have unbound configured as the upstream DNS server for Pi-hole.

What is the output of the following command from the Pi terminal:

delv crosstalksolutions.com @127.0.0.1 -p5335 +yaml

I haven't configuredpi-hole yet to use unbound yet. The guide first suggest to run a successful dig command before setting the DNS server as 127.0.0.1#5335

delv crosstalksolutions.com @127.0.0.1 -p5335 +yaml
type: DELV_RESULT
query_name: crosstalksolutions.com
status: SERVFAIL
records:

To validate that unbound is running here is the output from sudo service unbound status

● unbound.service - Unbound DNS server
     Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-12-26 19:31:12 CET; 1h 39min ago
       Docs: man:unbound(8)
    Process: 16601 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
    Process: 16604 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/S>
   Main PID: 16607 (unbound)
      Tasks: 1 (limit: 779)
        CPU: 2.436s
     CGroup: /system.slice/unbound.service
             └─16607 /usr/sbin/unbound -d -p

Dec 26 19:31:11 pihole systemd[1]: Starting Unbound DNS server...
Dec 26 19:31:12 pihole unbound[16607]: Dec 26 19:31:12 unbound[16607:0] debug: increased limit(open files) from 1>
Dec 26 19:31:12 pihole unbound[16607]: Dec 26 19:31:12 unbound[16607:0] debug: creating udp4 socket 127.0.0.1 5335
Dec 26 19:31:12 pihole unbound[16607]: Dec 26 19:31:12 unbound[16607:0] debug: creating tcp4 socket 127.0.0.1 5335
Dec 26 19:31:12 pihole unbound[16607]: Dec 26 19:31:12 unbound[16607:0] debug: creating tcp4 socket 127.0.0.1 8953
Dec 26 19:31:12 pihole unbound[16607]: Dec 26 19:31:12 unbound[16607:0] debug: setup SSL certificates
Dec 26 19:31:12 pihole unbound[16607]: Dec 26 19:31:12 unbound[16607:0] debug: chdir to /etc/unbound
Dec 26 19:31:12 pihole unbound[16607]: Dec 26 19:31:12 unbound[16607:0] debug: drop user privileges, run as unbou>
Dec 26 19:31:12 pihole unbound[16607]: Dec 26 19:31:12 unbound[16607:0] debug: switching log to /var/log/unbound/>
Dec 26 19:31:12 pihole systemd[1]: Started Unbound DNS server.

I run delv crosstalksolutions.com @127.0.0.1 +yaml which technically uses port 53 and I got this:

;; no valid RRSIG resolving 'com/DS/IN': 127.0.0.1#53
;; broken trust chain resolving 'crosstalksolutions.com/A/IN': 127.0.0.1#53
type: DELV_RESULT
query_name: crosstalksolutions.com
status: broken trust chain
records:

broken trust chain doesn't sounds good

Here's a good test site with an independent instance of unbound running. You can compare your log results to theirs and see where they differ:

https://unboundtest.com/m/A/crosstalksolutions.com/GZPL6WGL

Is there a difference between CAA records and A records? The link you provided is looking for CAA records, and when I run dig on my Raspberry PI, it looks for A records.

Check for A records on the link. That's what I did, but apparently that selection isn't captured in the URL.

I'm not sure I fully understand. Sorry about it, I'm lacking some knowledge around DSN and linux tools around DNS

@jfb I'm using the 1.13 version of unbound. Do you think that could be an issue?

No.

I believe I found the culprit. I disable DNSSEC from unbound and things started working with unbound

dig crosstalksolutions.com @127.0.0.1 -p5335

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

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

;; ANSWER SECTION:
crosstalksolutions.com.	7	IN	A	34.149.36.179

;; Query time: 3 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Wed Dec 27 18:34:34 CET 2023
;; MSG SIZE  rcvd: 67

Another curious thing I found is that enabling DNSSEC in the pi-hole makes DNS resolution fail. (Note that I'm still not using unbound as my Upstream DNS server)

So, it must be something with DNSSEC in general.

Have other users of Pi-hole experience the same issue with DNSSEC?

You may have found the culprit, but you haven't fixed the problem. You have changed the parameters so the problem no longer interferes with the replies.

DNSSEC is not something you want to disable just because it isn't working.

In this case, it appears the domain is unsigned, and should show as INSECURE, a valid DNSSEC reply.

https://dnsviz.net/d/crosstalksolutions.com/dnssec/

delv crosstalksolutions.com @127.0.0.1 -p5335 +yaml  
type: DELV_RESULT
query_name: crosstalksolutions.com
status: success
records:
  - unsigned_answer:
    - crosstalksolutions.com. 300 IN A 34.149.120.3

@jfb I was able to enable DNSSEC and make unbound work.

It was nothing directly related to Pihole or unbound. I think it had something to do with the router I was using. I was using the router provided by my ISP (Vodafone Spain)

I was able to replace the ISP router with a Mikrotik. After the initial configuration, I went over the unbound instructions from the Pihole website and everything works as expected.

Unfortunately, I can not point 100% to the root cause of others so there is no command or thing I did that others from the community could benefit from.

Anyway, thank you so much for all the help.

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