The output was quite large so I used pastebin to post the log:
UNBOUND LOG - Pastebin.com
Below bit repeating in the journals is failing to connect (module_event_noreply):
Nov 21 10:27:32 raspberrypi unbound[10894]: [10894:0] info: sending query: ns3.bezeqint.net. A IN
Nov 21 10:27:32 raspberrypi unbound[10894]: [10894:0] debug: sending to target: <bezeqint.net.> 212.179.7.7#53
[..]
Nov 21 10:27:32 raspberrypi unbound[10894]: [10894:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_noreply
The equivalent dig command would be:
dig +norecurse @212.179.7.7 ns3.bezeqint.net. A IN
Could you try above one on the Pi-hole host and post results pls?
Also if you have a Windows, MacOS or Linux client, could you post results for below too when run in a command prompt/terminal window pls?
nslookup -type=a ns3.bezeqint.net. 212.179.7.7
FYI, below are all the queries made by unbound from those journals you posted:
$ ./unbound_check.sh unbound.bad.journals | column -t
dig +norecurse @198.41.0.4 . NS IN
dig +norecurse @192.203.230.10 il. A IN
dig +norecurse @204.61.216.134 co.il. A IN
dig +norecurse @128.139.35.5 clalit.co.il. A IN
dig +norecurse @199.7.91.13 net. A IN
dig +norecurse @199.9.14.201 net. A IN
dig +norecurse @198.97.190.53 net. A IN
dig +norecurse @192.31.80.30 bezeqint.net. A IN
dig +norecurse @192.54.112.30 bezeqint.net. A IN
dig +norecurse @62.219.128.128 ns2.bezeqint.net. A IN
dig +norecurse @192.115.132.132 ns1.bezeqint.net. A IN
dig +norecurse @192.12.94.30 bezeqint.net. A IN
dig +norecurse @212.179.7.7 ns3.bezeqint.net. A IN
dig +norecurse @192.115.132.132 ns2.bezeqint.net. A IN
dig +norecurse @212.179.7.7 ns1.bezeqint.net. A IN
dig +norecurse @192.115.132.132 ns3.bezeqint.net. A IN
dig +norecurse @212.179.7.7 ns2.bezeqint.net. A IN
dig +norecurse @62.219.128.128 ns1.bezeqint.net. A IN
dig +norecurse @62.219.128.128 ns3.bezeqint.net. A IN
dig +norecurse @212.179.7.7 ns1.bezeqint.net. A IN
dig +norecurse @62.219.128.128 ns3.bezeqint.net. A IN
dig +norecurse @192.115.132.132 ns2.bezeqint.net. A IN
dig +norecurse @212.179.7.7 e-services.clalit.co.il. A IN
dig +norecurse @212.179.7.7 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 ns3.bezeqint.net. A IN
dig +norecurse @192.115.132.132 e-services.clalit.co.il. A IN
dig +norecurse @212.179.7.7 ns2.bezeqint.net. A IN
dig +norecurse @62.219.128.128 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 ns1.bezeqint.net. A IN
dig +norecurse @62.219.128.128 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 e-services.clalit.co.il. A IN
dig +norecurse @212.179.7.7 e-services.clalit.co.il. A IN
dig +norecurse @62.219.128.128 ns3.bezeqint.net. A IN
dig +norecurse @62.219.128.128 ns1.bezeqint.net. A IN
dig +norecurse @62.219.128.128 e-services.clalit.co.il. A IN
dig +norecurse @62.219.128.128 e-services.clalit.co.il. A IN
dig +norecurse @62.219.128.128 ns2.bezeqint.net. A IN
dig +norecurse @212.179.7.7 e-services.clalit.co.il. A IN
dig +norecurse @62.219.128.128 ns3.bezeqint.net. A IN
dig +norecurse @62.219.128.128 ns1.bezeqint.net. A IN
dig +norecurse @192.115.132.132 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 ns3.bezeqint.net. A IN
dig +norecurse @192.115.132.132 ns2.bezeqint.net. A IN
dig +norecurse @62.219.128.128 ns1.bezeqint.net. A IN
dig +norecurse @212.179.7.7 e-services.clalit.co.il. A IN
dig +norecurse @212.179.7.7 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 ns3.bezeqint.net. A IN
dig +norecurse @212.179.7.7 ns2.bezeqint.net. A IN
dig +norecurse @62.219.128.128 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 e-services.clalit.co.il. A IN
dig +norecurse @62.219.128.128 e-services.clalit.co.il. A IN
dig +norecurse @62.219.128.128 e-services.clalit.co.il. A IN
dig +norecurse @192.115.132.132 e-services.clalit.co.il. A IN
dig +norecurse @62.219.128.128 ns3.bezeqint.net. A IN
dig +norecurse @192.115.132.132 ns2.bezeqint.net. A IN
dig +norecurse @212.179.7.7 e-services.clalit.co.il. A IN
dig +norecurse @128.139.34.240 e-services.clalit.co.il. A IN
module_event_noreply ---> no reply, timeout or other error
This one doesn't output anything in the log. I did change the verbosity to 5... there.
Microsoft Windows [Version 10.0.22631.2715]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Gil>nslookup -type=a ns3.bezeqint.net. 212.179.7.7
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 212.179.7.7
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
The above is because my PC is using the pihole as the DNS server.
So I changed my PC's DNS server to 1.1.1.1 and I still get the same thing:
C:\Users\Gil>ipconfig /all | findstr "DNS\ Servers"
DNS Servers : 1.1.1.1
C:\Users\Gil>nslookup -type=a ns3.bezeqint.net. 212.179.7.7
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 212.179.7.7
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
C:\User\Gil>
My eyes are hurting 
Could you post text instead of screenshot from now on pls?
Both those dig and nslookup commands dont involve unbound or Pi-hole in any way.
They try to connect to the authoritative DNS server 212.179.7.7 directly.
Below how it should look like:
pi@ph5a:~ $ dig +norecurse @212.179.7.7 ns3.bezeqint.net. A IN
; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> +norecurse @212.179.7.7 ns3.bezeqint.net. A IN
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2816
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 8831beecbfe0f561c717f29e655cfb93bef4f3de9a3f075a (good)
;; QUESTION SECTION:
;ns3.bezeqint.net. IN A
;; ANSWER SECTION:
ns3.bezeqint.net. 60 IN A 192.115.132.132
;; Query time: 86 msec
;; SERVER: 212.179.7.7#53(212.179.7.7)
;; WHEN: Tue Nov 21 19:48:51 CET 2023
;; MSG SIZE rcvd: 89
C:\>nslookup -type=a ns3.bezeqint.net. 212.179.7.7
Server: ns2.bezeqint.net
Address: 212.179.7.7
Name: ns3.bezeqint.net
Address: 192.115.132.132
Both not being able to connect indicates something is blocking/filtering traffic to this 212.179.7.7 IP.
Could be a router security setting of some sort.
Or being blocked at the ISP level.
For both I advice you to contact your ISP for support, tell them you want to run a recursive DNS server at home and show them both dig and nslookup results compared to mine.
And out of interest, could you post their answer pls?
EDIT: Oh and dont forget to lower verbosity to 0 and reload!
Client queries are already logged on Pi-hole when they use Pi-hole for DNS.
that green screen effect is from the really good sci-fi TV show Counterpart. I highly recommend it.
I can confirm that my ISP doesn't block it.
When I use AdGuard's DNS 94.140.14.14, 94.140.15.15 (or any DNS address for that matter) I can access e-services.clalit.co.il and also saas.attenix.co.il which is getting blocked when using Unbound.
The moment I use 127.0.0.1#5335 in Pihole's DNS settings, I get these issues. When I change to any other DNS, there is no issue. So clearly, not my ISP.
This is something in the Raspberry Pi's setting somewhere when Unbound is being used...
I wonder if my previous (last year) attempt to compile unbound 1.13.0 caused an issue.
Just for reference here's the guide I wrote to myself to compile it: pihole-blocklist/unbound/compile unbound.md at main · Gil80/pihole-blocklist (github.com)
How can you explain the nslookup failing on an entirely different OS and machine?
EDIT: Ps. Adguard isnt a recursive resolver like unbound.
Read up on the difference between a recursive resolver and a stub resolver!
EDIT2: Stub as in only sub/partial functionality compared to a full recursive resolver.
A stub is also often referred to as a caching DNS forwarder or DNS proxy.
I'll contact them tomorrow and see what they have to say.
By the way, my pihole server doesn't have a resolv.conf file. Is that normal?
I thought it would show what ever is set up in pihole to be the DNS.
pi@raspberrypi:~ $ cat /etc/resolv.conf
cat: /etc/resolv.conf: No such file or directory
pi@raspberrypi:~ $ systemd-resolve --status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
1 Like
Thats an entirely different issue and totally unrelated to Pi-hole.
Better suited to ask on the appropriate support channels like the Raspi forums!
Hint for figuring out who is in control of network settings (dont post here!):
sudo journalctl --full --no-pager --boot --grep eth0
I failed to explain properly...
-
If I just test using the
nslookup -type=a ns3.bezeqint.net. 212.179.7.7, it will fail and you are right to ask "How can you explain the nslookup failing on an entirely different OS and machine?" -
However, the actual site that I need access to is not blocked if I'm not using Unbound, and that's the point I was trying to make.
To clarify, given this address https://saas.attenix.co.il/ or e-services.clalit.co.il which is part of the full URL https://e-services.clalit.co.il/onlineweb/general/login.aspx?CustomUrlRiderect=/Services/Tamuz/TamuzTransfer.aspx
I can't access them (I get some DNS error) when using Unbound.
The moment I switch to 8.8.8.8 or some other DNS server, I can access these sites.
That's what led me to believe I somehow messed up with Unbound.
p.s. - I fixed the "my pihole server doesn't have a resolv.conf file."
They are two completely different DNS paths.
One (stub) is just forwarding queries.
And the other (unbound) is doing the hard work of actually resolving the queries ... recursively!
For unbound to work/recurse properly, all below ones need to reply:
1 Like
I think you need see if systemd-resolved is installed. I installed a clean lite version of 64-bit Pi OS Bookworm and it wasn't installed by default. You should have a /etc/systemd/resolved.conf file.
try:
sudo resolvectl
Note that I'm not using pihole on this particular Pi. Just Unbound. I edit the /etc/systemd/resolved.conf file and do a reboot and the /etc/resolv.conf file is generated. No setting of system links or anything. I think if I don't edit the /etc/systemd/resolved.conf file it will just use the system defaults and list them in the /etc/resolv.conf file after reboot.
Yes, that was the issue. I was able to correct by issuing these commands:
sudo systemctl start systemd-resolved
sudo systemctl enable systemd-resolved
systemd-resolve --status
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.