Unbound times out with: "communications error to 127.0.0.1#5335: timed out"

BengalEmpire767 · July 28, 2024, 3:13pm

For dad, however, this is enough for now. sorry.

I can tell that I probably broke a lot of rules and caused the moderators a lot more trouble than it was worth, and I fully intended to take the full time required to troubleshoot this issue, no matter the back-and-forth when I came here, but as I mentioned before, my dad basically dragged me back into this quagmire, and this time too he had no patience. You can't see this, but he is right behind me, as I type this. It's just that he's not wearing his glasses right now. He practically dragged me out to fix unbound. Today. He has a short fuse.

I highly doubt this is an ISP problem, since I don't use their DNS and the ping works, but this is more likely a router problem.
This probably doesn't mean that I'll stop troubleshooting this, I just need to placate my dad for now. If worse comes to worse, I could probably scrounge up another system to test this on.

As for the hotspot idea, I have no idea how I didn't think of that, I will try that tomorrow.

As for the commands,

I still personally believe this is a local issue, especially since our country is still going through internet blackout, which is to only end on government notice, and that is only conditionally, since some services might be shut down permanently. Either that, or something is wrong with dad's new configuration from last year.

I know you all work tirelessly to work the literal magic that is Pi-hole (I installed it first a few years ago and have never looked back since) and I can tell I have troubled you all a lot, I have no excuse. And I did come here knowing that there perhaps is no end to this rabbit hole. Some things just are impossible.

This issue means a lot to me, and if it requires me to even use Tor proxy for the rest of my life, so be it. At least I will have solved his issue. I do not intend to give up this easily. I don't care what my dad says. If he doesn't approve, well he didn't help anyway.

I saw other topics about this that went nowhere, and I want the solution, now that my dad is satisfied.

Moto · July 28, 2024, 4:40pm

It would probably help if you were to tell us the make and model of your router and the country you live in.

deHakkelaar · July 28, 2024, 6:50pm

Above failure is why Unbound doesnt work for you.
The equivalent dig command for above that you can run on any Linux host with dig installed is:

$ dig +norecurse @192.36.148.17 . ns

; <<>> DiG 9.18.24-1-Debian <<>> +norecurse @192.36.148.17 . ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1792
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c1eff379f301c6d90100000066a693fc97b7012c9fff1685 (good)
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       518400  IN      NS      g.root-servers.net.
.                       518400  IN      NS      d.root-servers.net.
.                       518400  IN      NS      f.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
.                       518400  IN      NS      j.root-servers.net.
.                       518400  IN      NS      h.root-servers.net.
.                       518400  IN      NS      i.root-servers.net.
.                       518400  IN      NS      e.root-servers.net.
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      l.root-servers.net.
.                       518400  IN      NS      m.root-servers.net.
.                       518400  IN      NS      c.root-servers.net.
.                       518400  IN      NS      k.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       170.247.170.2
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    2801:1b8:10::b
a.root-servers.net.     518400  IN      AAAA    2001:503:ba3e::2:30

;; Query time: 7 msec
;; SERVER: 192.36.148.17#53(192.36.148.17) (UDP)
;; WHEN: Sun Jul 28 20:54:52 CEST 2024
;; MSG SIZE  rcvd: 851

The equivalent nslookup command syntax that you can run on any Windows, MacOS or Linux client is:

C:\>nslookup -type=ns . 192.36.148.17
in-addr.arpa    nameserver = c.in-addr-servers.arpa
in-addr.arpa    nameserver = b.in-addr-servers.arpa
in-addr.arpa    nameserver = e.in-addr-servers.arpa
in-addr.arpa    nameserver = f.in-addr-servers.arpa
in-addr.arpa    nameserver = a.in-addr-servers.arpa
in-addr.arpa    nameserver = d.in-addr-servers.arpa
f.in-addr-servers.arpa  internet address = 193.0.9.1
e.in-addr-servers.arpa  internet address = 203.119.86.101
d.in-addr-servers.arpa  internet address = 200.10.60.53
c.in-addr-servers.arpa  internet address = 196.216.169.10
b.in-addr-servers.arpa  internet address = 199.253.183.183
a.in-addr-servers.arpa  internet address = 199.180.182.53
f.in-addr-servers.arpa  AAAA IPv6 address = 2001:67c:e0::1
e.in-addr-servers.arpa  AAAA IPv6 address = 2001:dd8:6::101
d.in-addr-servers.arpa  AAAA IPv6 address = 2001:13c7:7010::53
c.in-addr-servers.arpa  AAAA IPv6 address = 2001:43f8:110::10
b.in-addr-servers.arpa  AAAA IPv6 address = 2001:500:87::87
a.in-addr-servers.arpa  AAAA IPv6 address = 2620:37:e000::53
Server:  UnKnown
Address:  192.36.148.17

