Pi-hole works fine but unbound has a problem

svs · March 2, 2026, 10:05pm

The issue I am facing:

Pi-hole works perfectly. Unbound does not work.

Details about my system:

Ubuntu home server.

Avahi running as a service that enable printers, etc, eto be found, but uses Port 5353.

I have therefore changed the Pi-hole and unbound configs to use Part 5053, which is not used elsewhere.

What I have changed since installing Pi-hole:

Pihole hands off DNS queries perfectly to, say, 1.1.1.1 or 9.9.9.9 but does not work when those off-the-shelf resolver options are unchecked.

I have worked on this for several days, burned many megawatts of Google’s AI power.

All the standard tests, including the DNSSEC tests, work.

Here’s the question

Does Pi-hole really work when a non-standard port is used? The documentation says it should, but does it?

Thanks for reading.

robgill · March 2, 2026, 11:15pm

So long as you have set up unbound correctly and your ISP is not hijacking your DNS requests then Pi-hole works just fine with unbound.

I am aware that some guides for setting up unbound (now woefully out of date) previously suggested the use of port 5353 for unbound. The official guide has recommended 5335 for quite some time. If the port number being suggested is wrong, I wonder what else may be out of date in the guides you are consulting. If you are consulting LLMs expect the slop they produce to be patchy and often including out of date or flat out wrong information.

The official guide for installing unbound alongside pi-hole is found here:

svs · March 3, 2026, 11:20am

Thanks Rob. Appreciated. Here's what I'm going to do and I will report on whether it's successful (or not).

Disable Avahi. It's job is to advertise stuff like printers and audio streams, so I can do without it.
Change Pi-Hole and Unbound configs to Port 5335, as per documentation.
Check and diagnose.

I'll report back here for posterity and maybe the AI will pick it up as truth.

svs · March 3, 2026, 11:39am

And the answer is NO. Here is a diagnostic that DID work.

steve@balrog:/etc/unbound/unbound.conf.d$ dig @127.0.0.1 -p 5335 bbc.co.uk  +dnssec +multi

; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> @127.0.0.1 -p 5335 bbc.co.uk +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50454
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;bbc.co.uk.		IN A

;; ANSWER SECTION:
bbc.co.uk.		111 IN A 151.101.192.81
bbc.co.uk.		111 IN A 151.101.64.81
bbc.co.uk.		111 IN A 151.101.0.81
bbc.co.uk.		111 IN A 151.101.128.81

;; Query time: 91 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Tue Mar 03 11:33:05 GMT 2026
;; MSG SIZE  rcvd: 102

But my Brave browser will not find cnn.com.

The plot thickens.

And here is the diagnostic using CNN.com.

dig @127.0.0.1 -p 5335 cnn.com +dnssec +multi

; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> @127.0.0.1 -p 5335 cnn.com +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51923
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 59 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Tue Mar 03 11:37:28 GMT 2026
;; MSG SIZE rcvd: 36

svs · March 3, 2026, 11:42am

Sheesh! Now bbc.co.uk and cnn.com work and don't work, randomly.

Something is up. Is it to do with caches?

svs · March 3, 2026, 2:12pm

Half the website I visit connect via unbound, half do not. I need some inspiration now. Do connect: cnn, bbc. Don't connect: ebay, unifi.

nero355 · March 3, 2026, 3:22pm

Did you also apply the config file from unbound - Pi-hole documentation instead of the one you already had ?

What does the dig command output when you talk to Pi-Hole instead of Unbound ?

svs · March 3, 2026, 4:16pm

Yes, I checked the config file and it looks fine.

Here is the benchmark DIG which shows the rest of the routing is OK.

dig pi-hole.net @1.1.1.1

; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> pi-hole.net @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30763
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e00ab7833f632f56 (echoed)
;; QUESTION SECTION:
;pi-hole.net.			IN	A

;; ANSWER SECTION:
pi-hole.net.		300	IN	A	162.244.93.14

