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

Help
1

;; communications error to 127.0.0.1#5335: timed out

I have a problem. I have tried troubleshooting this problem on and off for years at this point. I even asked for help about it in this forum. After a lot of tinkering (the moderators helped a lot, thx), I wholeheartedly convinced myself that this was a local issue. I still tried a few more times after that topic, but no dice.

I had almost happily forgotten about this issue, but then my dad decided to dig it out of the grave again. And I HAVE to fix it, no matter what, no weaseling my out this time. I have bashed my head again and again against this troublesome issue for two days, but no luck.

I searched around on the forums, and there were a few more cases of this same issue after my post, but their solution either doesn't work for me, or there is no solution and the topic was automatically closed after 21 days. So, I had no other choice except to come back here, just like last time. However, there are a few changes:

  1. No one is using the server except me. Last time, this meant prioritizing keeping Pi-hole running. No distractions this time.
  2. No reinstalling Raspberry Pi OS: I can't. I physically am not able to do it this time around. Please don't ask why.
  3. I have an FTP Server now, so getting files will be easier this time around.

The issue is the same this around:

Expected Behaviour:

According to pi-hole's documentation on unbound (NLnet has no online documentation really), I did the following:

sudo apt install unbound

and copied the configuration for /etc/unbound/unbound.conf.d/pi-hole.conf from there.

Then installed Pi-hole with 127.0.0.1#5335 as the DNS.

Pi-hole and Unbound have not been configured after this, with the exception of:

logfile: "/var/log/unbound/unbound.log"
verbosity: 1

for troubleshooting purposes. On that note, this is running on the latest version of Raspberry Pi OS, the only other application that is installed is vsftpd.

Pi-hole works fine.

Unbound should work fine.

Actual Behaviour:

/etc/init.d/unbound status

returns

● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; preset: enabled)
Active: active (running) since Sat 2024-07-27 18:45:36 +06; 1h 8min ago
Docs: man:unbound(8)
Main PID: 715 (unbound)
Tasks: 1 (limit: 3915)
CPU: 181ms
CGroup: /system.slice/unbound.service
└─715 /usr/sbin/unbound -d -p

Jul 27 18:45:36 Club-Net systemd[1]: Starting unbound.service - Unbound DNS server...
Jul 27 18:45:36 Club-Net systemd[1]: Started unbound.service - Unbound DNS server.

showing that it is working.

However,

dig wiby.com @127.0.0.1 -p 5335

returns

;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out

; <<>> DiG 9.18.28-1~deb12u1-Debian <<>> wiby.com @127.0.0.1 -p 5335
;; global options: +cmd
;; no servers could be reached

almost every other
topic about this issue
gets stuck here.

Here is an excerpt from unbound.log, if it helps:

[1722084067] unbound[709:0] debug: module config: "subnetcache validator iterator"
[1722084067] unbound[709:0] notice: init module 0: subnetcache
[1722084067] unbound[709:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.
[1722084067] unbound[709:0] debug: subnetcache: option registered (8)
[1722084067] unbound[709:0] notice: init module 1: validator
[1722084067] unbound[709:0] debug: reading autotrust anchor file /var/lib/unbound/root.key
[1722084067] unbound[709:0] info: trust point . : 1
[1722084067] unbound[709:0] info: assembled 0 DS and 1 DNSKEYs
[1722084067] unbound[709:0] info: DNSKEY:: . 86400 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}

