The part in brackets tells you which DNS server Pi-hole sent your query to. In this case it is localhost#5335 which is your own Unbound running on port 5335. This is correct and means your Pi-hole is sending its queries to your Unbound which is running alongside it on the same Pi.
So the question is whether Unbound itself has some problem which is causing SERVFAIL. As @Bucking_Horn said the timing info has to be correct or else the data that Unbound fetches will appear to be outdated and will be rejected, and it's a common problem so a good place to start.
Try running the command below and see if you have the correct numbers for Local time, Universal time, Time zone, is the System clock synchronized and is NTP active.
timedatectl
Local time: Fri 2022-11-25 22:51:19 -03
Universal time: Sat 2022-11-26 01:51:19 UTC
RTC time: n/a
Time zone: America/Bahia (-03, -0300)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
NTP was disabled. I'm getting NOERROR using dig.
But how (or where) can I make sure is it really working as it should?
It says active in the output so I assume you enabled it?
To test it now, try flushing the Unbound cache (note the dot at the end of the command) and then running the DNSSEC test from the Pi-hole Unbound setup guide.
It looks like the problem was what @Bucking_Horn said, and your system time was wrong. This turned out to be because NTP wasn't enabled and your enabling of it fixed the problem and this allowed Unbound to work correctly.
If you installed it from the Pi-hole guide (here) then that sets it up to fully resolve domains name locally. In this mode it's called a "recursive resolver" because it steps through the domain name one piece at a time and resolves each piece.
This is the same as what an external name server like Google would be doing, only you're doing it yourself directly now. It's much better for privacy, and Pi-hole and Unbound in recursive mode work really well together. The earlier online guide explains the difference between sending your queries to an external server vs resolving them yourself.
You can confirm it by looking at your dig output. Where it says flags you have ra (recursion available). That's Unbound telling your dig command that it's configured as a recursive resolver. [ Edit - the above is not correct because the ra flag would also be picked up from an external upstream resolver if Unbound was simply forwarding requests to that resolver ]
No need to be sorry, you're very welcome; these kind of questions and answers also help others who find Pi-hole and this forum later on.
Thinks for replying and for the understanding of my situation.
One last thing. An odd thing. Looking for the reasons why it wasn't working before posting here I've noticed that my unbound log it's not recording anything.
This is my permissions:
ls -ld /var/log/unbound/
drwxr-xr-x 2 unbound unbound 4096 Nov 24 20:23 /var/log/unbound/
Do you happen to have an idea of what might be happening here?
It's working. Don't get me wrong. But i feel that it might come handy in the future to use that log.
Yes you're right, it's handy to have a dedicated log file available for it. You have to enable it – as standard it's using syslog. See the Add logging to unbound section at the end of that online guide for the steps.
In summary, in pi-hole.conf you'll uncomment the logfile entry to enable logging into /var/log/unbound/unbound.log, then create the logfile and set its permissions, and finally restart Unbound.
A handy tip; in pi-hole.conf add the line below to make the logging use human-readable time.
log-time-ascii: yes
At verbosity level 1 you just get Unbound start and stop entries. If you hit a weird problem you can temporarily knock it up to a higher level to help diagnose it, and put it back to 1 when done. It can get quite large at higher verbosity levels. If you ever need to zero the log after filling it with diagnostics, you can do so with the command
The above truncate command will empty the unbound.log file and set the size back to 0, without deleting the file itself. This way the file still exists and Unbound can continue to add new entries to it.
On verbosity level 1 you don't need to worry about this at all. It's useful if you have been doing some higher level verbosity diagnostics and the file has grown a lot with domain details.
Devices will recognise the domain pi.hole as resolving to your Pi-hole if their query is ultimately answered by the Pi-hole, ie because either they are using the Pi-hole for their DNS, or because they are using something else, such as a router, and that is using Pi-hole for it's DNS.
