The following log message would only sporadically be logged on my Pi-hole. Not every hour, and not even every day. Just... sometimes. When the stars aligned... When, 52 years ago, Monday fell on a full moon and a 12th-generation carpenter was born... You get the idea. 😄
The error message was:
"No valid NTP replies received, check server and network connectivity"
Strange. NTP works. Despite Pi-hole sometimes fancy otherwise.
Inspecting the Pi-hole configuration
pihole-FTL returned the following NTP configuration:
user@host:~$ pihole-FTL --config ntp
ntp.ipv4.active = true
ntp.ipv4.address =
ntp.ipv6.active = true
ntp.ipv6.address =
ntp.sync.active = true
ntp.sync.server = 1.de.pool.ntp.org
ntp.sync.interval = 3600
ntp.sync.count = 8
ntp.sync.rtc.set = false
ntp.sync.rtc.device =
ntp.sync.rtc.utc = true
That looked good to me.
It was here that I had my suspicions: Wait, does the NTP Pool Project already offer IPv6? I have never knowingly used public NTP pools with IPv6. In customer networks, NTP servers are usually only reachable via IPv4. I don't have an NTP server in my home network. Sadly, many services are still not IPv6 ready.
Some companies even remove IPv6 support, like DigiCert (a commercial certificate authority!), who removed IPv6 support when they switched to a new CDN provider. This left me speechless. Read https://knowledge.digicert.com/alerts/digicert-certificate-status-ip-address if you want to know more.
NTP & IPv6? Only with pools that start with a 2
A short search for IPv6 support in NTP-Pools and https://www.ntppool.org/en/use.html provided the answer:
Please also note that the system currently only provides IPv6 addresses for a zone in addition to IPv4 addresses if the zone name is prefixed by the number 2, e.g. 2.pool.ntp.org (provided there are any IPv6 NTP servers in the respective zone). Zone names not prefixed by a number, or prefixed with any of 0, 1 or 3, currently provide IPv4 addresses only.
It turns out that the problem lies in my dual-stack setup, since I use IPv4 and IPv6 in parallel. Or rather... It's with the NTP pools. I checked with dig to see if any AAAA records were returned for 1.de.pool.ntp.org. The pool I was using.
dig aaaa 1.de.pool.ntp.org returns no AAAA-Records.
user@host:~$ dig aaaa 1.de.pool.ntp.org
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> aaaa 1.de.pool.ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43230
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
;; QUESTION SECTION:
;1.de.pool.ntp.org. IN AAAA
;; AUTHORITY SECTION:
pool.ntp.org. 0 IN SOA d.ntpns.org. hostmaster.pool.ntp.org. 1749216969 5400 5400 1209600 3600
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Jun 06 16:10:31 CEST 2025
;; MSG SIZE rcvd: 134
And surely enough a dig aaaa 2.de.pool.ntp.org returns AAAA-Records.
user@host:~$ dig aaaa 2.de.pool.ntp.org
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> aaaa 2.de.pool.ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47906
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;2.de.pool.ntp.org. IN AAAA
;; ANSWER SECTION:
2.de.pool.ntp.org. 130 IN AAAA 2a0f:85c1:b73:62:123:123:123:123
2.de.pool.ntp.org. 130 IN AAAA 2a01:239:2a6:d500::1
2.de.pool.ntp.org. 130 IN AAAA 2606:4700:f1::1
2.de.pool.ntp.org. 130 IN AAAA 2a01:4f8:141:282::5:1
;; Query time: 656 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Jun 06 16:33:32 CEST 2025
;; MSG SIZE rcvd: 158
My new Pi-hole configuration
The fix was easy, just configure 2.de.pool.ntp.org instead of 1.de.pool.ntp.org. Done.
user@host:~$ pihole-FTL --config ntp
ntp.ipv4.active = true
ntp.ipv4.address =
ntp.ipv6.active = true
ntp.ipv6.address =
ntp.sync.active = true
ntp.sync.server = 2.de.pool.ntp.org
ntp.sync.interval = 3600
ntp.sync.count = 8
ntp.sync.rtc.set = false
ntp.sync.rtc.device =
ntp.sync.rtc.utc = true
Now my Pi-hole instances aren't running long enough to really verify that the error is gone but I suspect so.