sudo -u unbound unbound-anchor -v -F
/var/lib/unbound/root.key has content
debug cert update forced
have 1 trusted certificates
resolve data.iana.org A: no result
resolve data.iana.org AAAA: no result
data.iana.org has no IP addresses I can use
sudo -u unbound unbound-anchor -v
/var/lib/unbound/root.key has content
fail: the anchor is NOT ok and could not be fixed
sudo -u unbound unbound-anchor -v -u 152.199.24.38
/var/lib/unbound/root.key has content
fail: the anchor is NOT ok and could not be fixed
BTW, I don't think this topic(auto-trust-anchor-file) is covered in the Pihole/Unbound documentation.
I only used the -F flag on unbound-anchor so you could see what it was doing. It should be able to update the root.key file w/o any of the other flags every 12 hours?(not sure).
If you 'cat' the root.key file you'll see the autotrust trust status and I think the updated dnskey/root.hints.
You can look at cat /lib/systemd/system/unbound.service
cat /usr/lib/unbound/package-helper
to see what happens @ boot.
This Unbound DNS tutorial might also help DNSWATCH Unbound DNS Tutorial
Near the end of the sample conf file they kind of explain the addition of the 'resolvconf_resolvers.conf' file in Raspian Bullseye.
Ok, thank you very much bigpcjuky this days i've got other thing more important to do, but when i have time and have re-charged up a little after like 4-5 days on the same problem, i'm gonna peacefully read and try to solve the problem.
After that, well.. i don't know. I'm kinda tired to use all my free time debugging this, so if it'ok ok, if not the mistery will remain unsolved.
After all it wasn't so stupid as it seemed at the beginning.
I think thanks to bigpcjunky, we've cornered your issue to be related to unbound not being able to validate its built-in root certificate.
It fails to do so because it cannot resolve data.iana.org to an IP address:
This might be caused by unbound requesting resolution via itself (via Pi-hole), which would require that same certificate to be already validated in order to succeed - a hen-and-egg kind of problem.
bigpcjunky trieed to steer you around this by suggesting to point your system to some other upstream DNS resolvers, and I tried the same by having unbound-anchor use an IP address, avoiding resolution of data.iana.org altogether.
Both of those approaches failed.
Directly requesting resiolution via public root servers works, so it doesn't seem that your router's firewall would block requests:
Let's see what your system running Pi-hole/unbound is really using for DNS.
Thanks for the recap. Much needed.
here are the outputs:
resolvconf -l
/usr/sbin/resolvconf: 7: /etc/resolvconf.conf: 1.1.1.1,: not found
# resolv.conf from eth0.dhcp
# Generated by dhcpcd from eth0.dhcp
nameserver 9.9.9.9,
nameserver 1.1.1.1,
nameserver 8.8.8.8;
# resolv.conf from eth0.dhcp6
# Generated by dhcpcd from eth0.dhcp6
search station
nameserver fe80::1614:59ff:fe97:a3e0%eth0
nameserver fe80::3594:58d5:2658:34d3%eth0
# resolv.conf from eth0.ra
# Generated by dhcpcd from eth0.ra
search station
nameserver fe80::1614:59ff:fe97:a3e0%eth0
nameserver fe80::3594:58d5:2658:34d3%eth0
# resolv.conf from wlan0.dhcp
# Generated by dhcpcd from wlan0.dhcp
domain station
search station
nameserver 192.168.1.1
nameserver 1.1.1.1
# resolv.conf from wlan0.dhcp6
# Generated by dhcpcd from wlan0.dhcp6
search station
nameserver fe80::1614:59ff:fe97:a3e0%wlan0
nameserver fe80::3594:58d5:2658:34d3%wlan0
# resolv.conf from wlan0.ra
# Generated by dhcpcd from wlan0.ra
search station
nameserver fe80::1614:59ff:fe97:a3e0%wlan0
nameserver fe80::3594:58d5:2658:34d3%wlan0
cat /etc/resolv.conf
# Generated by resolvconf
domain station
search station
nameserver 9.9.9.9
nameserver 1.1.1.1
nameserver 2606:4700:4700::1111
nameserver fe80::1614:59ff:fe97:a3e0%eth0
nameserver 2606:4700:4700::1112
nameserver fe80::1614:59ff:fe97:a3e0%wlan0
nameserver 192.168.1.1
dig data.iana.org
; <<>> DiG 9.16.33-Debian <<>> data.iana.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29726
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;data.iana.org. IN A
;; ANSWER SECTION:
data.iana.org. 3148 IN CNAME ianadata.vip.icann.org.
ianadata.vip.icann.org. 30 IN A 152.199.24.38
;; Query time: 211 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Thu Nov 17 22:56:49 CET 2022
;; MSG SIZE rcvd: 91
#!/bin/sh -e
UNBOUND_CONF="/etc/unbound/unbound.conf"
UNBOUND_BASE_DIR="$(dirname $UNBOUND_CONF)"
CHROOT_DIR="$(unbound-checkconf -o chroot)"
DNS_ROOT_KEY_FILE="/usr/share/dns/root.key"
ROOT_TRUST_ANCHOR_FILE="/var/lib/unbound/root.key"
# Override these variables by editing or creating /etc/default/unbound.
RESOLVCONF="true"
ROOT_TRUST_ANCHOR_UPDATE="true"
if [ -f /etc/default/unbound ]; then
. /etc/default/unbound
case "x$RESOLVCONF" in xfalse|x0|xno)
RESOLVCONF="false"
;;
esac
case "x$ROOT_TRUST_ANCHOR_UPDATE" in xfalse|x0|xno)
ROOT_TRUST_ANCHOR_UPDATE="false"
;;
esac
fi
do_resolvconf_start() {
if $RESOLVCONF; then
if [ -x /sbin/resolvconf ]; then
unbound-checkconf $CHROOT_DIR/$UNBOUND_CONF -o interface | (
default=yes
while read interface; do
default=no
if [ "x$interface" = x0.0.0.0 -o "x$interface" = x127.0.0.1 ]; then
echo "nameserver 127.0.0.1"
elif [ "x$interface" = x::0 -o "x$interface" = x::1 ]; then
echo "nameserver ::1"
fi
done
if [ $default = yes ]; then
# unbound defaults to listening on localhost
echo "nameserver 127.0.0.1"
fi
) | /sbin/resolvconf -a lo.unbound
fi
fi
}
do_resolvconf_stop() {
if $RESOLVCONF; then
if [ -x /sbin/resolvconf ]; then
/sbin/resolvconf -d lo.unbound
fi
fi
}
do_chroot_setup() {
if [ -d "$CHROOT_DIR" -a "$CHROOT_DIR" != "$UNBOUND_BASE_DIR" ]; then
rm -rf $CHROOT_DIR/$UNBOUND_BASE_DIR && mkdir -p $CHROOT_DIR/$UNBOUND_BASE_DIR
cd /
tar -cf - $(echo $UNBOUND_BASE_DIR | sed 's/^\///') | (cd $CHROOT_DIR && tar -xf -)
if [ -S "/run/systemd/notify" ]; then
mkdir -p "$CHROOT_DIR/run/systemd"
touch "$CHROOT_DIR/run/systemd/notify"
mount --bind "/run/systemd/notify" "$CHROOT_DIR/run/systemd/notify"
fi
fi
}
do_chroot_teardown() {
if [ -d "$CHROOT_DIR" ] && mountpoint -q "$CHROOT_DIR/run/systemd/notify"; then
umount "$CHROOT_DIR/run/systemd/notify"
fi
}
do_root_trust_anchor_update() {
if $ROOT_TRUST_ANCHOR_UPDATE; then
if [ -n "$ROOT_TRUST_ANCHOR_FILE" ]; then
if [ -r "$DNS_ROOT_KEY_FILE" ]; then
if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" -o "$DNS_ROOT_KEY_FILE" -nt "$ROOT_TRUST_ANCHOR_FILE" ]; then
if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" ]; then
echo "$ROOT_TRUST_ANCHOR_FILE does not exist, copying from $DNS_ROOT_KEY_FILE"
elif [ "$DNS_ROOT_KEY_FILE" -nt "$ROOT_TRUST_ANCHOR_FILE" ]; then
echo "Overwriting older file $ROOT_TRUST_ANCHOR_FILE with newer file $DNS_ROOT_KEY_FILE"
fi
install -m 0644 -o unbound -g unbound "$DNS_ROOT_KEY_FILE" "$ROOT_TRUST_ANCHOR_FILE"
fi
fi
fi
fi
}
case "$1" in
resolvconf_start)
do_resolvconf_start
;;
resolvconf_stop)
do_resolvconf_stop
;;
chroot_setup)
do_chroot_teardown
do_chroot_setup
;;
chroot_teardown)
do_chroot_teardown
;;
root_trust_anchor_update)
do_root_trust_anchor_update
;;
*)
echo "Usage: $0 {resolvconf_start|resolvconf_stop|chroot_setup|chroot_teardown|root_trust_anchor_update}" >&2
exit 1
;;
esac
So while unbound-anchor fails, dig on the same machine succeeds in resolving data.iana.org, and it has picked 9.9.9.9 for doing so.
The only thing that stands out is that liknk-local IPv6, probably belonging to your router?
If that wouild be true, you want to investigate your router settings - though it may not necessarily be involved here, it would alloow IPv6 clients to by-pass PI-hole.
Now, if unbound-anchor would prefer an IPv6 nameserver, it may opt for that link-local.
Let's see what that would return - what's the output of:
Hi guys,
I've been away for work as i said before and now in italy there is what it seems to be like the usual pre-covid flu epidemic where there is like 2/3 of the staff ill and the rest of us has triple work to do. Still i didn't forgot about this problem and your kind help but i must say that after setting unbound up with DoT + pi-hole + VPN i had 0 problem at all and remembering the stubborness and downthehole-ness type of reaction that this problem caused me makes me wonder if i really should open this chapter again.
Before going away last time i decided that as i was still fresh in linux terminal it would have been a good idea to have a total different image completely clean in another sdcard i had around so i did just that and it took me less than a day to setup.
This means that i still have the original sd card that we debugged together here, but after what i tried even in the new sdcard (below) i believe it could be best to just start fresh in the future 'cause maybe the problem it's not in there. Now, to explain:
Even if i did not answer i tried
with no resolution of the problem.
I tried the post before too with the same result.
After that I was exhausted and i decided to give it just one last, desperate, shot.
I went to the official unbound site and i saw the repository was behind lots of versions. So i deleted all the folders that i had messed up with and compiled the last version of unbound ( .19 i believe ) hoping that it would solve the problem. It didn't. Well, it was a mess, with different configuration folders and files in places i've never seen before. Still i downloaded the official manual and tried to make it work but after another night wasted i quit.
When i set up the new sd, unbound DoT was the target. Still, as it was an empty image i had to try to follow the official guide again and see if, with nothing messed up it would work.
And.... It didn't. I assured the time was right ( forgot to run timedatectl, just checked in raspi-config and watched my Apple watch just in case ) and all the configuration was default.
After that i decided to give up and configure DoT leaving the problem to a future me.
I'm gonna have the recursive DNS one day but i guess that day it's not today.
I will look at this post from time to time just out of curiosity and maybe some day and when the unbound package will get an update through repository i will come bite you in the arse again with a new post... but i hope not!!
I thank you all again for your time and patience, @Bucking_Horn you most of all, i didn't think there was someone so patient and caring, i hope to find you here if i'd need help again.
Much love and respect,
I used chat GPT3 to try figure out / fix the issue to no success and I'm giving up for now working 2 days on this rediculous issue. would love to use unbound though.
FYI
Thank you for providing the test results. It seems that the root DNS server at 192.112.36.4 did not respond to the ping requests, which might explain why Unbound encountered an issue when querying this server.
However, changing the upstream DNS server to Google Public DNS (8.8.8.8) has allowed Unbound to successfully resolve the crosstalksolutions.com domain name. The query returned a valid A record (IP address) for crosstalksolutions.com (IP: 34.149.36.179), indicating that DNS resolution is working correctly with the new upstream DNS server.
This outcome suggests that the issue might be related to the response from the root DNS server at 192.112.36.4. It is not uncommon to experience occasional connectivity issues or timeouts when querying root DNS servers, as they receive a massive amount of DNS traffic globally.
Since changing the upstream DNS server resolved the issue, you might consider continuing to use Google Public DNS (8.8.8.8) or another reliable DNS resolver as the upstream DNS server in your Pi-hole configuration.
would love to use unbound though.