What do below two output when run on the Pi?
nslookup -port=5335 pi-hole.net 127.0.0.1
nslookup pi-hole.net $(hostname -I)
And for below one when run on a Windows, MacOS or Linux client in a CMD/terminal window when the client(s) is/are set to use Pi-hole for DNS?
nslookup pi-hole.net
; Got SERVFAIL reply from 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#5335
** server can't find pi-hole.net: SERVFAIL
nslookup pi-hole.net $(hostname -I) -
Usage:
nslookup [-opt ...] # interactive mode using default server
nslookup [-opt ...] - server # interactive mode using 'server'
nslookup [-opt ...] host # just look up 'host' using default server
nslookup [-opt ...] host server # just look up 'host' using 'server'
If you try the second command @deHakkelaar indicated you do get a response. If you run the command with the typo ‘-‘ after the closing ) you get an error because the syntax error.
apologies that was me indicating that this is what it responded with
nslookup pi-hole.net $(hostname -I)
responded with:
Usage:
nslookup \[-opt ...\] # interactive mode using default server
nslookup \[-opt ...\] - server # interactive mode using 'server'
nslookup \[-opt ...\] host # just look up 'host' using default server
nslookup \[-opt ...\] host server # just look up 'host' using 'server'
No worries. I’d confirm the command entered, as I just tried again on both a Windows box, and a Linux box, using “nslookup pi-hole.net $(hostname -I)” and receive valid results.
If I enter “nslookup pi-hole.net $(hostname -I) -” (includes the trailing “-“), I receive the error indicated.
$(hostname -I) may return a set of IPv4 and IPv6 addresses, where nslookup would just expect one address, and thus would fail in the way you observe.
You should instead have run nslookup explicitly by your Pi-hole's IPv4, e.g.
nslookup pi-hole.net 192.168.2.51.
Your debug log shows your router is distributing two public DNS servers:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
Scanning all your interfaces for DHCP servers and IPv6 routers
* Received 300 bytes from 192.168.2.1 @ eth0
Offered IP address: 192.168.2.51
DHCP options:
Message type: DHCPOFFER (2)
dns-server: 1.1.1.1
dns-server: 1.0.0.1
router: 192.168.2.1
--- end of options ---
None of your network is using Pi-hole for DNS, unless you'd manually have pointed a device to do so.
If this is not how you intend to introduce Pi-hole to your network, you should configure your router's DHCP server to distribute Pi-hole (and Pi-hole only) as local DNS server.
Your debug log also shows excerpts of Pi-hole's logs where each query forwarded to unbound results in SERVFAIL.
This could happen if your Pi-hole machine's time would be off.
Please verify that your Pi-hole machine's time and time zone information are correct.
And if they are, please share the result of the following command (directly interrogating a root server) as run from your Pi-hole machine:
dig +short @192.33.4.12 chaos txt version.bind
the above command shows nothing?
however i tried the following if this gives you what you need?
:timedatectl
Local time: Thu 2025-08-28 17:29:10 BST
Universal time: Thu 2025-08-28 16:29:10 UTC
RTC time: n/a
Time zone: Europe/London (BST, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
which is the correct time
For note, I am not setting my DNS to this on my switch right now as it just kills my internet, I am doing it 1 by 1 until I can get this sorted.
That doesn't bode well.
Please rerun that with full output:
dig @192.33.4.12 chaos txt version.bind
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @192.33.4.12 chaos txt version.bind
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1385
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 133e3ee8c49b00f0 (echoed)
;; QUESTION SECTION:
;version.bind. CH TXT
;; Query time: 23 msec
;; SERVER: 192.33.4.12#53(192.33.4.12) (UDP)
;; WHEN: Thu Aug 28 18:25:49 BST 2025
;; MSG SIZE rcvd: 53
Something upstream of your unbound (either your router or your ISP) is interfering and refusing DNS requests to the root servers.
You should first verify that your router isn't intercepting and/or disallowing those DNS requests.
It may help to share your router's make and model, to improve chances that a user with a similar model may chime in and share their experiences.
Yeah I shouldnt use that construct anymore 
content filtering is completely off on my gateway 
Need to get above one working eg:
$ dig +short @192.33.4.12 chaos txt version.bind
"c-root"
FYI, that 192.33.4.12 IP is one of the root name servers:
$ dig +short -x 192.33.4.12
c.root-servers.net.
First thing Unbound does is update the root "." name servers in cache that were primed from the root.hints file at startup eg:
$ dig +short +norecurse @192.33.4.12 . ns
e.root-servers.net.
g.root-servers.net.
l.root-servers.net.
m.root-servers.net.
d.root-servers.net.
k.root-servers.net.
h.root-servers.net.
a.root-servers.net.
b.root-servers.net.
f.root-servers.net.
i.root-servers.net.
j.root-servers.net.
c.root-servers.net.
Need to get above queries to work or you wont be able to use Unbound for upstream.
Equivalent nslookup syntax below that you can run on a Windows, MacOS or Linux system:
nslookup -class=chaos -type=txt version.bind 192.33.4.12
nslookup -type=ns . 192.33.4.12
i can see the traffic on the UDM to the IP listed above and it is allowing it so the issue must be within the PI/pihole/unbound, still getting a fail on the call though
We've already confirmed why your unbound cannot resolve anything:
That dig tries to talk to one of the root servers directly (specifically 192.33.4.12/c.root-servers.net), mimicking what unbound would have to do when trying to resolve any domain.
The reply returned by that root server would be "c-root", but in your case, it is REFUSED.
This reply was forced by something intercepting and refusing DNS requests to (at least) that root server, and it is openly telling you it does.
That's why deHakkelaar points out:
You'd need to find out what's refusing those DNS requests.
If it isn't your router or another gateway device (like a dedicated firewall machine) in your network, that could suggest that your ISP is disallowing them.
First thing Unbound does is something similar as below:
$ delv +rtrace @192.33.4.12 . ns
;; fetch: ./NS
;; fetch: ./DNSKEY
; fully validated
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN RRSIG NS 8 0 518400 20250912170000 20250830160000 46441 . VPPJVo+7qX6uR2gsDNVaq0TkRs366dgg+XYs26zve/qm4RwAZGRhhkdG 2mzzNfdlG4DKeWVXwSkE3L1iHsePtz7q1abwYa7LF3xU0MQSqh9wa7Zf XeCCQAvhaz/onzfcUkfkliWqCQgUAi7EP27GkkQ4qRmLQ1006Z/a6vV0 4BnL7jrWjb+DRwUSN2y44WrwG5UjulgLkK4Zwi2eP13Rq2rZp+vUfz47 S0EMgRBKqVGzl5IcHcJPv7tNi7VNC6oY/a8gShp3igkkpLJoybuebWU5 21E16uc+U3gJSptf4Ck7amBRO7RkfvA9SM2yBIyN3xhrJSYv7bbkCw0P vVrikg==
If it doesnt say fully validated on your system, it means something upstream is tampering with the DNS traffic.
FYI:
$ man delv
[..]
DESCRIPTION
delv is a tool for sending DNS queries and validating the results,
using the same internal resolver and validator logic as named.
delv sends to a specified name server all queries needed to fetch
and validate the requested data; this includes the original re‐
quested query, subsequent queries to follow CNAME or DNAME chains,
queries for DNSKEY, and DS records to establish a chain of trust
for DNSSEC validation. It does not perform iterative resolution,
but simulates the behavior of a name server configured for DNSSEC
validating and forwarding.