;; Query time: 16 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Mar 03 16:14:03 GMT 2026
;; MSG SIZE  rcvd: 79

Other tests follow.

svs · March 3, 2026, 4:19pm

Here is same test with 127.0.0.1 Port 5335. Fail.

dig pi-hole.net @127.0.0.1 -p 5335

; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> pi-hole.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37898
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pi-hole.net.			IN	A

;; Query time: 323 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Tue Mar 03 16:18:27 GMT 2026
;; MSG SIZE  rcvd: 40

svs · March 3, 2026, 4:21pm

And here going in via default port 53. Fail.

dig pi-hole.net @127.0.0.1

; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> pi-hole.net @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12595
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pi-hole.net.			IN	A

;; Query time: 295 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Mar 03 16:20:35 GMT 2026
;; MSG SIZE  rcvd: 40

robgill · March 3, 2026, 8:33pm

OK, so this could be the second scenario I described - potentially your ISP (or your router) is hijacking your DNS requests.

As a quick test please run the following:

dig NS . @198.41.0.4

If something (your ISP, your router) is hijacking your DNS requests then you will receive only a truncated output such as:

$ dig NS . @198.41.0.4

; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> NS . @198.41.0.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44599
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			54697	IN	NS	h.root-servers.net.
.			54697	IN	NS	l.root-servers.net.
.			54697	IN	NS	e.root-servers.net.
.			54697	IN	NS	f.root-servers.net.
.			54697	IN	NS	g.root-servers.net.
.			54697	IN	NS	a.root-servers.net.
.			54697	IN	NS	d.root-servers.net.
.			54697	IN	NS	j.root-servers.net.
.			54697	IN	NS	k.root-servers.net.
.			54697	IN	NS	i.root-servers.net.
.			54697	IN	NS	m.root-servers.net.
.			54697	IN	NS	c.root-servers.net.
.			54697	IN	NS	b.root-servers.net.

;; Query time: 4 msec
;; SERVER: 198.41.0.4#53(198.41.0.4) (UDP)
;; WHEN: Wed Mar 04 06:29:24 AEST 2026
;; MSG SIZE  rcvd: 444

But, if you are able to access the root nameserver, your output should be similar to this: With the "additional section" at the end and the entry WARNING: recursion requested but not available near the top.

$ dig NS . @198.41.0.4

; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> NS . @198.41.0.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15172
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; WARNING: recursion requested but not available

[..]

;; ADDITIONAL SECTION:
l.root-servers.net.	518400	IN	A	199.7.83.42
l.root-servers.net.	518400	IN	AAAA	2001:500:9f::42
j.root-servers.net.	518400	IN	A	192.58.128.30
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
f.root-servers.net.	518400	IN	A	192.5.5.241
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	A	198.97.190.53
h.root-servers.net.	518400	IN	AAAA	2001:500:1::53
d.root-servers.net.	518400	IN	A	199.7.91.13
d.root-servers.net.	518400	IN	AAAA	2001:500:2d::d
b.root-servers.net.	518400	IN	A	170.247.170.2
b.root-servers.net.	518400	IN	AAAA	2801:1b8:10::b
k.root-servers.net.	518400	IN	A	193.0.14.129
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
i.root-servers.net.	518400	IN	A	192.36.148.17
i.root-servers.net.	518400	IN	AAAA	2001:7fe::53
m.root-servers.net.	518400	IN	A	202.12.27.33
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35
e.root-servers.net.	518400	IN	A	192.203.230.10
e.root-servers.net.	518400	IN	AAAA	2001:500:a8::e
g.root-servers.net.	518400	IN	A	192.112.36.4
g.root-servers.net.	518400	IN	AAAA	2001:500:12::d0d
c.root-servers.net.	518400	IN	A	192.33.4.12
c.root-servers.net.	518400	IN	AAAA	2001:500:2::c
a.root-servers.net.	518400	IN	A	198.41.0.4
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
;; Query time: 167 msec
;; SERVER: 198.41.0.4#53(198.41.0.4) (UDP)
;; WHEN: Wed Mar 04 06:28:05 AEST 2026
;; MSG SIZE  rcvd: 811

