Here is the permanent fix for your unbound configuration change (you have only done part of this):
/etc/resolvconf.conf and comment out the last line which should read:unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
sudo service unbound restart
Plus you'll notice that if you disable and stop that unbound-resolvconf.service unit with below:
sudo systemctl disable --now unbound-resolvconf.service
And restart the dhcpcd.service unit:
sudo systemctl restart dhcpcd.service
The /etc/resolv.conf file will be populated with the DNS nameserver(s) you defined in the /etc/dhcpcd.conf file instead of the loopback IP 127.0.0.1:
pi@ph5b:~ $ systemctl status unbound-resolvconf.service
● unbound-resolvconf.service - Unbound DNS server via resolvconf
Loaded: loaded (/lib/systemd/system/unbound-resolvconf.service; disabled; vendor preset: enabled)
Active: inactive (dead)
pi@ph5b:~ $ cat /etc/dhcpcd.conf
[..]
static domain_name_servers=10.0.0.1
pi@ph5b:~ $ cat /etc/resolv.conf
[..]
nameserver 10.0.0.1
EDIT: Those two packages, unbound and openresolv, try hard to break unbound's recursion and mess up resolv.conf 
Many thanks for your help!
I have done both (comment out the line, deleted the unwanted file, restarted unbound + disabled the service).
Last night at around 3am the pihole reduced itself to querying the time server about every 30 minutes. No idea why! 
The other raspberry pi in my network (printerserver) did not change its frequency of once every 2 minutes.
The last ~50 minutes I have not seen another time server query from my pihole, the other raspberry pi keeps querying every 2 minutes.
So my problem is partially resolved.
I would like to use unbound and not the OpenDNS servers that are now listed in /etc/dhcpcd.conf and /etc/resolv.conf. Do I just change the addresses below into 127.0.0.1#5335 in /etc/dhcpcd.conf, however this was called a "loopback IP"?
# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface eth0
static ip_address=192.168.1.150/24
static routers=192.168.1.1
static domain_name_servers=208.67.222.222 208.67.220.220
I would advice against that.
These domain_name_servers that end up in resolv.conf are used by local processes running on the Pi-hole host and are independent from what you've configured as upstream DNS servers in the Pi-hole settings.
Meaning if you loopback queries for them back to Pi-hole, you wouldn't have DNS when you mess up Pi-hole again tweaking etc
This is disadvantageous if you lose DNS while troubleshooting.
I have my router IP configured.
But you could also opt to enter your ISP DNS servers or whatever other external DNS provider you prefer.
Also you cant define a port (#5335 or whatever) in dhcpcd.conf and is also not valid in resolv.conf.
I am starting to understand these systems now (slightly)
Two things puzzle me though. First, why I am starting to have this issue when I enable IPv6? All was good when I was using IPv4.
Second, why does my other raspberry pi (cups printerserver) in my network still have the issue? It has no unbound installed. Is there anything that I can do about this?
I would love to know more about this!
It might have to do with the IPv6 GUA prefix changing by your ISP upstream which comes from your router via "router advertisement" or short RA:
Which in turn triggers a series of events which does not happen with IPv4.
Below posting hints to RA ... and the thread is full of related info:
EDIT:
Have you tried a good old trusty reboot?
Thanks for the information, I will check it out!
I tried restarting all systems, no improvement..
With journalctl -u systemd-timesyncd.service I checked the pihole and the other raspberry pi in my network, both still seem to successfully sync the time ~2 minutes for some time already. It seems that because I enabled IPv6 on my router and pihole, the NTP sync queries became visible in the pihole query log.
Somehow currently the pihole time sync is not included in the pihole query log anymore after the actions mentioned in one of the previous posts.
I will look into limiting the sync process as suggested earlier in this thread.
Some pointers concerning systemd-timesyncd.service that comes default with Pi-OS/Raspbian.
You already figured out to list the systemd logs:
journalctl --full --no-pager -u systemd-timesyncd.service
Below one shows time/date and if NTP is active and syncing:
pi@ph5b:~ $ timedatectl
Local time: Fri 2022-06-10 19:35:14 CEST
Universal time: Fri 2022-06-10 17:35:14 UTC
RTC time: n/a
Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Below one shows details about the syncing:
pi@ph5b:~ $ timedatectl timesync-status
Server: 185.216.161.42 (0.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 1
Reference: GPS
Precision: 2us (-19)
Root distance: 45us (max: 5s)
Offset: -2.118ms
Delay: 17.115ms
Jitter: 2.938ms
Packet count: 2654
Frequency: -17.507ppm
Am not sure but from above it looks like systemd-timesyncd is suppose to poll every 34 minutes when successful and goes down to 32 seconds when it fails syncing.
Maybe someone else can confirm or debunk?
Or if you want to monitor:
timedatectl --monitor timesync-status
If install ntpdate:
pi@ph5b:~ $ sudo apt install ntpdate
[..]
After this operation, 234 kB of additional disk space will be used.
You can manually test connectivity with NTP server IP's or DNS pool names:
pi@ph5b:~ $ ntpdate -q 0.debian.pool.ntp.org
server 162.159.200.123, stratum 3, offset -0.004728, delay 0.05746
server 45.85.15.35, stratum 2, offset -0.002805, delay 0.03673
server 5.79.108.34, stratum 2, offset -0.003996, delay 0.03769
server 188.165.11.86, stratum 2, offset -0.004380, delay 0.04564
10 Jun 19:46:18 ntpdate[6372]: adjust time server 45.85.15.35 offset -0.002805 sec
Above is also a good test to see if the 0.debian.pool.ntp.org name resolves to IP's properly on the host itself (IP's in the pool are a bit dynamic):
pi@ph5b:~ $ dig +short 0.debian.pool.ntp.org a
188.165.11.86
162.159.200.123
45.85.15.35
5.79.108.34
Yeah I waited a good 15 minutes and --monitor now shows differrent stats as before (EDIT: and Packet count went up by one):
pi@ph5b:~ $ timedatectl --monitor timesync-status
Server: 185.216.161.42 (0.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 1
Reference: GPS
Precision: 2us (-19)
Root distance: 45us (max: 5s)
Offset: -3.340ms
Delay: 22.399ms
Jitter: 3.365ms
Packet count: 2655
Frequency: -18.322ppm
The details about the sync helped!
My Raspberry Pi's each have a poll interval of 2min 8s, sometimes it switches to 1min 4s.
Both Raspberry's seems to resolve the IP addresses properly.
My poll interval's are frequent but the time is correct so I will leave it at that.
What I do not understand is that the NTP queries of the Raspberry on which the Pihole is installed are not included in the pihole query log and the NTP queries of the other raspberry pi in my network are included.
Check if below OOTB defaults have been changed:
pi@ph5b:~ $ cat /etc/systemd/timesyncd.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.
[Time]
#NTP=
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048
The hashed out lines with directives are the defaults (note above two last lines!):
pi@ph5b:~ $ man timesyncd.conf
[..]
PollIntervalMinSec=, PollIntervalMaxSec=
The minimum and maximum poll intervals for NTP messages. Each
setting takes a time value (in seconds). PollIntervalMinSec=
must not be smaller than 16 seconds. PollIntervalMaxSec=
must be larger than PollIntervalMinSec=. PollIntervalMinSec=
defaults to 32 seconds, and PollIntervalMaxSec= defaults to
2048 seconds.
If thats not it, I'm outa ideas and know too little about what influences the pol frequency.
I would suggest to post a support question on the Raspbian/Pi-hole Raspberry Pi forums as this does not appear to be a Pi-hole issue.
EDIT: And if get to a solution, could you feedback here pls?
Thats because local processes including systemd-timesyncd use the DNS nameserver(s) defined in resolv.conf:
Check /etc/resolv.conf on respective hosts!
The default settings on both raspberry's have not changed. I will not investigate this any further. The poll interval is frequent but the times are correct so essentially there is no problem.
It makes sense that the pihole is not using itself 
/etc/resolv.conf contains an IPv6 DNS address of my internet service provider. This address is passed on to the other raspberry pi as well. I can comment it out, it however is uncommented after a reboot. Can I somehow block the address elsewhere?
For Pi-OS/Raspbian, the default network manager is called dhcpcd and is responsible for what ends up in resolv.conf.
If the host is configured to acquire IP details automatically via DHCP, dhcpcd will configure the nameserver(s) in resolv.conf that are advertised via DHCP.
You can see/check those if run below (10.0.0.2 & 10.0.0.4 are both running Pi-hole):
pi@ph5b:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
dns-server: 10.0.0.2
dns-server: 10.0.0.4
If instead have configured static IP details on the host like below:
pi@ph5b:~ $ tail /etc/dhcpcd.conf
[..]
interface eth0
static ip_address=10.0.0.4/24
static routers=10.0.0.1
static domain_name=home.dehakkelaar.nl
static domain_name_servers=10.0.0.1
The domain_name_servers= values will end up in resolv.conf.
In addition to that, if IPv6 is supported and enabled on your router for your LAN , clients normally also receive DNS server(s) via IPv6 router advertisement(RA).
So make sure your router is advertising Pi-hole's IPv6 ULA address for DNS!
Am not that familiar with diagnosing IPv6 RA DNS because I dont have IPv6 enabled on my LAN.
But you could check on clients what DNS server IP's are configured.
Below some hints:
I have as well configured static DNS addresses in /etc/dhcpcd.conf, these are visible too in resolv.conf.
Interestingly I got an error, I am not sure if it matters:
pi@PiHole:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds
WARN: Could not sendto() in send_dhcp_discover() (/__w/FTL/FTL/src/dhcp-discover.c:233): Network is unreachable
* Received 300 bytes from eth0:192.168.1.150
Offered IP address: 192.168.1.98
Server IP address: 192.168.1.150
Relay-agent IP address: N/A
BOOTP server: (empty)
BOOTP file: (empty)
DHCP options:
Message type: DHCPOFFER (2)
server-identifier: 192.168.1.150
lease-time: 86400 ( 1d )
renewal-time: 43200 ( 12h )
rebinding-time: 75600 ( 21h )
netmask: 255.255.255.0
broadcast: 192.168.1.255
dns-server: 192.168.1.150
domain-name: "lan"
router: 192.168.1.1
--- end of options ---
DHCP packets received on interface wlan0: 0
DHCP packets received on interface lo: 0
DHCP packets received on interface eth0: 1
As far as I understand things right now, my Vodafone Station is pushing the vodafone DNS through RA. I cannot change this.
On my Asus router I have enabled IPv6 passthrough and disabled automatic DNS server connection. Instead I have configured the local ´fe80´ IPv6 pihole address. This last one is not being picked up.
I will disable IPv6 for some time and assess if there are strong enough reasons to enable it again like e.g. performance.
Many thanks for your help @deHakkelaar !
Non-technical advice, I recommwnd picking a debian pool out of the four, and blacklist the other three. I assume there are four for extra network use, debian forums probably knows. zI allow pool 0 for the ntp and packages.
Any reason why you would do that?
You dont have to blacklist anything if you configure below file to use only one of the pool names:
Hey that's cool!
Why?
pi@ph5b:~ $ date; dig +short a 0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org | sort -n
Tue 12 Jul 20:29:28 CEST 2022
5.135.158.34
5.39.184.5
5.79.108.34
45.85.15.40
46.243.26.34
81.169.204.140
83.137.149.135
94.198.159.15
95.85.21.89
149.210.142.45
158.69.20.38
162.159.200.1
164.92.216.152
185.224.145.68
185.35.202.197
213.109.127.82
pi@ph5b:~ $ date; dig +short a 0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org | sort -n
Tue 12 Jul 20:30:21 CEST 2022
23.94.217.117
46.249.42.12
78.142.193.131
78.47.93.191
83.137.149.135
93.94.224.67
93.94.224.67
95.81.173.74
162.159.200.123
178.215.228.24
178.62.16.103
185.51.192.34
188.165.11.86
193.182.111.143
213.136.0.252
213.239.154.12
EDIT: To make matters even worse, it appears only one pool holds IPv6 addresses for if you have IPv6 support upstream from your ISP:
pi@ph5b:~ $ date; dig +short aaaa 2.debian.pool.ntp.org
Tue 12 Jul 21:00:26 CEST 2022
2603:c022:c003:c900::4
2a03:10c3:480::123
2a01:1b1:1::36
2606:4700:f1::1
Vs:
pi@ph5b:~ $ date; dig +short aaaa 0.debian.pool.ntp.org
Tue 12 Jul 21:00:16 CEST 2022
So if exlude that one, you wont have the benefits of syncing over IPv6 also.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.