Unbound Not Working

Help
1

Hello everyone.

I'm trying to run Unbound on my Pi-Hole but I think it can't seem to reach the internet when I specify 127.0.0.1 p5335 with the dig command. I receive the SERVFAIL status when the guide says I should be receiving a NOERROR status. The dig command works when I don't specify the IP. Does anyone have any idea as to what my problem is? Any and all help will be appreciated.

I'm using a Raspberry Pi 5 with Pi Os 12 (Bookworm).

I've seen the command sudo grep -v '#|^$' -R /etc/unbound/unbound.conf* a lot so below is the output from this command if it'll help determine anything.

/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:    verbosity: 0
/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: yes
/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
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 192.0.2.0/24
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 198.51.100.0/24
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 203.0.113.0/24
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 255.255.255.255/32
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 2001:db8::/32
/etc/unbound/unbound.conf.d/remote-control.conf:remote-control:
/etc/unbound/unbound.conf.d/remote-control.conf:  control-enable: yes
/etc/unbound/unbound.conf.d/remote-control.conf:  control-interface: /run/unbound.ctl
/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"
2

It looks like Unbound may not be able to access the root DNS servers. A few things to check:

  1. Network access: Ensure your Pi has internet access and no firewall is blocking Unbound.

  2. DNSSEC validation: Try disabling it temporarily (unbound-checkconf to test changes) to see if it’s causing the SERVFAIL.

  3. Root trust anchor: Make sure /var/lib/unbound/root.key exists and is valid. You can refresh it with:

    sudo unbound-anchor -a /var/lib/unbound/root.key

Also, try:

dig @127.0.0.1 -p 5335 google.com

to test directly. Let me know if it still fails!

3

Yeah something has changed at dnssec.works:

$ dig fail01.dnssec.works @127.0.0.1 -p 5335
[..]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56843
[..]
;; ANSWER SECTION:
fail01.dnssec.works.    3600    IN      A       5.45.109.212

This happened before with a domain that was used in the Pi-hole guide.
Maybe they fix it, or the guide needs another domain to test DNSSEC.

Does below link say IPv6 is supported upstream by your ISP?

If not, above setting should be changed to no.

4
  1. It does. Using it via ethernet and ensured it's not being blocked.
  2. I believe I did that but I'm not sure if I used the correct command. I tried googling the command and tried what I found but it wouldn't connect at all when I implemented it.
  3. It does exist. The command you gave didn't work though; doesn't recognize unbound-anchor as a command.
  4. Using the dig command with any IP/url fails when I specify the unbound IP and port.
    Thank you for taking the time to help. Do you have any more suggestions?
5

I just pasted the script from pi-hole's guide. I did turn off IPV6 to your suggestion and still nothing. I'm not able to use the dig command for any site if I specify using unbound's IP and port so I don't think in this instance the problem is dnssec.works.

6

I think you'll need to inspect the Unbound logs to try and figure out whats wrong.
For below instructions, I'm assuming you dont have Unbound configured as upstream for Pi-hole yet!

Up above verbosity to three first to have individual client queries logged in the systemd journals.
One-liner:

sudo sed -i 's/verbosity: 0/verbosity: 3/' /etc/unbound/unbound.conf.d/pi-hole.conf

Follow/tail the systemd journal live for the Unbound unit with below:

sudo journalctl --full --no-hostname --follow --lines 0 --unit unbound.service

Open another shell/SSH session and post the appearing log entries here after you've restarted Unbound with below:

sudo systemctl restart unbound.service

And separately, post also the log entries when performing below query for an "any site":

dig +short @127.0.0.1 -p 5335 pi-hole.net

When done diagnosing, run below two to restore verbosity to zero again:

sudo sed -i 's/verbosity: 3/verbosity: 0/' /etc/unbound/unbound.conf.d/pi-hole.conf

sudo systemctl reload unbound.service

FYI:

$ man unbound.conf
[..]
       verbosity: <number>
              The verbosity number, level 0 means no verbosity,  only  er‐
              rors.  Level 1 gives operational information.  Level 2 gives
              detailed operational information including short information
              per  query.   Level  3 gives query level information, output
              per query.   Level  4  gives  algorithm  level  information.
              Level  5  logs  client identification for cache misses.  De‐
              fault is level 1.  The verbosity can also be increased  from
              the commandline, see unbound(8).