[1722084067] unbound[709:0] info: file /var/lib/unbound/root.key
[1722084067] unbound[709:0] info: last_queried: 0 Thu Jan 1 06:00:00 1970
[1722084067] unbound[709:0] info: last_success: 0 Thu Jan 1 06:00:00 1970
[1722084067] unbound[709:0] info: next_probe_time: 0 Thu Jan 1 06:00:00 1970
[1722084067] unbound[709:0] info: query_interval: 0
[1722084067] unbound[709:0] info: retry_time: 0
[1722084067] unbound[709:0] info: query_failed: 0
[1722084067] unbound[709:0] info: [ VALID ] . 86400 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state:2 ;;pending_count:0 last:Thu Jan 1 06:00:00 1970
[1722084067] unbound[709:0] debug: validator nsec3cfg keysz 1024 mxiter 150
[1722084067] unbound[709:0] debug: validator nsec3cfg keysz 2048 mxiter 150
[1722084067] unbound[709:0] debug: validator nsec3cfg keysz 4096 mxiter 150
[1722084067] unbound[709:0] notice: init module 2: iterator
[1722084067] unbound[709:0] debug: target fetch policy for level 0 is 3
[1722084067] unbound[709:0] debug: target fetch policy for level 1 is 2
[1722084067] unbound[709:0] debug: target fetch policy for level 2 is 1
[1722084067] unbound[709:0] debug: target fetch policy for level 3 is 0
[1722084067] unbound[709:0] debug: target fetch policy for level 4 is 0
[1722084067] unbound[709:0] debug: donotq: 127.0.0.0/8
[1722084067] unbound[709:0] debug: EDNS known options:
[1722084067] unbound[709:0] debug: Code: Bypass_cache_stage: Aggregate_mesh:
[1722084067] unbound[709:0] debug: edns-cli NO NO
[1722084067] unbound[709:0] debug: total of 59448 outgoing ports available
[1722084067] unbound[709:0] debug: start threads
[1722084067] unbound[709:0] debug: libevent 2.1.12-stable uses epoll method.
[1722084067] unbound[709:0] debug: no config, using builtin root hints.
[1722084067] unbound[709:0] debug: cache memory msg=66072 rrset=66072 infra=7808 val=66368 subnet=74504
[1722084067] unbound[709:0] info: start of service (unbound 1.17.1).
[1722084067] unbound[709:0] debug: autotrust probe timer callback
[1722084067] unbound[709:0] info: autotrust probe . DNSKEY IN
[1722084067] unbound[709:0] debug: retry probe set in 3489 seconds
[1722084067] unbound[709:0] debug: mesh_run: start
[1722084067] unbound[709:0] debug: subnetcache[module 0] operate: extstate:module_state_initial event:module_event_new
[1722084067] unbound[709:0] info: subnetcache operate: query . DNSKEY IN
[1722084067] unbound[709:0] debug: subnetcache: pass to next module
[1722084067] unbound[709:0] debug: mesh_run: subnetcache module exit state is module_wait_module
[1722084067] unbound[709:0] debug: validator[module 1] operate: extstate:module_state_initial event:module_event_pass
[1722084067] unbound[709:0] info: validator operate: query . DNSKEY IN
[1722084067] unbound[709:0] debug: validator: pass to next module
[1722084067] unbound[709:0] debug: mesh_run: validator module exit state is module_wait_module
[1722084067] unbound[709:0] debug: iterator[module 2] operate: extstate:module_state_initial event:module_event_pass
[1722084067] unbound[709:0] debug: process_request: new external request event
[1722084067] unbound[709:0] debug: iter_handle processing q with state INIT REQUEST STATE
[1722084067] unbound[709:0] info: resolving . DNSKEY IN
[1722084067] unbound[709:0] debug: request has dependency depth of 0
[1722084067] unbound[709:0] info: priming . IN NS
[1722084067] unbound[709:0] debug: mesh_run: iterator module exit state is module_wait_subquery
[1722084067] unbound[709:0] debug: iterator[module 2] operate: extstate:module_state_initial event:module_event_pass
[1722084067] unbound[709:0] info: iterator operate: query . NS IN
[1722084067] unbound[709:0] debug: iter_handle processing q with state QUERY TARGETS STATE
[1722084067] unbound[709:0] info: processQueryTargets: . NS IN
[1722084067] unbound[709:0] debug: processQueryTargets: targetqueries 0, currentqueries 0 sentcount 0
[1722084067] unbound[709:0] info: DelegationPoint<.>: 13 names (0 missing), 13 addrs (0 result, 13 avail) parentNS
[1722084067] unbound[709:0] info: A.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: B.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: C.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: D.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: E.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: F.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: G.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: H.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: I.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: J.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: K.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: L.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] info: M.ROOT-SERVERS.NET. * A
[1722084067] unbound[709:0] debug: ip4 198.41.0.4 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 199.9.14.201 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 192.33.4.12 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 199.7.91.13 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 192.203.230.10 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 192.5.5.241 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 192.112.36.4 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 198.97.190.53 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 192.36.148.17 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 192.58.128.30 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 193.0.14.129 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 199.7.83.42 port 53 (len 16)
[1722084067] unbound[709:0] debug: ip4 202.12.27.33 port 53 (len 16)
[1722084067] unbound[709:0] debug: attempt to get extra 2 targets
[1722084067] unbound[709:0] debug: rpz: iterator module callback: have_rpz=0
[1722084067] unbound[709:0] debug: selrtt 376
[1722084067] unbound[709:0] info: sending query: . NS IN
[1722084067] unbound[709:0] debug: sending to target: <.> 192.36.148.17#53
[1722084067] unbound[709:0] debug: dnssec status: expected
[1722084067] unbound[709:0] debug: mesh_run: iterator module exit state is module_wait_reply
[1722084067] unbound[709:0] info: mesh_run: end 2 recursion states (1 with reply, 0 detached), 1 waiting replies, 0 recursion replies sent, 0 replies dropped, 0 states jostled out
[1722084067] unbound[709:0] info: 0pvCD mod2 . NS IN
[1722084067] unbound[709:0] info: 1RDdc mod2 cb . DNSKEY IN
[1722084067] unbound[709:0] debug: autotrust probe timer 1 callbacks done
[1722084067] unbound[709:0] debug: serviced send timer
[1722084067] unbound[709:0] debug: EDNS lookup known=0 vs=0
[1722084067] unbound[709:0] debug: serviced query UDP timeout=376 msec
[1722084067] unbound[709:0] debug: inserted new pending reply id=c76e
[1722084067] unbound[709:0] debug: opened UDP if=0 port=27574
[1722084067] unbound[709:0] error: udp connect failed: Network is unreachable for 192.36.148.17 port 53 (len 16)
[1722084067] unbound[709:0] debug: svcd callbacks start
[1722084067] unbound[709:0] debug: worker svcd callback for qstate 0x5583299490
[1722084067] unbound[709:0] debug: mesh_run: start
[1722084067] unbound[709:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_noreply
[1722084067] unbound[709:0] info: iterator operate: query . NS IN
[1722084067] unbound[709:0] debug: process_response: new external response event
[1722084067] unbound[709:0] debug: iter_handle processing q with state QUERY RESPONSE STATE
[1722084067] unbound[709:0] debug: query response was timeout
[1722084067] unbound[709:0] debug: iter_handle processing q with state QUERY TARGETS STATE
[1722084067] unbound[709:0] info: processQueryTargets: . NS IN
[1722084067] unbound[709:0] debug: processQueryTargets: targetqueries 0, currentqueries 0 sentcount 1
[1722084067] unbound[709:0] info: DelegationPoint<.>: 13 names (0 missing), 13 addrs (13 result, 0 avail) parentNS

Any and all help regarding this issue would be greatly appreciated. I am truly at a loss regarding this right now.

Debug Token:

https://tricorder.pi-hole.net/oFAd49Lu/

2

These should be 127.0.0.1#5335.

As an aside, from your log the DHCP server at 192.168.0.10 isn't set up right. This may be because you are still testing the main setup before switching. The DNS needs to be just Pi-hole's IP at 192.168.0.121. The domain name looks like an IP was mistakenly entered in there when it would normally be a suffix such as lan or home.arpa or somethiing specific to a brand of router such as fritz.box.

DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.0.10
      lease-time: 7200 ( 2h )
      renewal-time: 3600 ( 1h )
      rebinding-time: 6300 ( 1h 45m )
      netmask: 255.255.255.0
      broadcast: 192.168.0.255
      domain-name: "1.1.1.1"
      dns-server: 8.8.8.8
      dns-server: 9.9.9.9
      router: 192.168.0.10
      --- end of options ---
3

try
dig google.com @127.0.0.1 -p 5335 instead of
dig google.com @127.0.0.1 -p 5353

4

Oh yeah, your right. I guess my brain is fried. I edited the post, but no, the error is still there. I did actually write 5353 instead of 5335 when I ran the dig command, but the config file is fine though, it just shows how tired I am I guess. Thankfully I didn't edit much configuration aside from what I copied from the documentation.

5

Yeah, I didn't switch to Pi-hole just yet. I haven't set up blocklists, or anything else really. My main goal right now is to just get Unbound working, what you just said is concerning though, i fixed it right now. last I remember the domain name was google.com, heh. My dad isn't too good with this stuff.

6

Is it working now when you use port 5335?

7

It isn't working still.

8

Please post the output from the command below in your Pi terminal, to show your Unbound configs:

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*

From the same terminal what do you get for these commands, testing resolving:

nslookup pi-hole.net

nslookup pi-hole.net 8.8.8.8

nslookup ns-407.awsdns-50.com 8.8.8.8

nslookup ns-407.awsdns-50.com 127.0.0.1

nslookup -port=5335 ns-407.awsdns-50.com 127.0.0.1
9

sudo grep -v '#|^$' -R /etc/unbound/unbound.conf*

returns the following:

/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf: logfile: "/var/log/unbound/unbound. log"
/etc/unbound/unbound.conf.d/pi-hole.conf: verbosity: 1
/etc/unbound/unbound.conf.d/pi-hole.conf: interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf: port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf: do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf: prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf: harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf: edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf: prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf: num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf: so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 192.168.0.0/24
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 169.254.0.0/24
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fe80::/10
/etc/unbound/unbound.conf.d/remote-control.conf:remote-control:
/etc/unbound/unbound.conf.d/remote-control.conf: control-enable: yes
/etc/unbound/unbound.conf.d/remote-control.conf: control-interface: /run/unboun d.ctl
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf: auto-trust-anch or-file: "/var/lib/unbound/root.key"

meanwhile:

nslookup pi-hole.net

returns:

Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: pi-hole.net
Address: 3.18.136.52

.

nslookup pi-hole.net 8.8.8.8

results in:

Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: pi-hole.net
Address: 3.18.136.52

.

nslookup ns-407.awsdns-50.com 8.8.8.8

result:

Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: ns-407.awsdns-50.com
Address: 205.251.193.151
Name: ns-407.awsdns-50.com
Address: 2600:9000:5301:9700::1

.

nslookup ns-407.awsdns-50.com 127.0.0.1

result

;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
;; no servers could be reached

.

nslookup -port=5335 ns-407.awsdns-50.com 127.0.0.1

result

;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; no servers could be reached

10

Thanks can you also run the commands below please?

nslookup pi-hole.net 205.251.193.151

sudo netstat -tulpn

ls -l /etc/dnsmasq.d/
11

The above unbound trace indicates: The unbound process is failing to communicate with the public internet address 192.36.148.17 using UDP to port 53. This trace log could be a one-off, and thus a red herring. OR it could be indicative of issues with your home lan setup.

While there are multiple possible causes, a frequent cause is firewall setups on either the unbound service's host, or with your network's internet router setup. Possibly its firewall.

I just checked that DNS server is available, using this command:

dig @192.36.148.17 com. SOA

If your workstation lacks the dig command, nslookup might work:

nslookup -type=soa com. 192.36.148.17

12

nslookup pi-hole.net 205.251.193.151

returns

;; communications error to 205.251.193.151#53: timed out
;; communications error to 205.251.193.151#53: timed out
;; communications error to 205.251.193.151#53: timed out
;; no servers could be reached

sudo netstat -tulpn

returns

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 926/lighttpd
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 904/pihole-FTL
tcp 0 0 127.0.0.1:4711 0.0.0.0:* LISTEN 904/pihole-FTL
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 725/sshd: /usr/sbin
tcp 0 0 127.0.0.1:5335 0.0.0.0:* LISTEN 731/unbound
tcp6 0 0 ::1:4711 :::* LISTEN 904/pihole-FTL
tcp6 0 0 :::80 :::* LISTEN 926/lighttpd
tcp6 0 0 :::53 :::* LISTEN 904/pihole-FTL
tcp6 0 0 :::21 :::* LISTEN 720/vsftpd
tcp6 0 0 :::22 :::* LISTEN 725/sshd: /usr/sbin
udp 0 0 127.0.0.1:5335 0.0.0.0:* 731/unbound
udp 0 0 0.0.0.0:5353 0.0.0.0:* 557/avahi-daemon: r
udp 0 0 0.0.0.0:59426 0.0.0.0:* 557/avahi-daemon: r
udp 0 0 0.0.0.0:53 0.0.0.0:* 904/pihole-FTL
udp6 0 0 :::5353 :::* 557/avahi-daemon: r
udp6 0 0 :::53 :::* 904/pihole-FTL
udp6 0 0 fe80::3dd8:21ab:3bc:546 :::* 639/NetworkManager
udp6 0 0 fe80::1887:1072:784:546 :::* 639/NetworkManager
udp6 0 0 :::39841 :::* 557/avahi-daemon: r

ls -l /etc/dnsmasq.d/

returns

total 8
-rw-r--r-- 1 root root 1372 Jul 27 18:35 01-pihole.conf
-rw-r--r-- 1 root root 2190 Jul 27 18:35 06-rfc6761.conf

13

dig @192.36.148.17 com. SOA

returns

;; communications error to 192.36.148.17#53: timed out
;; communications error to 192.36.148.17#53: timed out
;; communications error to 192.36.148.17#53: timed out

; <<>> DiG 9.18.28-1~deb12u1-Debian <<>> @192.36.148.17 com. SOA
; (1 server found)
;; global options: +cmd
;; no servers could be reached

14

It seems that unbound is suffering from network connectivity issues. Can you ping? Like this:

ping 192.36.148.17

If the ping fails, there is probably something wrong with IPv4's default routing to the internet. The most likely cause is issues with the IPv4 configuration of that machine. Is it DHCPv4, or static configured? DHCPv4; check the DHCPv4 server settings (it's likely your home router). Static; check your local IPv4 configuration. Is the default IPv4 route set correctly?

