I had exactly the same issue happening to me! I’ve since added a Real Time Clock (RTC), so the Pi shouldn’t forget about the current time anymore. That is until the battery runs out of course, for which there is no monitoring in place. So yeah maybe I should disable DNSSEC as well. At least we need to get better at building fault tolerant systems. Maybe Pi-Hole needs to be aware of and handle this scenario better: a special “we’re booting up and we don’t have the current time so don’t do DNSSEC yet”.

fake-hwclock[1] is useful for this. I don't know much about Pi-Hole, but if it involves writable storage and has a package manager, fake-hwclock may be available from there.

> At least we need to get better at building fault tolerant systems.

Security and fault tolerance are at odds here. Failing closed when you can't validate is correct, but not so useful. Properly modeling the clock might give you a way to get bootstrapped, but then an adversary would arrange for a bootstrap situation so they could interfere with your clock and then make use of the incorrect time for their nefarious purposes.

[1] https://git.einval.com/cgi-bin/gitweb.cgi?p=fake-hwclock.git

Does pihole even have value anymore with DNS over https?

I'd just implement that in 0.2 nanoseconds if I were a Samsung engineer making an intrusive adserver.

What's your alternative to the pihole with dns over https?

Grandparent is saying that DoH ignores the dns settings on your computer and on your network (from dhcp) because every piece of software and every "smart" device just asks cloudflare where to go meaning pihole is ineffective.

Wouldn't you just have your pihole block well known resolver ips and solve that problem?

For me it's a reason to use IP address in /etc/ntp.conf instead. DNS over HTTPS and HTTPS in general also need current time to validate a certificate so DNSSEC is not unique here.

This makes Network Time Security difficult.

This is a reason you add an RTC to your RPi.