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 (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.
Expected Behaviour:
I install Pi-hole and then unbound. Unbound works.
Ubuntu 22.04
Raspberry Pi
Actual Behaviour:
Pi-hole works like normal, but Unbound receives the DNS Request (i checked the logs), and simply doesn't respond, like at all.
Only non-standard change I made was changing verbosity to 3 to try to figure out what on earth was wrong with it. After an entire day of troubleshooting, I am at the end of my rope. HELP.
Your dig result suggest that unbound cannot be contacted.
Did you verify that unbound was active at that time, e.g.
sudo systemctl status unbound
And if you run a firewall on your RPi: even though its unlikely that your RPi 's firewall would block localhost traffic, you should check that port 5335 is not blocked.
yeah. about that. alot has happened since the last post. long story short, the entire system disintegrated and now i am trying this whole thing again with raspberry pi os. yoohoo! yay! also no i had no firewall at all. nor any issues related to it. unbound was running perfectly fine. said something aling the lines of "Unbound DNS Server started" or something and then nothing. should i open a new post or just edit this one if raspberry pi os also fails. will reply whatever cryptic error appears straight onto this post. guessing nothing will change.
it would be nice to know what happened tho. does pi-hole not supposed to work on ubuntu 22.04 or something. as far as i know it couldnt have been the installation. formatted it way too many times.
Edit: wish i got more screenshots.
The root problem seems to be that Unbound gives absolutely no response, despite it apparently running and being correctly assigned the port 5335, and there being no firewall.
So, this time I have a plan, I will list all the commands I did on first boot, since I will practically did nothing else except dig pi-hole.net @127.0.0.1 -p 5335 and sudo apt update, sudo apt upgrade etc.
all the commands i did on the first three boots, no exceptions, unbound gave absolutely no response to any queries whatsoever during the entirety of this and beyond. (why do i feel like im not being very helpful to you all)
I also promise to not format the entire drive again throughout the entirety of this thread.
Notice I filter the journals to only show those of -S today !
Check man page for syntax eg:
pi@ph5b:~ $ man journalctl
[..]
-S, --since=, -U, --until=
Start showing entries on or newer than the specified date, or
on or older than the specified date, respectively.
[..]
And please copy/paste text output to here instead of screenshots?
You can format the output here with the </> button before posting like I did above ^
Is easier to process eg copy/paste/quote, and easier to find for others with similar problems.
cat: /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf: No such file or directory
I am reduced to using cloudflare, for now
# Generated by resolvconf
nameserver 1.1.1.1
nameserver 1.0.0.1
For the journal, I managed to crash my browser instantly by copying the journal (verbosity was set to three, suprise suprise), before realizing there was a word limit
Jun 20 13:55:44 raspberrypi systemd[1]: Starting Unbound DNS server...
Jun 20 13:55:44 raspberrypi unbound[558]: [558:0] info: start of service (unbound 1.13.1).
Jun 20 13:55:44 raspberrypi systemd[1]: Started Unbound DNS server.
Is this all there is when things go south? (EDIT: with verbosity set to 3?)
If so, increase verbosity to get more details?
pi@ph5b:~ $ man unbound.conf
[..]
verbosity: <number>
The verbosity number, level 0 means no verbosity, only er‐
rors. Level 1 gives operational information. Level 2 gives
detailed operational information. Level 3 gives query level
information, output per query. Level 4 gives algorithm
level information. Level 5 logs client identification for
cache misses. Default is level 1. The verbosity can also
be increased from the commandline, see unbound(8).
I think I have enough disk space (for now), especially given that I had it set to verbosity 3, sometimes 5 for a month before this.
Also, Yes, this is literally all there is when things go south. It says started, earlier attempts even said that unbound got the requests, but there was no response from unbound, at all. but this time i set verbosity to 0 because of above mentioned reason. I did try to again send the journal with verbosity 3, but this happened
Welp, looks like i have to do with images, sorry! ...is what i would have said if i didn't run into two problems:
the journal is stupidly long, couldn't even scroll to the end, --no-pager seems to keep the beginning parts out, and accessing it normally leads to an unscrollably long journal.
so, i am going to close my eyes and hope for the best...
and maybe also spam the last 5000 words of the journal (i don't know if this counts but i did dig google.com @127.0.0.1 -p 5335, dig www.google.com @127.0.0.1 -p 5335, dig pi-hole.net @127.0.0.1 -p 5335 right before copying this journal)
This could indicate that there is something going wrong on the path to those root servers (eg UDP packet size), or some DNS filtering going on upstream (maybe your ISP).
Check your router for DNS related security settings like filters or redirecting DNS!
For both above problems, you should ask your ISP for support!
When things go south, do you get below same similar reply?
pi@ph5b:~ $ dig +norecurse @199.9.14.201 ns .
; <<>> DiG 9.16.22-Raspbian <<>> +norecurse @199.9.14.201 ns .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27200
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6baf8941e3ec25050100000064936dc71d89cb79224f3b55 (good)
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518400 IN NS i.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS l.root-servers.net.
;; ADDITIONAL SECTION:
m.root-servers.net. 518400 IN A 202.12.27.33
l.root-servers.net. 518400 IN A 199.7.83.42
k.root-servers.net. 518400 IN A 193.0.14.129
j.root-servers.net. 518400 IN A 192.58.128.30
i.root-servers.net. 518400 IN A 192.36.148.17
h.root-servers.net. 518400 IN A 198.97.190.53
g.root-servers.net. 518400 IN A 192.112.36.4
f.root-servers.net. 518400 IN A 192.5.5.241
e.root-servers.net. 518400 IN A 192.203.230.10
d.root-servers.net. 518400 IN A 199.7.91.13
c.root-servers.net. 518400 IN A 192.33.4.12
b.root-servers.net. 518400 IN A 199.9.14.201
a.root-servers.net. 518400 IN A 198.41.0.4
m.root-servers.net. 518400 IN AAAA 2001:dc3::35
l.root-servers.net. 518400 IN AAAA 2001:500:9f::42
k.root-servers.net. 518400 IN AAAA 2001:7fd::1
j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30
i.root-servers.net. 518400 IN AAAA 2001:7fe::53
h.root-servers.net. 518400 IN AAAA 2001:500:1::53
g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d
f.root-servers.net. 518400 IN AAAA 2001:500:2f::f
e.root-servers.net. 518400 IN AAAA 2001:500:a8::e
d.root-servers.net. 518400 IN AAAA 2001:500:2d::d
c.root-servers.net. 518400 IN AAAA 2001:500:2::c
b.root-servers.net. 518400 IN AAAA 2001:500:200::b
a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30
;; Query time: 9 msec
;; SERVER: 199.9.14.201#53(199.9.14.201)
;; WHEN: Wed Jun 21 23:38:15 CEST 2023
;; MSG SIZE rcvd: 851
Or alternatively on a Windows/MacOS/Linux client of yours:
Maybe I should have said the entire story, but when i opened this post I was way too stressed to say anything. So I am going to take a long detour (i promise to circle back) and start from the beggining:
A few days before before this debacle, everything was normal and happy (mostly) and we used all Pi-hole all the time. But then we saw something like this:
[copied from google cuz i didn't take screenshot]
We tried many things, but were unable to fix this issue... before Ubuntu 22.04 died (anti-climactic if you ask me). I reinstalled Ubuntu, and Good news! Pi-hole is back up and running but at the expense of Unbound not responding to anything, no errors , no answer to queries, no nothing.
I set verbosity to 3 (or 5, i forgot, but later i set it to 3). i did dig google.com @127.0.0.1 -p 5335 and checked the journal and it said somthing about query and google.com. at this point, i felt pretty sure that unbound was receiving queries and just not responding to them. and so i went searching from forum to forum for answers, reinstalled ubuntu a bunch of times, none of their solutions fixed my issue, and then...
you know what happens next. in fact, with the exception of
one single day of actually working, unbound returned to it's old ways. finally my father had enough of not being able to do anything, changed the dns, and my exams finished,
giving me a whole another chance to crack this mystery, and here we are now.
hopefully that should clear things, but i went to this whole detour to prove a point and that is that...
unbound has and had no uptime, throughout almost the entirety of this post.
i for some reason thought that you are assuming that unbound works for a few seconds after boot (i saw that in a few forum posts i think). if you were hopefully this should clear things and if not...
now that we are back from the long detour (forgive me on that one please), about this...
no. i did block those servers on my pi-hole once though, but that installation has been wiped already so that can't be it.
dig +norecurse @199.9.14.201 ns
; <<>> DiG 9.16.37-Debian <<>> +norecurse @199.9.14.201 ns
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
C:\>nslookup -type=ns . 199.9.14.201
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 199.9.14.201
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
My router doesn't have dns related security settings like filters or redirecting dns and it's the same router and same configuration that served well with pi-hole for many years, so no issues there.
and from what i can tell, firstly no they won't help, and secondly that would actually explain a lot.
Is there any way to cirumvent isp filtering my dns, cause that would help if it were to be the case
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.
... oh wait sorry i meant