Does another computer on the same LAN, have the same problem? Yes; it's more likely the home router that is at fault. No; it's more likely an issue with the unbound server's computer itself.

If the ping succeeds, there is something wrong with UDP and/or UDP port 53. In this case it's likely firewall issues of some kind. For example: some home routers play games by redirecting UDP 53 in various ways.

The above are merely general tips. Troubleshooting network connectivity issues can complex.

Good Luck!

15

Yes, I have tried to ping the IP address from my computer. The ping works. I am outside right now, when I get back, I will send a screenshot.
Also, it isn't that hard to believe that something could be wrong with my router. My dad set it up, and it has spewed errors for years at this point. We tried to unclog the router a bit last year, but I wouldn't be surprised if it starts acting up again.
Edit: Unfortunately, I have absolutely no idea what to do to fix it. This is most likely a router problem.

17

image

18

My best guess, is that your home router is blocking DNS traffic (destination port 53/udp) between your LAN and the internet.

I suggest checking your home router's settings; check for DNS settings that 'redirect' DNS traffic and/or firewall settings related to DNS, or port 53/udp.

Unfortunately, I cannot be any more specific than that. Home routers vary widely in settings and features.

It's weird... that 8.8.8.8 works. Perhaps there is something about the 192.x.x.x address that is being blocked?

