You have to wonder if it's intentional or not, but even the pihole documentation points out the problem: raspberry pis do not come with a RTC (real-time clock), so unless one gets one for the Pi your pihole-based NTP server always will have a problem if it was offline for longer than a few hours.

The problem is deliciously simple: a device with no RTC will keep the time it last switched off on until it synchronized with another NTP server. It cannot synchronize with any public NTP server because it can't establish a connection: the handshake fails because one of the devices believes it's days earlier than it actually is.

No connection, no sync. No sync, no valid DNS resolution. No valid DNS resolution, no connection.

How do we solve this?

Well, one way is to set your time manually.

Run

$ timedatectl set-ntp false

Then

$ timedatectl set-time 2026-03-04 02:00

Or whatever is right. Then

$ timedatectl set-ntp true

And while that does the job, I realized there's actually an easier way to handle the problem: you see, the issue comes because DNS resolution doesn't work, right? So why not, incidentally, just use the ip address of a nearby NTP server?

And presto, it's back to normal.

I actually used the server of the Polish Główny Urząd Miar (Central Office of Measures) as I'm located in Poland (their address is 194.146.251.100 btw) because I figured, well, isn't that likely one of the most accurate places around? In fact, why do we keep using clock servers by Google and Cloudflare and so on, when public scientific institutions everywhere provide the same service? Oh, well, besides the fact that it's free either way I guess?