In addition to these problems,

Unlikely to be caches, more likely there is a second DNS pathway specified somewhere on your network (potentially IPv6 via your router).

I recommend posting a debug token.

svs · March 3, 2026, 10:10pm

Thank you Rob. I get the former. Like this.

dig NS . @198.41.0.4

; <<>> DiG 9.18.39-0ubuntu0.22.04.2-Ubuntu <<>> NS . @198.41.0.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24290
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a8bb1f0d8457789c (echoed)
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			3600	IN	NS	a.root-servers.net.
.			3600	IN	NS	b.root-servers.net.
.			3600	IN	NS	c.root-servers.net.
.			3600	IN	NS	d.root-servers.net.
.			3600	IN	NS	e.root-servers.net.
.			3600	IN	NS	f.root-servers.net.
.			3600	IN	NS	g.root-servers.net.
.			3600	IN	NS	h.root-servers.net.
.			3600	IN	NS	i.root-servers.net.
.			3600	IN	NS	j.root-servers.net.
.			3600	IN	NS	k.root-servers.net.
.			3600	IN	NS	l.root-servers.net.
.			3600	IN	NS	m.root-servers.net.

;; Query time: 12 msec
;; SERVER: 198.41.0.4#53(198.41.0.4) (UDP)
;; WHEN: Tue Mar 03 22:06:28 GMT 2026
;; MSG SIZE  rcvd: 443

So I guess it's my ISP. I had no idea. It's late night now, so I'll work out what I can do in the morning. Thanks again.

svs · March 3, 2026, 10:12pm

I just read your reply again and saw your comment about my router. It's a Unifi Gateway, and I think I know what it's about, but I'll take another look.

svs · March 4, 2026, 10:25am

Thank you. My debug token is K7H2f6GB.

svs · March 4, 2026, 10:40am

Can't see anything untoward in the Unifi Gateway settings. And I do not have IP6 anywhere.
Odd behaviour that resolves about half the queries. It's not a TLD, as some .com and resolved and some are not.

deHakkelaar · March 4, 2026, 5:39pm

Inquire if your ISP applies CGNAT for its customers?
I believe CGNAT doesnt work well with recursive resolvers like Unbound:

Some users were able to opt out of this CGNAT after contacting their ISP:

EDIT: When run below one, do you see an IP starting with 100.x.x.x which confirms CGNAT being applied?

traceroute -n 8.8.8.8

From the wiki:

The allocated address block is 100.64.0.0/10, i.e. IP addresses from 100.64.0.0 to 100.127.255.255.

svs · March 4, 2026, 10:27pm

No, I see this. I'm pretty sure CGNAT is not the problem.

 traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.0.1  0.524 ms  0.489 ms  0.466 ms
 2  10.247.254.1  8.625 ms  6.651 ms  6.558 ms
 3  10.255.255.157  8.688 ms  7.889 ms  7.695 ms
 4  * * *
 5  * * *
 6  8.8.8.8  7.739 ms 172.253.66.98  9.071 ms 8.8.8.8  8.178 ms

deHakkelaar · March 6, 2026, 2:16am

Yes it appears so.
But your latest dig not returning below:

Also makes me suspect something upstream is interfering.
Below on my setup:

$ dig NS . @198.41.0.4

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> NS . @198.41.0.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61892
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       518400  IN      NS      l.root-servers.net.
.                       518400  IN      NS      j.root-servers.net.
.                       518400  IN      NS      f.root-servers.net.
.                       518400  IN      NS      h.root-servers.net.
.                       518400  IN      NS      d.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
.                       518400  IN      NS      k.root-servers.net.
.                       518400  IN      NS      i.root-servers.net.
.                       518400  IN      NS      m.root-servers.net.
.                       518400  IN      NS      e.root-servers.net.
.                       518400  IN      NS      g.root-servers.net.
.                       518400  IN      NS      c.root-servers.net.
.                       518400  IN      NS      a.root-servers.net.

