Pi-hole NTP server failing as it is using outdated IPv6 addresses

Help
1

The NTP server is using outdated IPv6 addresses when synchronising, instead of the addresses being returned by Pi-hole.

From the pihole log:

Oct 29 20:55:56 query[A] 2.au.pool.ntp.org from 127.0.0.1
Oct 29 20:55:56 forwarded 2.au.pool.ntp.org to ::1#5335
Oct 29 20:55:56 query[AAAA] 2.au.pool.ntp.org from 127.0.0.1
Oct 29 20:55:56 forwarded 2.au.pool.ntp.org to ::1#5335
Oct 29 20:55:58 reply 2.au.pool.ntp.org is 202.142.133.141
Oct 29 20:55:58 reply 2.au.pool.ntp.org is 162.159.200.1
Oct 29 20:55:58 reply 2.au.pool.ntp.org is 168.138.12.93
Oct 29 20:55:58 reply 2.au.pool.ntp.org is 103.249.238.208

Notice the lack of an IPv6 address. Yet:

From the FTL log:

All FTL errors are Failed to receive data from NTP server 2.au.pool.ntp.org. NTP server 2.au.pool.ntp.org was removed to improve the formatting.

2026-10-29 20:56:01.913 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:07.033 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:12.153 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:17.273 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:22.393 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:27.513 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:32.633 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:37.753 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:37.755 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity

The last time 2403:5807:a51a:2011:5449:434b:544f:434b1 was returned was:

Oct 29 12:52:59 reply 2.au.pool.ntp.org is 2403:5807:a51a:2011:5449:434b:544f:434b

And the result is:

2026-10-29 00:56:29.818 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 01:56:29.948 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 03:56:30.459 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 05:56:30.971 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 10:56:33.658 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 12:56:35.194 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 13:56:35.322 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 14:56:35.451 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 15:56:35.579 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 19:56:36.603 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity
2026-10-29 20:56:37.755 WARNING Warning NTP client: No valid NTP replies received, check server and network connectivity

The times that NTP used each IPv6 address today and the pihole log entries for those IPv6 addresses:

2026-10-29 00:55:53.977 ERROR Failed to receive data from (2402:9e80:1::1:88ba): Timeout
2026-10-29 01:55:54.105 ERROR Failed to receive data from (2402:9e80:1::1:88ba): Timeout

Oct 29 03:52:55 reply 2.au.pool.ntp.org is 2402:9e80:1::1:88ba
Oct 29 12:52:59 reply 2.au.pool.ntp.org is 2402:9e80:1::1:88ba


2026-10-29 03:55:54.617 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 12:55:59.353 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout
2026-10-29 20:56:01.913 ERROR Failed to receive data from (2403:5807:a51a:2011:5449:434b:544f:434b): Timeout

Oct 29 07:52:57 reply 2.au.pool.ntp.org is 2403:5807:a51a:2011:5449:434b:544f:434b
Oct 29 09:55:53 reply 2.au.pool.ntp.org is 2403:5807:a51a:2011:5449:434b:544f:434b
Oct 29 12:52:59 reply 2.au.pool.ntp.org is 2403:5807:a51a:2011:5449:434b:544f:434b


2026-10-29 05:55:55.129 ERROR Failed to receive data from (2403:580c:ffff:808e:d329:945c:2014:8e4f): Timeout
2026-10-29 10:55:57.821 ERROR Failed to receive data from (2403:580c:ffff:808e:d329:945c:2014:8e4f): Timeout
2026-10-29 13:55:59.481 ERROR Failed to receive data from (2403:580c:ffff:808e:d329:945c:2014:8e4f): Timeout
2026-10-29 15:55:59.737 ERROR Failed to receive data from (2403:580c:ffff:808e:d329:945c:2014:8e4f): Timeout
2026-10-29 19:56:00.761 ERROR Failed to receive data from (2403:580c:ffff:808e:d329:945c:2014:8e4f): Timeout

Oct 29 05:55:51 reply 2.au.pool.ntp.org is 2403:580c:ffff:808e:d329:945c:2014:8e4f
Oct 29 10:52:58 reply 2.au.pool.ntp.org is 2403:580c:ffff:808e:d329:945c:2014:8e4f


2026-10-29 14:55:59.609 ERROR Failed to receive data from (2401:c080:1800:499c::1:123): Timeout

Oct 29 09:55:53 reply 2.au.pool.ntp.org is 2401:c080:1800:499c::1:123
Oct 29 12:52:59 reply 2.au.pool.ntp.org is 2401:c080:1800:499c::1:123


2026-10-29 14:55:59.609 ERROR Failed to receive data from (2401:c080:1800:499c::1:123): Timeout

Oct 29 09:55:53 reply 2.au.pool.ntp.org is 2401:c080:1800:499c::1:123
Oct 29 12:52:59 reply 2.au.pool.ntp.org is 2401:c080:1800:499c::1:123

One can see there is a very weak correlation between when the Pi-hole returned an IPv6 address, and when NTP synchronisation attempted to use it.

And before anyone says cache, I use Unbound and dns.cache.size = 0.

2

That log excerpt seems incomplete.
It lacks the upstream AAAA reply entirely. Could you check your log for a corresponding reply?

