There are not enough stats collected yet for proper diagnosing.
But I believe thats not relevant bc of below.
Above query is missing the dot "." at the end (the dot represents the root of DNS):
But as the nslookup command isn't able to connect either, I believe it also doesnt matter.
The way things work, remember those root.hints from the guide?
pi@ph5b:~ $ cat /usr/share/dns/root.hints
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
[..]
B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201
[..]
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
When unbound starts, it loads all those hints in cache.
And first thing it does when receiving a query from a client is to update those root servers in cache similar like below:
pi@ph5b:~ $ dig +norecurse @199.9.14.201 ns .
[..]
;; ANSWER SECTION:
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
[..]
;; ADDITIONAL SECTION:
[..]
c.root-servers.net. 518400 IN A 192.33.4.12
b.root-servers.net. 518400 IN A 199.9.14.201
[..]
Without this connectivity, there is no way to get unbound working as a recursive DNS resolver.
unbound might have worked for you in the past, but that could have been bc of that unwanted config file:
As mentioned, this file configures unbound as a stub resolver instead of a recursive resolver and that works differently without any root.hints.
EDIT: FYI, the pihole-FTL daemon also functions as a stub resolver.
Yes if you run those DNS queries through a commercial VPN tunnel.