May I ask: is there any difference if you install Unbound before Pi-hole?
(I've split your question from Unable to synchronize system time, Pi-hole not working in order to keep that other topic focused.)
There wouldn't be once you'd have completed installaton of both.
Still, I'd recommend to get Pi-hole fully operational first before installing unbound.
Well that is what he did:
LilRedDog
This is indeed my first time with Pi-hole. But I have some experience with Ubuntu from programming.
I know that it seems like I'm trying a lot of things at the same time but the problem started when I followed a simple tutorial.
The time synchronization problem has been an issue since the beginning.
I tried a lot of different things to fix the issue before posting on a forum because a lot of times there are already solutions elsewhere but I was unable to solve my problem.
This afternoon I freshly installed Rasbian on my pi to make sure I restarted on a clean slate and worked slowly to make sure everything worked along the way. Time synchronization and Unbound worked fine until I rebooted my pi after installing Pi-hole.
Without Unbound my Pi-hole didn't work as well, so that doesn't seem to be causing it.
Before using Chrony I didn't change any time-related settings and got the same results. strong text"
And that is a different situation than every output given before that.
Why use Chrony? I have 3 Pis and none use that.
Sorry but I don't understand what the point of this post is.
The only thing you have been doing is flooding my original post with unhelpful comments and being overly pedantic about unimportant miniscule details.
Now you even go as far as to create a separate topic just to prove a point.
You make it seem that because you have pi-hole running everyone else needs to be setting it up exactly the same way as you did.
I don't mean to be rude but felt like this needed to be said.
3 Likes
I did not make this separate: a mod did.
I may do a crap job of helping but there are things I still do not understand about that thread:
I do not understand why to use Chrony.
I do not understand why rebooting corrupts time. I've turned off my Pi4B for a couple hours to days and not had issues, but then I do not use it for Pi-hole. It always seems to boot to the correct time.
I have installed Unbound and it was no problem and since we are using the same Pi Zero 2 w, and the same software, I do not understand what is different.
I did use a YouTube video and not their page.
I've fresh installed Bullseye and Unbound twice because I wanted practice on a cheap SD card before I put in my 'high usage' card. and was left with nothing working.
You can tell me I'm rude but while I may be accomplishing it, I'm not trying to be.
And no, not everyone else should do things the way that is simple and works; you can set it up anyway you want.
I just see you struggling with your first install and trying to run before you walk, so to speak.
Above was originally posted by @thofra01.
Am not sure if Ubuntu on the Pi installs that fake hardware clock that DanSchaper mentioned before:
pi@ph5b:~ $ systemctl list-units "*fake*"
UNIT LOAD ACTIVE SUB DESCRIPTION
fake-hwclock.service loaded active exited Restore / save the current clock
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
pi@ph5b:~ $ journalctl -u fake-hwclock.service
[..]
-- Boot f58554c76e3245a1af30860c16a15796 --
Feb 16 17:54:23 ph5b fake-hwclock[89]: Wed 16 Feb 16:54:20 UTC 2022
Feb 22 23:42:17 ph5b systemd[1]: Stopping Restore / save the current clock...
Feb 22 23:42:17 ph5b systemd[1]: fake-hwclock.service: Succeeded.
Feb 22 23:42:17 ph5b systemd[1]: Stopped Restore / save the current clock.
pi@ph5b:~ $ dpkg -S fake-hwclock.service
fake-hwclock: /lib/systemd/system/fake-hwclock.service
pi@ph5b:~ $ man fake-hwclock
[..]
BACKGROUND
Many embedded Linux systems do not have a functional hardware clock. Ei‐
ther they simply don't have a hardware clock at all or they have a hard‐
ware clock but it is not usable (e.g. because Linux doesn't know how to
use it or because no battery is present).
This can lead to time moving backwards to some default value (often
1970) when the system is rebooted. Since lots of software assumes that
time only moves forward this is a bad thing. NTP can (and should where
practical) be used to sync with an external timeserver but it is not
available early in the boot process and may be unavailable for other
reasons.
The design expectation of fake-hwclock is that it will be run very late
at shutdown and very early at boot. This will ensure that fsck has a
vaguely sensible idea of system time at boot and won't complain that the
last-modified time in the filesystem is not hugely in the past or fu‐
ture. Some users may not worry about this too use case, in which case it
is possible to modify the init system configuration to move things ear‐
lier/later as appropriate.
DESCRIPTION
fake-hwclock sets and queries a fake "hardware clock" which stores the
time in a file. This program may be run by the system administrator di‐
rectly but is typically run by init (to load the time on startup and
save it on shutdown) and cron (to save the time hourly).
If no command is given then fake-hwclock acts as if the save command was
used.
COMMANDS
save Save the time to the file. As a sanity check, fake-hwclock will
not move the saved clock backwards to a time/date earlier than
its own release date. Use "force" to over-ride this check.
load Load the time from the file. If force is specified fake-hwclock
will move the clock either backwards or forwards. Otherwise it
will only move it forwards.
Maybe @thofra01 can confirm by running above commands?
I have very little experience with Ubuntu but maybe for Ubuntu, thats the default timekeeper.
I could be wrong!
For Raspbian/Pi-OS the default is the one thats also provided with systemd and called systemd-timesyncd.service:
pi@ph5b:~ $ journalctl -u systemd-timesyncd.service
[..]
-- Boot 09d1cb9f77744bc89cdf91b39d90a4df --
Feb 22 23:42:31 ph5b systemd[1]: Starting Network Time Synchronization...
Feb 22 23:42:33 ph5b systemd[1]: Started Network Time Synchronization.
Feb 22 23:43:22 ph5b systemd-timesyncd[194]: Initial synchronization to time server 45.85.15.40:123 (2.debian.pool.ntp.org).
For my XBian Kodi media center, the default is called ntpd:
xbian@avr ~ $ sudo service ntp status
ntp start/running, process 2970
xbian@avr ~ $ man ntpd
[..]
DESCRIPTION
The ntpd utility is an operating system daemon which sets and maintains
the system time of day in synchronism with Internet standard time
servers.
And my Debian laptop is also using systemd-timesyncd.service.
No rebooting should not corrupt time as that fake HW clock will take care of that.
Ubuntu?
No, Raspbian OS which is Debian Bullseye, 64-bit.
If I remember correctly, they are, also, using Raspbian. Only difference, other than I do not use Chony, I do not use the Pi-hole as a DHCP server. OpenWrt does that.
I do know it needs the correct time for DNS but tomorrow I'm going to plug in my old Pi Zero w, with Buster, and see if the DHCP he is using and the DHCP I do not use, makes a difference.
Also, If I remember correctly, they are more versed in Ubuntu. Maybe explains Chrony.
I play with it, but it is not my favorite Distro. And I play on an old Dell Precision 670...
Yeah, it is torture but it is winter here and it helps heat the room.
Not entirely.
Raspbian is its own distro but makes uses of most all of Debian's packages.
There are packages in Raspbian that are not available in Debian.
Below tool might be helpful to check the DNS server(s) that are advertised via DHCPv4:
pihole-FTL dhcp-discover
Do mind though that its only scanning for DHCPv4.
Your router might also be providing DHCPv6.
And if your router supports IPv6 on your LAN, other DNS server(s) could be pushed to the clients as well with something thats called IPv6 router advertisement (RA).
Thats why its important when uncerten, to check DNS servers configured locally on the clients.
It is weird:
I do have IPv6 enabled on the router, but I still do not get ads.
I do see a lot of IPv6 inquiries, on both the Pi-hole and traffic on the router, but still no ads. ~26-30% blockage in the Pi-hole.
I get some ads on Safari, a TON on YouTube, if I use the app but primarily I use Brave.
Anyway: everything works on my end. I was just trying to see why they do not on theirs and they seem to have time sync issues I do not.
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.
So let's briefly return to those explanations.
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:
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.
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)).
1 Like
I understand most of that and I know we have 1,000 seconds to get it running again, (~16.6 minutes).
The only times I have pulled the plug was, once when the Pi4 locked up, and once when 64-bit went official but screen blanking would not turn the monitor back on after keyboard input.
And I only reboot after updates. I know I don't need to, most of the time, but It feels right.
I'm pretty sure it gets time from the router that gets it from openwrt.org. I do not play with Unbound after I install it; too many threads on issues.
I do know in about 5 months I'll need to up grade root hints.
Hmmm I think some of your assumptions are or could be wrong.
No you dont have 1000 seconds to get it running again.
You simple dont have a proper working system if time is off by 1000 seconds.
When NTP tries to sync but cant bc time is off and consequently DNSSEC fails when trying to lookup the IP's for the NTP servers (see below).
Above is only true if your Pi-hole host is setup to acquire IP details via DHCP and your DHCP service is advertising NTP servers (which is rarely the case).
You can check with below command if your DHCP setup is advertising NTP servers:
pihole-FTL dhcp-discover
With Raspbian default OOTB, and when you've stetup a static IP for the Pi-hole host, below servers are queried for syncing time:
pi@ph5b:~ $ cat /etc/systemd/timesyncd.conf
[..]
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.
[Time]
#NTP=
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048
Above commented/hashed out FallbackNTP= line shows the default NTP servers that will be queried by timesyncd:
pi@ph5b:~ $ journalctl -u systemd-timesyncd.service
[..]
Feb 22 23:43:22 ph5b systemd-timesyncd[194]: Initial synchronization to time server 45.85.15.40:123 (2.debian.pool.ntp.org).
So essentially timesyncd will first try to lookup the IP's via DNS like below:
pi@ph5b:~ $ dig +short 2.debian.pool.ntp.org a
213.136.0.252
129.250.35.251
94.198.159.15
46.243.26.34
And then tries to connect to one of them via the IP address (not the name) to try and sync:
pi@ph5b:~ $ ntpdate -q 213.136.0.252
server 213.136.0.252, stratum 1, offset +0.006187, delay 0.04129
27 Feb 11:19:01 ntpdate[21089]: adjust time server 213.136.0.252 offset +0.006187 sec
If you followed the official Unbound guide without that "Optional: Download the current root hints file.." bit,
the root.hints file should have been installed already via your software package manager named APT:
pi@ph5b:~ $ apt depends unbound
[..]
Depends: dns-root-data
pi@ph5b:~ $ dpkg -L dns-root-data
[..]
/usr/share/dns/root.hints
/usr/share/dns/root.hints.sig
pi@ph5b:~ $ cat /etc/unbound/unbound.conf.d/pi-hole.conf
[..]
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
#root-hints: "/var/lib/unbound/root.hints"
This means you dont have to download that root.hints file separately to update but instead, just run apt update/upgrade at regular intervals.
EDIT: Ow ps, you've got lots of brilliant talents contributing here so dont shy away from asking 
1 Like
It returns this:
- Received 300 bytes from wlan0:192.168.10.1
Offered IP address: 192.168.10.121
Server IP address: 192.168.10.1
Relay-agent IP address: N/A
BOOTP server: (empty)
BOOTP file: (empty)
DHCP options:
Message type: DHCPOFFER (2)
server-identifier: 192.168.10.1
lease-time: 43200 ( 12h )
renewal-time: 21600 ( 6h )
rebinding-time: 37800 ( 10h 30m )
netmask: 255.255.255.0
broadcast: 192.168.10.255
router: 192.168.10.1
domain-name: "lan"
dns-server: 192.168.10.245
192.168.10.1 is the router; 192.168.10.245 is pi-hole.
I'd have to dig to find 10.121.
edit
192.168.10.121 must be a virtual machine. I cannot ping it.
2nd edit
But it is suspiciously close to the wired range extender, in AP mode, that I set to 192.168.10.120.
Guest mode is off.
I'm just trying to learn:
My OpenWRT CFG is a decade old, then tweaked as needed. Honestly: I do not know all the changes I made to make it work over all these years.
I would save and tweak. If the tweak did not work, I reverted and tried again.
It is running 21.02, now, but I have 'only' 8GB ram and that was 'crazy' more than enough, back then.
-memories of my SonicWall SOHO 50 as bleeding edge-
Whatever flaked, I would tweak.
And now that I've dove back into it:
I think AT&T has done a firmware upgrade and double NAT'ed me.
Not that I noticed: the only game I play is CS:Go...
(1.4 BB!!!)
I do remember, being told that, I could not, completely, passthrough the gateway because the POS clients for the POS gateway needed it for U-Verse.
It does not appear that your DHCP service is advertising NTP servers.
If I configure my Pi-hole host (who also does DHCP for my network) to advertise an NTP server:
pi@ph5a:~ $ pihole-FTL -- --help dhcp
Known DHCP options:
[..]
42 ntp-server
pi@ph5a:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
dhcp-option=option:ntp-server,10.0.0.3
pi@ph5a:~ $ pihole-FTL --test
dnsmasq: syntax check OK.
pi@ph5a:~ $ sudo service pihole-FTL reload
pi@ph5a:~ $
It shows like below when I scan:
pi@ph5a:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
ntp-server: 10.0.0.3
That 192.168.10.121 IP is an offer from the DHCP server if the Pi-hole host would actually try to acquire an IP via DHCP.
Instead, you most likely configured the Pi-hole host with a static IP like below? (EDIT: and thus not involving DHCP)
pi@ph5a:~ $ tail /etc/dhcpcd.conf
[..]
interface eth0
static ip_address=10.0.0.2/24
static routers=10.0.0.1
static domain_name_servers=10.0.0.1
The dhcp-discover looks ok.
But you'd also have to consider below if you have IPv6 supported/enabled for the LAN side in the router settings:
I dont know what you mean with POS?
I only know POS from Point Of Sale (a cash register).
Piece Of S#it.
AT&T...
...No. I cannot pollute this thread with realty.
It is like an election in the U.S.: choose between AT&T or Comcast...
Been with AT&T since 1999 (yeah, I know: AT&T collapsed, Cingular bought BellSouth, then bought AT&T, then changed names)
And:
Yeah, I KNOW and set up IPv6, but it causes no issues.
I, seriously, do not get ads and the only site I have broken is SyFy.com.
edit
Whoops! Slightly color blind, but you can see.
2nd edit
This is all academic and I thank you:
I am happy with my results.
I'm now working on getting a better than 30 ping to servers when I play CS:Go.
Online is like the Olympics:
every, count, counts.
I get it.
They can hate on me: I don't care; I was trying to help them. Even If it was ignorant help.
The more I think I know and the more you all correct, the better I get at this.
OpenWRT is a PitA.
And, they are mean. You all are cool.
It is kind of like "Live and let Die": Sheriff Pepper is not the bad guy, instead, he is out of touch with Europe.
I'm ooT. Thanks for all the patience.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.