;; ADDITIONAL SECTION:
l.root-servers.net.     518400  IN      A       199.7.83.42
l.root-servers.net.     518400  IN      AAAA    2001:500:9f::42
j.root-servers.net.     518400  IN      A       192.58.128.30
j.root-servers.net.     518400  IN      AAAA    2001:503:c27::2:30
f.root-servers.net.     518400  IN      A       192.5.5.241
f.root-servers.net.     518400  IN      AAAA    2001:500:2f::f
h.root-servers.net.     518400  IN      A       198.97.190.53
h.root-servers.net.     518400  IN      AAAA    2001:500:1::53
d.root-servers.net.     518400  IN      A       199.7.91.13
d.root-servers.net.     518400  IN      AAAA    2001:500:2d::d
b.root-servers.net.     518400  IN      A       170.247.170.2
b.root-servers.net.     518400  IN      AAAA    2801:1b8:10::b
k.root-servers.net.     518400  IN      A       193.0.14.129
k.root-servers.net.     518400  IN      AAAA    2001:7fd::1
i.root-servers.net.     518400  IN      A       192.36.148.17
i.root-servers.net.     518400  IN      AAAA    2001:7fe::53
m.root-servers.net.     518400  IN      A       202.12.27.33
m.root-servers.net.     518400  IN      AAAA    2001:dc3::35
e.root-servers.net.     518400  IN      A       192.203.230.10
e.root-servers.net.     518400  IN      AAAA    2001:500:a8::e
g.root-servers.net.     518400  IN      A       192.112.36.4
g.root-servers.net.     518400  IN      AAAA    2001:500:12::d0d
c.root-servers.net.     518400  IN      A       192.33.4.12
c.root-servers.net.     518400  IN      AAAA    2001:500:2::c
a.root-servers.net.     518400  IN      A       198.41.0.4
a.root-servers.net.     518400  IN      AAAA    2001:503:ba3e::2:30

;; Query time: 23 msec
;; SERVER: 198.41.0.4#53(198.41.0.4) (UDP)
;; WHEN: Fri Mar 06 02:50:15 CET 2026
;; MSG SIZE  rcvd: 811

Another test that you can run is querying above root servers for their version like below (via IPv4 only):

awk '/ A / {print "@"$4}' /usr/share/dns/root.hints | xargs -n1 dig +norecurse +short version.bind chaos txt

If you dont get below or similar answer, it also confirms something upstream is interfering and you should ask your ISP for assistance:

$ awk '/ A / {print "@"$4}' /usr/share/dns/root.hints | xargs -n1 dig +norecurse +short version.bind chaos txt
"ATLAS"
"knot 3.x"
"c-root"
"NSD 4"
"9.18.46"
"NSD 4.x"
"contact info@netnod.se"
"NSD"
"BIND"
"NSD 4"
"9.16"

You can run below similar one on a Windows, MacOS or other Linux host to rule out the Unbound host:

C:\>nslookup -class=chaos -type=txt version.bind 198.41.0.4
[..]
version.bind    text =

        "ATLAS"

robgill · March 6, 2026, 3:56am

Traceroute is often unrevealing as to what happening with dns. Often times an ISP will redirect port 53 DNS, without altering other traffic, so traceroute traffic goes right through to the specified destination unscathed.

svs · March 6, 2026, 1:51pm

Thanks to Rob and others who contributed. I'm going to leave it where it is.

For posterity, here is what I found:

Port 5335 is needed for Unbound. The documentation hints that any port is OK, but I think I showed otherwise.
I confused Port 5335 with Port 5353 which didn't help. Avahi running on Port 5353 was an innocent bystander.
Interference from ISP produces odd results, in which URLs are found and not found, randomly.
The contributors to this community are very helpful and knowledgeable.