Hello,
recently I have a strange behaviour.
All couple of seconds the pi-hole system is sending requests to ntp servers. In the pihole.log it appears like this:
Apr 24 00:00:16 dnsmasq[806]: query[A] nl.pool.ntp.org from 172.26.0.1
Apr 24 00:00:16 dnsmasq[806]: cached nl.pool.ntp.org is 83.98.155.30
Apr 24 00:00:16 dnsmasq[806]: cached nl.pool.ntp.org is 5.79.108.34
Apr 24 00:00:16 dnsmasq[806]: cached nl.pool.ntp.org is 172.107.94.157
Apr 24 00:00:16 dnsmasq[806]: cached nl.pool.ntp.org is 136.144.152.8
Apr 24 00:00:16 dnsmasq[806]: query[A] 0.nl.pool.ntp.org from 172.26.0.1
Apr 24 00:00:16 dnsmasq[806]: cached 0.nl.pool.ntp.org is 108.61.164.200
Apr 24 00:00:16 dnsmasq[806]: cached 0.nl.pool.ntp.org is 84.245.9.254
Apr 24 00:00:16 dnsmasq[806]: cached 0.nl.pool.ntp.org is 37.97.195.195
Apr 24 00:00:16 dnsmasq[806]: cached 0.nl.pool.ntp.org is 162.159.200.123
Pi-hole runs as a docker image on a Raspberry PI4. Everything is upgraded to latest versions - both the raspbian system and the pi-hole docker image.
I can't say since when I have this behaviour. So I can't link it to a particular change I have made. Certainly it didn't behave like this before.
I found some hints in the Internet, but none did much my setting.
I already stopped all other applications (containers) on the Raspberry Pi to make sure the NTP requests don't come from another program. But they are still there and they seem to come from the virtual IP address of the pi-hole system.
172.26.0.1 looks a lot like Docker's internal gateway address for its default internal bridge network, with containers connected to it being allocated 172.26.0.2 through 172.26.0.254.
Any request from outside of Docker's internal subnet wil be NATed through that address, so you really can't derive the source by looking at that IP - any client in your network may have sent those requests, including the host system that Docker runs on.
As RPis are lacking a battery-backuped RTC, it would be common that their OS is configured for syncing time with an NTP server, which would make it likely that those requests are indeed issued by the OS of the system that runs Docker.
Raspberry Pi OS e.g. would read a last known time from a file created by fake-hwclock early upon booting, and it would then try to sync with NTP servers (as configurable by /etc/systemd/timesyncd.conf).
As we can see from the logs you've provided, Pi-hole correctly resolves the requested NTP server domains to IP addresses, i.e. Pi-hole is not blocking them.
If the host OS would be configured to use Pi-hole for DNS, those requests may have just have piled up in the time span during system boot and final availability of your Pi-hole container.
If my guess would be correct, you could consider to provide a separate DNS server instead of or in addition to Pi-hole for your OS running Docker, in order to avoid those requests from piling up during boot.
Alternatively, you could also consider to edit timesyncd.conf to point to your router's IP, which may avoid DNS lookups for time-syncs - provided your router can be configured to act as a local time server.
But if the OS would be continuing to request NTP server domains nonetheless, it may not be able to set the current time. This could happen if the gap between your system time and the NTP server time would be too large.
In that case, you may have to manually set the system time, e.g. by running