(root)  nameserver = b.root-servers.net
(root)  nameserver = d.root-servers.net
(root)  nameserver = g.root-servers.net
(root)  nameserver = h.root-servers.net
(root)  nameserver = m.root-servers.net
(root)  nameserver = a.root-servers.net
(root)  nameserver = j.root-servers.net
(root)  nameserver = c.root-servers.net
(root)  nameserver = e.root-servers.net
(root)  nameserver = l.root-servers.net
(root)  nameserver = i.root-servers.net
(root)  nameserver = f.root-servers.net
(root)  nameserver = k.root-servers.net
m.root-servers.net      internet address = 202.12.27.33
l.root-servers.net      internet address = 199.7.83.42
k.root-servers.net      internet address = 193.0.14.129
j.root-servers.net      internet address = 192.58.128.30
i.root-servers.net      internet address = 192.36.148.17
h.root-servers.net      internet address = 198.97.190.53
g.root-servers.net      internet address = 192.112.36.4
f.root-servers.net      internet address = 192.5.5.241
e.root-servers.net      internet address = 192.203.230.10
d.root-servers.net      internet address = 199.7.91.13
c.root-servers.net      internet address = 192.33.4.12
b.root-servers.net      internet address = 170.247.170.2
a.root-servers.net      internet address = 198.41.0.4
m.root-servers.net      AAAA IPv6 address = 2001:dc3::35
l.root-servers.net      AAAA IPv6 address = 2001:500:9f::42

As long as those commands dont resolve, you wont be able to get Unbound to work recursively.
If its not router related settings preventing/blocking those lookups, I would suggest to take it up with your ISP and show them results for above dig or nslookup results or both.
Tell them you want to run a recursive DNS resolver at home.
They should be able to help if its related to router settings.
Or they should be able to tell if those queries are getting blocked at the ISP level.

BengalEmpire767 · July 29, 2024, 4:40pm

TP-Link TL-R480T+ v9.0 and I live in Bangladesh.

BengalEmpire767 · July 29, 2024, 5:03pm

That's the thing. I already have. I didn't mention it back then but I did, right after I made that post. They dismissed me and that said probably it was a problem on the root server's end. (as weird as that sounds)

That's why I mentioned Tor this time around, because I was a bit familiar with it, and hoped it could bypass my ISP in this regard, since I know for sure they aren't going to cooperate.

Deja vu, but I keep going this time.

chrislph · July 29, 2024, 5:05pm

Any luck with the hotspot?

deHakkelaar · July 30, 2024, 3:18am

Switch provider if they cant support this minor technical issue.

Moto · July 30, 2024, 10:25am

I am no expert.
If I was faced with this problem I would break it down into simple steps, testing at each stage. We know you are using a router with multiple WANs capable of load sharing in a country known for blocking popular web sites. A reliable VPN might be what you need.

I would start with the router with one WAN enabled, DHCP server enabled and using the ISP's DNS servers. Is internet access what is expected. Using https://www.dnsleaktest.com/ do I see the expected ISP's DNS server in the results.

Now change the routers DNS servers in DHCP to public DNS servers such as 8.8.4.4 Reconnect my client PC to the network and retest internet access and retest using https://www.dnsleaktest.com/ If the test shows anything other than the public DNS server then your ISP or government is redirecting your DNS queries.

