On Raspberry Pi OS, fake-hwclock
would already have been active by default, and it would already have been setup to save periodically (once per hour by default).
More importantly, note that fake-hwclock
did not and cannot "make sure this doesn't occur again", and neither won't ntpd
nor any other time service.
This is because RPis do lack a battery-backuped RTC, so they won't have a correct time after prolongued powerdown periods.
As a makeshift solution, Raspberry Pi OS starts with the last known time as saved by fake-hwclock
, and it would then try to sync with NTP servers by their respective DNS names (as configurable by /etc/systemd/timesyncd.conf
).
Now, DNSSEC validation requires a consistent time-frame on all involved machines, and if your RPi's time would be off by too much, DNS resolution of the time server name would fail. In fact, all DNS lookups will fail that way, and the resulting inability to contact an NTP server's IP for syncing time would leave you stuck with the wrong time and no DNS resolution.
To address this, you could try to add your router's IP address to your RPi's timesyncd.conf
, provided your router can be configured to act as a local time server.
This is what I've done on my RPi (click for details)
(*at least before I mounted a DS3231 RTC
*)
I've added a Local DNS record for time.fritz.box
pointing to my router's IP, and I've edited /etc/systemd/timesyncd.conf
to contain the following:
[Time]
NTP=time.fritz.box
FallbackNTP=0.de.pool.ntp.org 1.debian.pool.ntp.org
If my router's IP should change (e.g. if I had to switch to a different router), this would allow me to adjust the local DNS record instead of editing timesyncd.conf
.
But let me remind you this only works if your router can act as a local time server.
Another option would be to configure Pi-hole to resolve certain time server requests by forwarding them to a separate DNS server (click for details).
To that end, you'd have to create a custom dnsmasq
configuration (e.g. /etc/dnsmasq.d/42-time-server-no-dnssec-redirects.conf
with the following content:
server=/pool.ntp.org/8.8.8.8
Pi-hole's embedded dnsmasq
wouldn't apply DNSSEC validation for domains that are handled by such a server
option.
Run pihole restartdns
afterwards.
Note that this would leak DNS requests to a public DNS server (Google's 8.8.8.8
in above example) - depending on your personal preferences, that may be something you'd want to avoid.
Alternatively, you could consider to fit an RTC to your RPi4.
Those are available for already a few bucks only, and may be the most reliable choice.