How-To Verify PiHole Unbound Status?

Please follow the below template, it will help us to help you!

*If you are Experiencing issues with a Pi-hole install that has non-standard elements

Device is operational.
Reaching out for guidance and best methods to attempt to verify and confirm status if unbound on Pihole v6 is operational

Expected Behaviour:

UNBOUND STATUS on Pihole Version 6

$ sudo systemctl status unbound
● unbound.service - Unbound DNS server
     Loaded: loaded (/lib/systemd/system/unbound.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-02-22 20:11:31 EST; 42min ago
       Docs: man:unbound(8)
    Process: 2651 ExecStartPre=/usr/libexec/unbound-helper chroot_setup (code=exited, status=0/SUCCESS)
    Process: 2653 ExecStartPre=/usr/libexec/unbound-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
   Main PID: 2655 (unbound)
      Tasks: 1 (limit: 767)
        CPU: 357ms
     CGroup: /system.slice/unbound.service
             └─2655 /usr/sbin/unbound -d -p

Feb 22 20:11:31 pihole1 systemd[1]: Starting unbound.service - Unbound DNS server...
Feb 22 20:11:31 pihole1 unbound[2655]: [2655:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.
Feb 22 20:11:31 pihole1 unbound[2655]: [2655:0] info: start of service (unbound 1.17.1).
Feb 22 20:11:31 pihole1 systemd[1]: Started unbound.service - Unbound DNS server.

UNBOUND VERSION

 unbound -v
[1740275503] unbound[2919:0] notice: Start of unbound 1.17.1.
[1740275503] unbound[2919:0] error: can't bind socket: Address already in use for 127.0.0.1 port 5335
[1740275503] unbound[2919:0] fatal error: could not open ports

UNBOUND TESTS

TEST01

dig www.cnn.com @127.0.0.1 -p 5335

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> www.cnn.com @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61431
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.cnn.com.            300     IN      CNAME   cnn-tls.map.fastly.net.
cnn-tls.map.fastly.net. 60      IN      A       151.101.127.5

;; Query time: 131 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sat Feb 22 20:47:59 EST 2025
;; MSG SIZE  rcvd: 92

TEST 02

dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58893
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigok.verteiltesysteme.net.    IN      A

;; ANSWER SECTION:
sigok.verteiltesysteme.net. 1799 IN     CNAME   sigok.rsa2048-sha256.ippacket.stream.
sigok.rsa2048-sha256.ippacket.stream. 60 IN A   195.201.14.36

;; Query time: 539 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sat Feb 22 20:51:09 EST 2025
;; MSG SIZE  rcvd: 121

TEST 03

dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; Query time: 2659 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sat Feb 22 20:47:30 EST 2025
;; MSG SIZE  rcvd: 57

Actual Behaviour:

I am attempting to make sense or learn the best method to verify and confirm unbound is deployed and operational on Pihole v6

As unbound was previously operational on my Pihole v5 environment, due to the requirement to update to the current OS recommendation, it was required to rebuild out some feature sets.

I attempted to locate some direct information to wrap my head around testing, and wanted to post, seeking some some recommendations from the community to assist with this unbound deployment, so I can be assured everything is working as required.

I look forward to hearing back from the many experts in this community with some tips and guidance.

Thank you kindly.

The outputs you presented show unbound is working. Take a look in the dnsmasq log at /var/log/pihole/pihole.log and see if unbound is answering queries sent to it from Pi-hole. If it is answering, then unbound is working.

Example from my log (unbound is working normally):

Feb 22 19:52:21 dnsmasq[15571]: query[A] privacy-gateway.cloudflare.com from 192.168.0.135
Feb 22 19:52:21 dnsmasq[15571]: forwarded privacy-gateway.cloudflare.com to 127.0.0.1#5335
Feb 22 19:52:21 dnsmasq[15571]: reply privacy-gateway.cloudflare.com is 104.18.12.110
Feb 22 19:52:21 dnsmasq[15571]: reply privacy-gateway.cloudflare.com is 104.18.13.110

Hello,
Looking at the log at that location, all replies to any of the IP addresses queried do not indicate port 5335.
I would assume unbound may not be operational if that's the case?

That is normal. The entire reply string comes from unbound, and the CNAMES are just further lookups by unbound to get the endpoint IP.

Example - this dig command

dig appleid.apple.com @127.0.0.1

; <<>> DiG 9.16.50-Raspbian <<>> appleid.apple.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34976
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
appleid.apple.com.	30	IN	CNAME	appleid.idms-apple.com.akadns.net.
appleid.idms-apple.com.akadns.net. 30 IN A	17.23.96.16

results in these dnsmasq log entries

Feb 22 08:40:39 dnsmasq[15571]: query[A] appleid.apple.com from 192.168.0.135
Feb 22 08:40:39 dnsmasq[15571]: forwarded appleid.apple.com to 127.0.0.1#5335
Feb 22 08:40:39 dnsmasq[15571]: reply appleid.apple.com is <CNAME>
Feb 22 08:40:39 dnsmasq[15571]: reply appleid.idms-apple.com.akadns.net is 17.23.96.16

Hello,

Attempted the same dig command you posted with the following result

dig appleid.apple.com @127.0.0.1
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out

hm...

However if I force the command over -p 5335 the following occurs

dig appleid.apple.com @127.0.0.1 -p 5335

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> appleid.apple.com @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49141
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
appleid.apple.com.      300     IN      CNAME   appleid.idms-apple.com.akadns.net.
appleid.idms-apple.com.akadns.net. 300 IN A     17.32.194.6
appleid.idms-apple.com.akadns.net. 300 IN A     17.32.194.37

;; Query time: 355 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sat Feb 22 22:04:54 EST 2025
;; MSG SIZE  rcvd: 125

Suppose I am not understanding with and withou the port in the query, why one times out, and one does not?

I've done a number of upgrades from V5 to V6 with Unbound installed. In all cases Unbound was not touched. If you did an upgrade from V5 to V6 then Unbound will be working as before. If you did a fresh install of V6 then you can install Unbound and use it in the same way as you would before, by following the guide. The UI graphic is slightly out of date now but not a problem.

Hello,

Yes performed a fresh install as recommended coming from Buster and installed Bullseye today

Imported teleporter, and went through the unbound guide to re-deploy it, which lead me to seek guidance on if I was perhaps overlooking something in the deployment of unbound that it may not be 100% functional.

doesn't look like there is a dnsmasq.log in my deployment at /var/log/pihole/
I would assume DSNMASQ is not enabled perhaps?

Why Bullseye and not the latest Bookworm, which will be supported for years longer?

The filename is pihole.log. The logs shown with number suffixes are previous days logs - the log rotates nightly at midnight.

ls -lha /var/log/pihole/
total 13M
drwxr-xr-x  2 pihole pihole 4.0K Feb 22 00:00 .
drwxr-xr-x 16 root   root   4.0K Feb 20 00:00 ..
-rw-r-----  1 pihole pihole  44K Feb 22 19:56 FTL.log
-rw-r-----  1 pihole pihole  58K Feb 22 00:00 FTL.log.1
-rw-r-----  1 pihole pihole 7.5K Feb 21 00:00 FTL.log.2.gz
-rw-r-----  1 pihole pihole 3.5K Feb 20 00:00 FTL.log.3.gz
-rw-r-----  1 pihole pihole  49K Feb 20 09:20 pihole_debug.log
-rw-r-----  1 pihole pihole  24K Feb  4  2019 pihole_debug-sanitized.log
-rw-r-----  1 pihole pihole 244K Jul  3  2022 pihole-FTL.log
-rw-r-----  1 pihole pihole 4.3K Jun  2  2022 pihole-FTL.log.1
-rw-r-----  1 pihole pihole  832 Jun  1  2022 pihole-FTL.log.2.gz
-rw-r-----  1 pihole pihole 2.6K May 31  2022 pihole-FTL.log.3.gz
-rw-r-----  1 pihole pihole 3.0M Feb 22 21:15 pihole.log
-rw-r-----  1 pihole pihole 7.6M Feb 22 00:00 pihole.log.1
-rw-r-----  1 pihole pihole 522K Feb 21 00:00 pihole.log.2.gz
-rw-r-----  1 pihole pihole 397K Feb 20 00:00 pihole.log.3.gz
-rw-r-----  1 pihole pihole 308K Feb 19 00:00 pihole.log.4.gz
-rw-r-----  1 pihole pihole 637K Feb 18 00:00 pihole.log.5.gz
-rw-r-----  1 pihole pihole 2.1K Feb 16 04:29 pihole_updateGravity.log
-rw-r-----  1 pihole pihole  166 Feb 22 09:01 webserver.log
-rw-r-----  1 pihole pihole  434 Feb 22 00:00 webserver.log.1
-rw-r-----  1 pihole pihole  244 Feb 21 00:00 webserver.log.2.gz
-rw-r-----  1 pihole pihole  146 Feb 20 00:00 webserver.log.3.gz

To view the current day's log:

sudo cat /var/log/pihole/pihole.log

The first query asks Pi-hole on port 53 to resolve the domain, which in turn asks its upstream server. The second query asks Unbound on port 5335 to resolve the domain, which it does.

Your first response implies that Pi-hole did not ask its upstream. If you upgraded from V5 you may have hit the problem, now fixed, where the upstream servers were not carried across.

Try setting Unbound as the upstream and running the first command again

sudo pihole-FTL --config dns.upstreams '["127.0.0.1#5335"]'

hm interesting in the GUI logs when I search for that same query this was the result.

also saw this which I band-aided in my last deployment. Learning from the original post that it was not a valid fix, but it worked ... never did find the actual fix for it

DNSMASQ_WARN Warning in dnsmasq core:
Maximum number of concurrent DNS queries reached (max: 150)

Ran the command as you stated:

$ sudo pihole-FTL --config dns.upstreams '["127.0.0.1#5335"]'
[ 127.0.0.1#5335 ]

Result

dig appleid.apple.com @127.0.0.1

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> appleid.apple.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3201
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
appleid.apple.com.      300     IN      CNAME   appleid.idms-apple.com.akadns.net.
appleid.idms-apple.com.akadns.net. 300 IN A     17.32.194.6
appleid.idms-apple.com.akadns.net. 300 IN A     17.32.194.37

;; Query time: 99 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Feb 22 22:18:07 EST 2025
;; MSG SIZE  rcvd: 125

You were forwarding to port 5053. That is the port normally used with a Cloudflared installation. Our unbound guide uses port 5335 for unbound.

I added a new query to attempt since appleid. is cached

dig nhl.com @127.0.0.1

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

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

;; ANSWER SECTION:
nhl.com.                300     IN      A       104.18.16.236
nhl.com.                300     IN      A       104.18.17.236

;; Query time: 55 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Feb 22 22:24:17 EST 2025
;; MSG SIZE  rcvd: 68

Does that mean the previous command you suggested

sudo pihole-FTL --config dns.upstreams '["127.0.0.1#5335"]'

So I am understanding correctly; fixed my instance to use 5335 now moving forward?

It seems in the GUI log any new query is successful, but is hitting port 53

Query Status: **Forwarded, reply from 1.1.1.1#53**

Your Pi-hole system has two DNS servers running on it.

  • Pi-hole on port 53, the standard DNS port
  • Unbound on port 5335

127.0.0.1 means "this computer". dig is a tool for probing DNS servers.

If you dig @127.0.0.1 (dig uses @ip_address to specify the server) you'll hit Pi-hole on the standard port 53 and Pi-hole will then either return 0.0.0.0 if it's a blocked domain, or else it will forward the query to its configured upstream server(s). Pi-hole has Unbound configured as its upstream server (the syntax for this in Pi-hole is 127.0.0.1#5335) and so Unbound then goes and works out the answer and reports it back to Pi-hole, which in turn answers your dig query.

client --> Pi-hole (port 53) --> Unbound (port 5335)

If you dig @127.0.0.1 and specify port 5335 (dig does this with -p port_number), you ask Unbound directly, bypassing Pi-hole's blocking.

client     Pi-hole (port 53) --> Unbound (port 5335)
    \_______________________________^

You previously had port 5053 configured, which as jtb says is usually associated with a different service, or might just have been a typo during install. Either way, Pi-hole had nothing there to talk to and hence it timed out, but going to Unbound directly still worked as expected.

The earlier command indeed is a command line way of configuring Pi-hole to use Unbound for its upstream server. You can also do this in Pi-hole's admin interface.

With this configured your query hits port 53, and the log in Pi-hole will show it being forwarded to port 5335.

1 Like

Appreciate that.
I see there is something hitting and rate limiting currently:

has been rate-limited for at least 25 seconds (current limit: 1000 queries per 60 seconds)

also noticed the system I am on, performing queries from is not hitting the pihole logs.... this is strange.

Going to give it a reboot to see if it assist with these changes, not seeing the reboot/shutdown in the v6 GUI so will have to from CLI

By all means create a debug log if you want, that rate limit message will be in there. Do that with sudo pihole -d and say y to upload when prompted and paste the green token URL it gives you into here. May answer your logs question too.

For your system that may be bypassing, try opening a terminal on it and type

nslookup flurry.com

and

nslookup flurry.com x.x.x.x

where x.x.x.x is the IP address of your Pi-hole. What do these two commands give back?

debug token is: https://tricorder.pi-hole.net/maQIaSYj/

nslookup flurry.com
Server:         10.200.0.6
Address:        10.200.0.6#53

Name:   flurry.com
Address: 0.0.0.0
Name:   flurry.com
Address: ::
nslookup flurry.com 10.200.0.6
Server:         10.200.0.6
Address:        10.200.0.6#53

Name:   flurry.com
Address: 0.0.0.0
Name:   flurry.com
Address: ::

Your debug log looks normal. There are not diagnosis messages contained in the log either.

Thanks. The nslookup tests show that the system you're on is correctly using Pi-hole for its DNS, and that Pi-hole is correctly returning 0.0.0.0 for that domain, since it's a known blocked domain.

If you're seeing Pi-hole bypassed when using your browser, check that your browser isn't using DNS-over-HTTPS or something like that, usually billed as a privacy feature. For example Firefox's info on their setting is here.

You should be able to see your computer's queries, and those from other computers and devices on your network, appearing in Pi-hole's Query Log.

The debug log all looks good. The diagnostic message about rate limits isn't in there unfortunately so I assume you cleared it beforehand. It should say which device is hitting the limit, and then you have to find out why that device is hammering the DNS [edit I see you found it]. You can look at its queries in the Query Log as a good way to get an idea of what it's doing. If it's trying to reach a blocked domain, it may be beneficial to whitelist that domain and let it reach it to see if that quietens it down.

Edit - actually there is one thing, your Pi OS is configured to use itself for DNS, ie it will be using Pi-hole.

-rw-r--r-- 1 root root 71 Feb 22 23:09 /etc/resolv.conf
   search localdomain
   nameserver 10.200.0.6

This will work, but it also means that if Pi-hole blocks something the OS needs during an update, or if Pi-hole needs something and that something is blocked, you might run into a catch-22 where you sort of lock yourself out. It's better practice to configure an external, trusted DNS provider for the OS itself. For example you might choose Quad9 or your ISP's DNS if you trust those.

You can edit them using sudo nmcli and navigating to the connnection, where you can Show and edit the IPv4 settings and the DNS servers for the OS to the external ones of your choosing. Pi-hole and Unbound are unaffected by this, it's just for the OS itself to use.