If everything is good so far, install RPiOS on your Pi, run updates:
sudo apt-get update && sudo apt-get full-upgrade -y
Do you have good internet access on your pi. If so then install pihole and configure using a public DNS server. Manually set your DNS server on your client PC to use pihole. Does the web interface show the pihole is receiving requests and is blocking sites.
If it is good you now have a choice.

Either configure DHCP on your router adding only the Pis address as DNS server or disable the DHCP server on the router and enable it on the Pi but the Pi must have a static IP in the case where the router DHCP is disabled.
Only after you have passed this stage do you need to install and configure Unbound following unbound - Pi-hole documentation

BengalEmpire767 · July 31, 2024, 12:23pm

Nope. Same result.

BengalEmpire767 · July 31, 2024, 12:34pm

cough coughDad no switch providercough cough

...on another note, that is not possible with the atmosphere in our area. Internet is still finnicky, and ISPs are infamous for taking advantage of customers when they switch providers, and charge them more than the government-mandated price. For example, we pay 1500 bucks for 3 Megabytes (And Upload Speed is always 0.5 MB)...

...BTCL's rate for 5 Megabytes is 500. We pay the cheapest in the entire residential area. Truth is stranger than fiction.

BengalEmpire767 · July 31, 2024, 12:39pm

I see only Google and Quad9

Aye aye, captain.

Ok.

Um... what. But that's what I did the fir-
Well... here we go i guess.

BengalEmpire767 · July 31, 2024, 12:46pm

Nothing happened. Thanks still, though. Was worth a try.

chrislph · July 31, 2024, 2:14pm

Are you 100% sure that you were on the hotspot, with an IP address and DNS coming from the hotspot and the Windows machine absolutely not using your home network? For example if you have hard coded Pi-hole as the Windows DNS, this test is pointless, it has to be completely off your home network and on the hotspot so that you are removing all home elements, apart from the Windows machine, (Pi-hole, Unbound, router, ISP) from the test.

The Windows machine itself seems okay since the issues it's seen are also being seen by the Pi-hole OS, ie Windows itself appears to not be relevant and can therefore be used for the above testing with good confidence.

Your lookup tests and earlier log show:

querying against google 8.8.8.8 worked
querying against a public AWS server (same one debug log used) timed out
querying against cloudlfare 1.1.1.1 worked
querying against quad9 9.9.9.9 worked
querying the txt record for ATLAS against the A root server timed out
querying the I root server timed out

These results are not tied to Unbound, your Pi-hole OS or Windows. There really is something external causing those timeouts. As a result of those timeouts, Pi-hole cannot access infrastructure it needs (eg AWS DNS) and Unbound evidently cannot perform recursive lookups.

Correctly testing on the hotspot removes all the home elements and apparently just leaves a regional cause. You may wish to try powering off all your home kit (router, Pi-hole, extenders) so your home network is offline, and then try the hotspot test again with a different machine if you have one. You can then be sure your home network is not involved in the testing.

Other than that, I'm sorry but I'm out of further ideas. It doesn't look like a Pi-hole or Unbound problem per se; rather, something else is preventing access to certain external servers and this is preventing Unbound from working.

At this stage you may prefer to ditch Unbound and set your Pi-hole upstream to a privacy-focused external resolver such as Quad9's 9.9.9.9. Note that this won't fix any issues where Pi-hole or its OS cannot access AWS DNS servers, but at least you will have ad blocking and good privacy during normal use.

chrislph · July 31, 2024, 2:42pm

Out of interest, on your home network try this command in a Pi-hole terminal, to check that Pi-hole can access its own service:

nslookup -class=chaos -type=txt version.bind 127.0.0.1

Try this command in the Windows terminal, to check that it can access Pi-hole's service (use the correct IP for that last part):

nslookup -class=chaos -type=txt version.bind IP_OF_PIHOLE

Both tests should give a result similar to "dnsmasq-pi-hole-v2.90+1" that makes it clear Pi-hole was queried.

Moto provided a methodical approach for testing where the failure gets introduced. You replied "Nothing happened. Thanks still, though. Was worth a try."

