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. [ When digging 127.0.0.1#5353 ! should not recieve an error reply...]
_[Unbound is playing tricks on me. I always recieve this error when digging:@127.0.0.1 -p 5335
;; OPT PSEUDOSECTION:
;; Query time: 215 msec
I know I configured unbound properly. I tried using 127.0.0.1#5353 as dns and its working. What's up with this error? Or maybe I'm just not able to read this result?]_
[ https://tricorder.pi-hole.net/LEKpjsHE/ ]
jfb
April 12, 2024, 5:40pm
3
I don't think this is the case. Your unbound instance is operating on port 5335, not 5353:
*** [ DIAGNOSING ]: Ports in use
udp:127.0.0.1:5335 is in use by unbound
Your debug log shows that earlier in the day, you were using this port and receiving no replies:
Apr 13 00:00:05 dnsmasq[9201]: forwarded . to 127.0.0.1#5353
Apr 13 00:00:05 dnsmasq[9201]: query[PTR] 9.9.9.9.in-addr.arpa from 127.0.0.1
Apr 13 00:00:05 dnsmasq[9201]: forwarded 9.9.9.9.in-addr.arpa to 127.0.0.1#5353
Apr 13 00:00:05 dnsmasq[9201]: query[A] services-bingapis-com.e-0001.e-msedge.net from 192.168.80.253
Apr 13 00:00:05 dnsmasq[9201]: forwarded services-bingapis-com.e-0001.e-msedge.net to 127.0.0.1#5353
Apr 13 00:00:08 dnsmasq[9201]: query[NS] . from 192.168.80.253
Apr 13 00:00:08 dnsmasq[9201]: forwarded . to 127.0.0.1#5353
But, later the port was changed to 5335 and replies were received from unbound:
-----tail of pihole.log------
Apr 13 00:43:13 dnsmasq[15573]: forwarded dual-s-ring.msedge.net to 127.0.0.1#5335
Apr 13 00:43:13 dnsmasq[15573]: reply dual-s-ring.msedge.net is <CNAME>
Apr 13 00:43:13 dnsmasq[15573]: reply s-ring.dual-s-9999.dual-s-msedge.net is <CNAME>
Apr 13 00:43:13 dnsmasq[15573]: reply dual-s-9999.dual-s-msedge.net is 52.123.129.254
Apr 13 00:43:13 dnsmasq[15573]: reply dual-s-9999.dual-s-msedge.net is 52.123.128.254
Apr 13 00:43:13 dnsmasq[15573]: query[A] s-ring.dual-s-9999.dual-s-msedge.net from 192.168.80.253
Apr 13 00:43:13 dnsmasq[15573]: forwarded s-ring.dual-s-9999.dual-s-msedge.net to 127.0.0.1#5335
Apr 13 00:43:13 dnsmasq[15573]: reply s-ring.dual-s-9999.dual-s-msedge.net is <CNAME>
Apr 13 00:43:13 dnsmasq[15573]: reply dual-s-9999.dual-s-msedge.net is 52.123.129.254
Apr 13 00:43:13 dnsmasq[15573]: reply dual-s-9999.dual-s-msedge.net is 52.123.128.254
This indicates that (at least at that time) unbound was responding to queries.
Let's take a look at two potential causes of unbound errors.
Is the date/time on the Pi correct and matches your local time?
date
Please post the output of the following command from the Pi terminal:
sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*
1 Like
Here's the output:
Thank you. I noticed my error earlier and changed the port and rerun debug and resent it again. Sorry for the confusion. Btw, the dig output looking great now I guess I'm just sleepy at that time. Human error😂.
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> pi-hole.net @127.0.0.1 -p 5335
;; OPT PSEUDOSECTION:
;; ANSWER SECTION:
;; Query time: 47 msec
That output shows that you have duplicated your configuration file, potentially being applied unintentionally..save file, or move it to a different location.
Complementing the answer:
The .save file extension is usually used for "auto-saved" files when nano (or possibly another text editor) is forced to close before save the file.
From nano manual, section Notes :
In some cases nano will try to dump the buffer into an emergency file. This will happen mainly if nano receives a SIGHUP or SIGTERM or runs out of memory. It will write the buffer into a file named nano.save if the buffer didn’t have a name already, or will add a .save suffix to the current filename. If an emergency file with that name already exists in the current directory, it will add .save plus a number (e.g. .save.1) to the current filename in order to make it unique. In multibuffer mode, nano will write all the open buffers to their respective emergency files.
This file was probably created unintentionally, as suggested above.