If there were indeed no IPv6 addresses for 2.au.pool.ntp.org, there should be a line like reply 2.au.pool.ntp.org is NODATA-IPv6.
The actual reply may be several seconds down the log.

2.au.pool.ntp.org is the only one out of Australia's 4 NTP pool domains that serves IPv6 addresses , and it currently holds 80+ such active IPs.
The NTP pool will pick only 4 out of those active IPs as a DNS reply on a regular basis.

That doesn't mean that an IPv6 that isn't returned by a DNS request wouldn't answer to NTP requests, though - e.g. I was able to get time info from 2403:5807:a51a:2011:5449:434b:544f:434b just now, despite that address not being currently returned for me by a respective DNS request.

This would increase the likelihood of an actual timeout issue from the NTP server, as even if outdated IPv6 address replies were being used here, there still should be an NTP reply.

But as suggested, let's first find out about your unbound's actual reply for those AAAA requests. Perhaps they already contain a clue to what's actually happening.

3

reply 2.au.pool.ntp.org is NODATA-IPv6 isn't there.

Oct 29 20:55:56 query[A] 2.au.pool.ntp.org from 127.0.0.1
Oct 29 20:55:56 forwarded 2.au.pool.ntp.org to ::1#5335
Oct 29 20:55:56 query[AAAA] 2.au.pool.ntp.org from 127.0.0.1
Oct 29 20:55:56 forwarded 2.au.pool.ntp.org to ::1#5335
Oct 29 20:55:58 reply 2.au.pool.ntp.org is 202.142.133.141
Oct 29 20:55:58 reply 2.au.pool.ntp.org is 162.159.200.1
Oct 29 20:55:58 reply 2.au.pool.ntp.org is 168.138.12.93
Oct 29 20:55:58 reply 2.au.pool.ntp.org is 103.249.238.208
Oct 29 20:56:06 query[A] pool.ntp.org from 192.168.xxx.xxx
Oct 29 20:56:06 forwarded pool.ntp.org to ::1#5335
Oct 29 20:56:06 query[AAAA] pool.ntp.org from 192.168.xxx.xxx
Oct 29 20:56:06 forwarded pool.ntp.org to ::1#5335
Oct 29 20:56:06 reply pool.ntp.org is 162.159.200.123
Oct 29 20:56:06 reply pool.ntp.org is 103.249.238.208
Oct 29 20:56:06 reply pool.ntp.org is 44.32.200.120
Oct 29 20:56:06 reply pool.ntp.org is 103.252.195.117
Oct 29 20:56:06 reply pool.ntp.org is NODATA-IPv6

sudo zgrep 'pool.ntp.org is NODATA-IPv6' /var/log/pihole/pihole.log.3.gz
Oct 29 20:38:01 reply 1.au.pool.ntp.org is NODATA-IPv6
Oct 29 20:55:52 reply pool.ntp.org is NODATA-IPv6
Oct 29 20:56:06 reply pool.ntp.org is NODATA-IPv6
Oct 29 20:56:24 reply pool.ntp.org is NODATA-IPv6
Oct 29 20:56:44 reply pool.ntp.org is NODATA-IPv6
Oct 29 20:57:04 reply pool.ntp.org is NODATA-IPv6
Oct 29 20:57:24 reply pool.ntp.org is NODATA-IPv6

How did you work out that "it currently holds 80+ such active IPs"?

4

As a test, temporarily replace Unbound with a public DNS server and try again. This will remove any possible Unbound issues from the equation.

5

One test, using Quad9 (filtered, ECS, DNSSEC) worked, but as it worked I don't know if the NTP synchronisation was over IPv4 or IPv6.

And the NTP synchronisation using IPv6 didn't always fail when using Unbound, so more data is needed before making any conclusions.

Why is it that where NTP synchronisation encounters a time out, it doesn't try using a different IPv6 or IPv4 address?

Also, is NTP synchronisation set to use IPv6 by default?

6

Try setting your upstream to 127.0.0.1 instead of the IPv6 localhost. I don't know if unbound has a preference of the IP version that it is queried on but localhost communication is essentially just a socket and you don't need to use IPv6 to have AAAA responses. You'll notice that the IP of the hosts queries are 127.0.0.1 and not the LL/GUA/ULA address.

7

Where? If you mean the pihole log, then the only host queries are from 127.0.0.01 and ::1. The Pi-holes LL/GUA addresses have never been used. Or, do you mean other devices?

After the first NTP synchronisation, I switched to using Cloudfare's DNS servers that block malware and phishing. These are my backup DNS servers, so I should have used them for the start.

After another four NTP synchronisations, I switched back to using Unbound, and since then all NTP synchronisations were successful.

Someone will need to tell me what's changed that appears to have fixed the problem.

Separately, between 3:40:49am and 3:41:16am yesterday there were 127 instances of WARNING: Cannot get exclusive lock for /etc/pihole/pihole.toml: Bad file descriptor, while there were 127 between 3:05:23am and 3:05:50am today in the FTL log files. Note, that these are not the only instances of these warnings.

Is there something that happens at this time that's causing these 100+ warnings.

8

That would be the NFS backed storage causing issues.

9

I know! The question was is there something that is causing more than 100 warnings in less than a minute between 3am and 4am.