19

Well, 192.168.0.10 is the router's IP address, and all local IPs start with 192.x.x.x, that could be the problem. Didn't stop ping from working, I don't know.

20

You know what, I have been tearing my hair over this for like 3 days now through load shedding and constant annoying, and the only acknowledgement I get is 'do more until it's fixed'.

In my original post, I stumbled upon unbound magically working. Turns out it wasn't, but now I don't care anymore if it's recursive or not. How do I get this back to work, cause now, I need unbound to work, whether it gives any benefits or not is not my problem anymore.

It might sound a bit rude but I want it. I just want unbound to look like it's working now.

If you are wondering, the router setup remains untouched. I can't touch my dad's wonderful handiwork. Fantastic.

If you can help regarding this, please do.

21

With respect, we all want our installations to work and most of the time they do. The Pi-hole installer takes care of the Pi-hole requirements and gives instructions to follow, and the Unbound guide includes everything needed to get it running with Pi-hole.

There are situations, like yours, where something else is going on, on the Pi-hole system or the network or both. Only you know how your network and devices are set up. And people may not follow the guides fully; for example you did not create an EDNS config file in /etc/dnsmasq.d, so I had to test here if that omission might be relevant.

This is why things like debug logs and config files are requested, in order to see what's going on around the setup. You can expect this process to go back and forth as testing reveals further information. The three examples you linked to either resulted in a lot of discussion or else never received the information requested.

