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
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:
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
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:
dnsmasq wouldn't apply DNSSEC validation for domains that are handled by such a
pihole restartdns afterwards.
Note that this would leak DNS requests to a public DNS server (Google's
220.127.116.11 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.