Is there any difference if you install Unbound before Pi-hole?

[Bucking_Horn]

@thofra01

Now you even go as far as to create a separate topic just to prove a point.

@LilRedDog

I did not make this separate: a mod did.

That was indeed a moderator action: You could tell by the link under the topic's opening post that it has been split away from another topic, but I forgot to include my usual explanatory hint in my reply. Apologies for that.

I did so in order to keep that other topic focused.

I also think that my reply is providing the correct answer to your (i.e. LilRedDog's) original question.

But given your subsequent questions, it would seem to me that this question is caused by a lack or refusal of understanding of the explanations offered in that other topic.

@deHakkelaar

Well you could ask what part you dont understand?

@LilRedDog

I do not need to understand (unless I'm asking); so I do not ask.

So let's briefly return to those explanations.

@thofra01

Time synchronization and Unbound worked fine until I rebooted my pi after installing Pi-hole.

@LilRedDog

I do not understand why rebooting corrupts time.

unbound commonly comes with DNSSEC enabled (at least if you follow our guide).

DNSSEC requires a mutually shared timeframe on all involved machines.
Without such a common timeframe, validation of digital signatures of DNS replies will result in BOGUS, and the replies will be discarded, leaving the requesting client without DNS resolution for such a request.

A client without a battery-backuped RTC must rely on retrieving correct time information from an external source. Commonly, it will try to do so by accessing a time server using the NTP protocol.

Now if a DNSSEC-enabled client's time would be off, and it would try to establish NTP communication using a domain like europe.pool.ntp.org (or any domain, really), DNSSEC validation will already fail when trying to validate the DNS root servers. And as the root zone is completely DNSSEC enabled, the client will never be able to retrieve a correct time.

This is essentially what **deHakkelaar** has already explained much shorter:

@deHakkelaar

If so, your most likely are experiencing a chicken-egg dilemma (who is first).
NTP depends on DNS.
And DNS (with DNSSEC) depends on the correct time provided by NTP.

On any RPi running Raspberry Pi OS, fake-hwclock will be used in lieu of an RTC.
fake-hwclock at least would be able to provide a constantly foward-moving timeline by reading a time from a file at boot, and writing to that file at a controlled shutdown. Depending on your config, it would also write the current time to that file at regular intervals, usually once per hour.

Hence if you reboot your RPi the hard way (e.g. by briefly cutting its power), your time may be off by as much as an hour, or whatever that regular interval is on your system (and would be completely off if that file would be corrupted or inaccessible at boot time).
For a graceful reboot, chances are that the time gap caused by rebooting remains small enough for DNSSEC to be tolerable.
But if you shutdown your RPi, that time difference could be further increased by the length of the shutdown period.

This is essentially what **DanSchaper** has already explained.

@DanSchaper

Raspberry Pi devices don't have a Real Time Clock onboard. So they use an application called fakehwclock to fake that facility. It writes a file with the current time when you gracefully shut down the Pi. When it starts up again it reads that file and uses that time as the start time until it can reach a way/process to update the current time (NTP).

If you would enable DNSSEC for your system, then you could observe the same apparent loss of DNS resolution (unless you'd configured a time server's IP instead of a domain for your favourite time-keeping package, of course. (edit: or if your Pi-hole host would not use Pi-hole/unbound for DNS at all)).