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.
You have "Bengal" in your handle/nick.
Are you located in India?
Internet censorship in India is selectively practised by both federal and state governments. DNS filtering and educating service users in better usage is an active strategy and government policy to regulate and block access to Internet content on a large scale.
No, I don't live in India, that would be my worst nightmare, I live in neighbouring Bangladesh, don't worry it's worse here, my speakers blew up the other day due to trash level electricity and i am subjected to hollywood song parodies on loudspeakers about how we are all doomed to getting kicked by cows in the face.
Btw, Is there any way to get Ubuntu running on Raspberry Pi OS even if it means having that
cause as long as it works, I don't really care. It worked before, and the whole reason i want Unbound is to not have to use big name DNS servers like Google or Cloudflare, cause even they are subject to hacking and reduction in speed and whatnot, and it sounds cool to have a local DNS Server.
At this point, I have half a mind to even consider VPN, especially given that i can't watch ascii star wars also (not important here but thought i would mention)
Edit: Also,
yeah no they don't help. why would anyone willingly admit to glaring issues in their business?
Yeah shortly after posting I realized I made a mistake
Same applies for Bangladesh by the looks of it:
The Government has approved the usage of Deep packet inspection to monitor web traffic.[5] According to Freedom House, Bangladesh is partly free.
Meaning not only DNS is sniffed/filtered but also unencrypted SNI when connecting to web servers:
The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested.
If you configure unbound with that config file, it will function exactly the same as pihole-FTL does but without the ad blocking.
You can configure Pi-hole with any upstream DNS server IP(s) that you desire exactly the same as if you would with that unboundforward-addr config file but with one less DNS hop.
Check the Custom 1 to 4 address fields in the DNS settings also described in the docs:
But it doesn resolve DNS names to IP's recursively like unbound can if configured correctly.
Meaning no unwanted config file and below needs to resolve:
Anyone that takes a glance at local news even for one day will know how much of an understatement that is. I heard on the news yesterday about how a goverment official chastized a news reporter for asking about the election and the fact there's literally no one coming to it. "The people of sylhet just take their breakfasts late" or so it goes..
I just stared at that line for 2 hours. The only thing I need to know on a bad day is my DNS Server won't run because I live in a totalitarian third world country that spies on its citizens to suppress dissent. Can we not bring this issue to Politics? It's sad and most definitely true but I need a solution, not someone to blame. Same goes for ISP, they just said the root servers must be down or don't even exist.
I see not many options:
VPN: Have to depend on another company, and speed is going to be bonkers amount of slow, but this seems like the only (and most definitely ironic) solution to running Unbound.
Set Unbound up recursively: At least i tried.
Wait, now that I think about it, can I update manually or something, i CAN ping most of the root servers
Set up Unbound as a stub resolver with resolvconf_resolvers.conf: not that it works anyway.
Give up: Hey, at least i fixed pi-hole, so not all is lost.
YOLO: Take out the Raspberry Pi Imager, Search on Google for Solutions and forum posts, and prepare for an unending session of troubleshooting and reinstallation.
Ping is not reliable for testing end to end.
Any router/hop/firewall between you and the root servers can reply to your ICMP ping.
If you read up on how recursive resolvers work, you would find out that this is close to impossible.
They not only work with root hints and nameserver records (ns), but there are also keys involved for checking validity for the records served.
You're a bit familiar with the dig command now I presume
Have a look below at all the queries unbound makes for just resolving the www.instagram.com domain.
The "Below my good logs" part:
VPN and Tor are the only ones that can encrypt all traffic.
With that, they wont be able to sniff DNS or SNI.
EDIT: Have a look at how those keys are managed/created:
Wow, this was a ride. Well a few things I have to note from this:
I am being watched by the government right now: ...welp.
We Are Sorry, but Setting Up A Recursive DNS Server is Not Possible in your Area: It happens sometimes, most companies are American or European anyways, so this wouldn't be the first time some service was unavailable here.
Yep, definitely.
I actually knew that this was nigh impossible, but still held hope that by some miracle, I would find a tool or something that would update everything for me. Held my hopes too high, I guess.
I will.
Haven't watched it yet, will watch when I have the time.
And that ends this thread I guess. This was my first post, let's see what other interesting problems and posts i run into! (I need sleep)
So, the Solution was: There is no solution lol. It's a local issue and there's nothing I can do about it.
... oh wait sorry i meant