That response makes no sense. What will always happen is that it either all works as expected, or else it stops working as expected at some point, which is the point of using that methodical approach. So, did you go through all those steps? If so, at what exact point did you stop getting expected results? But if not, then please start over and follow it. It will allow you to identify the most likely cause. Then please report the results here.

BengalEmpire767 · July 31, 2024, 3:20pm

I turned off ethernet and switched wifi to hotspot. (gov gives 5 gigabytes of free internet to compensate for chaos).
I tried one of the root servers which i tested earlier. I also think its a regional problem. Unbound stays to keep my dad happy, although I will switch its resolver to quad9 or cloudflare. I might still test Tor, although I don't have high hopes.

chrislph · July 31, 2024, 6:27pm

Have you tried the above nslookup commands to confirm Pi-hole is responding?

What is it about Unbound that your father likes? If it's the additional privacy, that comes from being a recursive resolver. If you're changing it to a forwarding resolver you'll get the same privacy as simply cutting out Unbound and putting the external resolver directly into Pi-hole's Settings > DNS. It will also be a simpler setup that way.

deHakkelaar · July 31, 2024, 7:35pm

I believe we're going in circles:

@BengalEmpire767 , elaborate why you want Unbound as upstream for Pi-hole if you cant get it to work recursively, like the official guide, bc all DNS root servers time-out?

BengalEmpire767 · August 3, 2024, 9:46am

The fact that it is Unbound. Apparently it has some magic or something, and if I fail to get unbound working, I'm not good at computers. The logic here is over the roof, don't question it. It's just tragically comedic, I suppose.

I have been, and probably someday again will be, bashing my head against this issue. My dad wants Unbound (clear as that), and doesn't believe that it doesn't work recursively here. I think the one time resolv.conf turned unbound into a forwarding resolver really got into his head.

In his head, if it works, it works recursively.

What? This dude on a forum says it's not? Well he doesn't know stuff.

I got unbound to once again forward DNS requests to Google, and that seems to get his interest away from this issue for now.

I have formatted the installation so many times, the SD card back from the original post is long gone, and even the USB flash drive the Raspberry Pi is using right now is on its last legs, giving write errors, hence:

I say that I believe that this is a local issue, but some part of me really did believe that maybe, just maybe, since others reported this issue, that it could be something else.

I just wanted this over with, and ended up bothering you all more than it was worth it, to be honest. There's truly some things that can't be fixed I suppose.

Give it a few weeks, and he will probably realize it's not recursive and go off on me, but at this point I surrender. I can do no more.

And this isn't the first place I looked to either, because my dad got his hands on this page as well,

You can probably guess what happened next. Fortunately, he got no response. I don't blame 'em.

That's it then. I suppose. This IS a local issue.

deHakkelaar · August 3, 2024, 11:50am

If have good contact with your neighbors, ask them to run the nslookup's on their PC.
Or preferably someone else who's connected through the same ISP.

The way you have it now with that Unbound forward-addr directive to Google is complicating your setup unnecessarily!

deHakkelaar · August 3, 2024, 2:29pm

As all the IPv4 root servers have a TCP component along with UDP:

$ awk '/ A / {print $4,"53"}' /usr/share/dns/root.hints | xargs -n 2 nc -nvzw 3
(UNKNOWN) [198.41.0.4] 53 (domain) open
(UNKNOWN) [199.9.14.201] 53 (domain) open
(UNKNOWN) [192.33.4.12] 53 (domain) open
(UNKNOWN) [199.7.91.13] 53 (domain) open
(UNKNOWN) [192.203.230.10] 53 (domain) open
(UNKNOWN) [192.5.5.241] 53 (domain) open
(UNKNOWN) [192.112.36.4] 53 (domain) open
(UNKNOWN) [198.97.190.53] 53 (domain) open
(UNKNOWN) [192.36.148.17] 53 (domain) open
(UNKNOWN) [192.58.128.30] 53 (domain) open
(UNKNOWN) [193.0.14.129] 53 (domain) open
(UNKNOWN) [199.7.83.42] 53 (domain) open
(UNKNOWN) [202.12.27.33] 53 (domain) open

EDIT: Shortened the timeout for nc to three seconds (-w 3).