The tests I requested from you show that the OS running Pi-hole can access Google's public DNS server 8.8.8.8 but that it cannot access an AWS public DNS server. Your debug log shows the same AWS blockage. Nor can Unbound access authoritative servers, causing it to time out. The test you did for wblew shows the same.

This implies that somethinig on your network is allowing devices to talk to only Google DNS. My guess would be your router is playing some part in this. Possibly a firewall rule in there, if it supports such. Another option, less likely, is that your ISP is taking control of your DNS. And it could be the Pi OS itself which is the problem. So this requires more testing. There is no shortcut to make it "just work". We are essentially reverse-engineering the peculiarities of your network via a forum. It might take days to get to the bottom of, or it might never be resolved.

From another machine on your network, eg a Windows machine without any extra anti-virus installed, try running these commands. These are testing to see if other machines besides the Pi-hole are similarly blocked from accessing external DNS servers or if DNS is being hijacked.

nslookup pi-hole.net 8.8.8.8
nslookup pi-hole.net 205.251.193.151
nslookup pi-hole.net 1.1.1.1
nslookup pi-hole.net 9.9.9.9
nslookup -class=chaos -type=txt version.bind 198.41.0.4

Note you can copy text from a Windows terminal by selecting it with your mouse and pressing Enter or using the menu Copy option.

Can you get into the router and hunt around for firewall rules, parental controls, anything like that which might be messing with access permissions? It would be worth you taking a look in there.

Edit: Another test which occured to me - if your smartphone supports being a hotspot, activate that, disconnect your Windows machine from your home network and connect to your hotspot. Then run the same nlsookup commands again. That takes your router out of the equation, but make absolutely sure that you really are disconnected from it and are on the hotspot only.