I read that NTP may have a configuration/process issue in recent Pi-Hole implementations, i.e., some redundancy that isn’t quite clear to me how to config correctly.
Goal: Config PiHole to also be the Primary NTP source for system devices. This entails directing system devices to use the PiHole as the first NTP source server. Pros/Cons associated with this are indeed requested.
Expected Behaviour:
NTP works without generating subject error
O/S: Debian 12
Mobo: RasPi 4B V1.5
Docker: N/A
Actual Behaviour:
Subject error appears about every other day. No time of occurrence correlation has been detected (no pun intended).
Two separate things going on here worth addressing individually.
The periodic "Cannot resolve NTP server address" error every other day is almost certainly a service startup ordering issue rather than a Pi-Hole problem. When the system reboots or when FTL restarts, the NTP client (systemd-timesyncd or chrony, whichever is running) sometimes starts before the network is fully up and before FTL has started accepting queries. Since it tries to resolve pool.ntp.org or similar hostnames through Pi-Hole as the DNS resolver, and FTL isn't ready yet, the lookup fails.
Fix: check which NTP daemon you're using:
systemctl status systemd-timesyncd
or
systemctl status chrony
For systemd-timesyncd, add a fallback to /etc/systemd/timesyncd.conf:
Timesyncd will try the name-based ones first, but if resolution fails it falls back to the alternates. The real fix though is ensuring the NTP service waits for network-online.target. Create a drop-in:
For your second goal of making the Pi-Hole machine serve NTP to your LAN: Pi-Hole v6 FTL has a built-in NTP server. Go to Settings → System → Time and enable "Act as NTP server for your network". Once enabled, point your DHCP server to serve your Pi-Hole's IP as the NTP server via DHCP option 42 (your router should have an NTP server setting under DHCP options, though the label varies by router).
Pros of this setup: all clients sync from the same source, drift is consistent, and you can monitor NTP sync in the Pi-Hole UI.
Cons: if the Pi-Hole is down, NTP for the whole network stops. On a Raspberry Pi this is usually fine but worth knowing.
That's utterly wrong.
The correct navigation path is Settings | All Settings › Network Time Sync, where options ntp.ipv4.active and ntp.ip6.active control Pi-hole's IPv4 and IPv6 NTP server respectively, and ntp.sync.active controls its NTP client. All Settings is available in Expert mode only.
@RianKellyIT, you would have noticed that if you'd had the grace to at least test your content before posting it here, instead of using people seeking help as guinea pigs, luring them into trying and failing on your AI generated advice.
tocguy, please consider ignoring RianKellyIT's post - this is at least the third time they have been posting incorrect advice that either relates to a mixture of older Pi-hole versions, or completely made up features, which would suggest they are using AI to generate answers.
You can control Pi-hole's NTP server via Settings | All Settings › Network Time Sync via options ntp.ipv.active and ntp.ip6.active.
Note that All Settings is available in Expert mode only.
Enabling Pi-hole's NTP server would only make sense if
a. Pi-hole is acting as your network's DHCP server, in which case it would automatically distribute itself as NTP server.
b. Your router allows configuration of distributing a custom IPv4 NTP server address via DHCP and/or advertising a custom IPv6 NTP server address via DHCPv6 and/or RAs.
Also, you may want to check your router before considering Pi-hole's NTP server:
If your router already would propagate itself as NTP server, there would be no benefit in moving that duty to Pi-hole.
$ pihole-FTL ntp 10.0.0.2
Using NTP server: 10.0.0.2
........
Received 8/8 valid NTP replies from 10.0.0.2
Time offset: 4.170895e+00 ms (excluded 1 outliers)
Round-trip delay: 1.597677e+00 ms (excluded 1 outliers)
Whats configured as the local resolver in below file?
I am not certain of this but given that the errors occur at differing times it does not support a correlation with FTL restart, at least, not a restart that I have direct control over such as the nightly reboot. One would think that an error would likely occur at that reboot time if there were a timing dependency present.
“DHCP option 42”; ambiguous AI reply?
Given that the PiHole is already serving as DNS master it would seem redundant to create another rule to redirect NTP specific traffic to the PiHole given that all DNS traffic is already being directed to it for resolution. Or, am I over-simplifying what is actually going on under the hood? For example, when a NTP request arrives at the router I would assume that the entire address string is forwarded to the PiHole rather than just the base component. In other words, does slicing and splicing all occur at the PiHole rather than the router?
Commandsudo pihole-FTL dhcp-discoverdid not produce a NTP server result which is surprising given that I have PiHole Settings enabled as Network Time Sync. ??
Commandpihole-FTL ntp 10.0.0.2result
Using NTP server: 10.0.0.2
(4x) Failed to receive data from NTP server 10.0.0.2 (10.0.0.2): Connection refused
Commandgrep nameserver /etc/resolv.conf returns only the lan’s Gateway/Router ipV4/6 addresses.
$ pihole-FTL --list-dhcp4
Known DHCP options:
[..]
42 ntp-server
Not sure what you're asking or me misunderstand.
This what happens if setup correctly:
Clients receives NTP servers (names or IP's) via DHCP;
Client resolves received NTP server(s) , eg: pool.ntp.org, to IP address(es) via DNS;
Client connects to resolved IP(s) for syncing via NTP.
Its the DHCP server thats advertising NTP servers.
Is Pi-hole configured to do DHCP services for your LAN?
That 10.0.0.2 address is my NTP server on my LAN.
You would need to replace 10.0.0.2 with your own NTP server IP.
One or more of those DNS nameservers is/are giving you the error: "Cannot resolve NTP server address".
This sounds like a networking issue and not a Pi-hole one.
Above is the one thats not able to resolve via DNS eg:
$ dig pool.ntp.org
[..]
;; ANSWER SECTION:
pool.ntp.org. 35 IN A 81.172.248.188
pool.ntp.org. 35 IN A 83.137.149.135
pool.ntp.org. 35 IN A 178.239.19.59
pool.ntp.org. 35 IN A 185.71.60.123
[..]
;; SERVER: 10.0.0.1#53(10.0.0.1) (UDP)
[..]
$ pihole-FTL ntp 81.172.248.188
Using NTP server: 81.172.248.188
........
Received 8/8 valid NTP replies from 81.172.248.188
Time offset: 2.122492e+00 ms (excluded 0 outliers)
Round-trip delay: 1.309913e+01 ms (excluded 0 outliers)