8

This a report of a problem I solved but I feel the solution could be useful to other.

The problem appeared on a Raspbian 9.13. For some - probably hardware - reasons still to be discovered, my Raspberry pi-based router crashed and could not restart. I found it stuck on the raibow like image displayed when the Pi is just powered up.

Anyway, I restarted the Pi and everything worked as usual.

The only thing that did not work was Bind 9. The daemon was running but names resolution did not work.

I had a look at the following help : https://dnsinstitute.com/documentation/dnssec-guide/ch05s04.html because I found weird logs in /var/log/named/dnssec.log :

validating ./NS: verify failed due to bad signature (keyid=60955): RRSIG validity period has not begun

One possible solution I found was that, indeed, the time was not right : The pi displayed a time a good five hours in the past. Which explained why it found RRSIG validity in the future.

Thing is: it could not set its time right because it could not resolve the NTP servers name. Because name resolution did not work at all, because the time was not right.

Sotto Voce
  • 3,664
  • 1
  • 8
  • 21
David Verdin
  • 213
  • 1
  • 7
  • 1
    I believe google solves this problem for Chromebooks by hardcoding a specific https certificate to be considered valid regardless of the time, and then using that server's returned timestamp to roughly set the clock. – Glenn Willen Jun 23 '23 at 23:42
  • Wouldn't it be risky though ? What if the hard coded certificate get compromised somehow ? – David Verdin Jun 24 '23 at 13:26

4 Answers4

11

Raspberry Pis don't have a (battery-backed) real-time clock, so they will forget about the current time after being powered down. While you can deal with that in the old school way and enter the time manually after starting up, there are other options.

  • With the issue here being DNS, a straightforward solution would be to specify the time server to use at boot using just the IP address. At least as long as you have a local time server that isn't likely to move to another address, that should be relatively safe. Though it won't help if the system starts up with the network down.

  • A really cheap-ass solution would be to simply save the current time on the filesystem when shutting down, and read it back on startup. You wouldn't know how much time had elapsed in the meanwhile, but at least for a quick reboot, you wouldn't be far off. Though if the system crashes without running all shutdown tasks, the time wouldn't be saved. You could combat that by explicitly saving the time every once in a while, taking into account how close you need to be after a reboot and the write endurance of the storage.

  • Or, just buy an RTC module for the Pi. They're not hard to find and don't cost that much. (e.g. thepihut.com, adafruit.com)

ilkkachu
  • 133,243
  • 15
  • 236
  • 397
  • 3
    Even simpler… use an external resolver, like the one provided by your ISP or the public DNS resolvers of Google (8.8.8.8 and 8.8.4.4) and/or CloudFlare (1.1.1.1 and 1.0.0.1). – jcaron Jun 23 '23 at 22:57
  • @jcaron, well, yeah, or just ignore the DNSSEC errors... But that sort of defeats the purpose if they want to use it for whatever reason. – ilkkachu Jun 24 '23 at 09:22
  • 1
    I think raspbian does the "save and restore time" by default. That probably explains why the clock was only 5 hours behind. – jpa Jun 24 '23 at 13:00
  • Thanks ! I think also that there must be some kind of time saving by Raspbian at shutdown, because simple shutdowns ans restarts dont lead to this issue. I think your first solution is the best. The fact that it des not work when the network is down is not really a problem. Who needs DNS when the network is down? Thanks again! – David Verdin Jun 24 '23 at 13:18
  • @jpa, right, I didn't see that part! I'm not sure what the validity periods usually are with DNSSEC, but of course it could always happen that a signature is renewed just during the time the system is down, nowever long the validity period was. – ilkkachu Jun 24 '23 at 15:53
  • 1
    @DavidVerdin, yes, well, that's true. But I was also thinking of getting the time at least approximately right for other purposes too (like making any logs easier to read). – ilkkachu Jun 24 '23 at 15:55
4

To avoid these situations, I include an NTP source in chrony/ntpd using a hard-coded IP address. This could be:

  • an NTP server on your LAN that already has a battery backed RTC
  • an NTP server of Google/Cloudflare, etc.
mtheofy
  • 41
  • 2
3

So I set the time right using the date command :

sudo date -s '2023-06-23 10:39:20'

And everything went back to normal.

I posted it here because it was a weird problem.

Hope this helps someone, someday.

Cheers !

David Verdin
  • 213
  • 1
  • 7
3

The classical UNIX approach is to use ntpdate very early in the boot process to set the date from a server that has been pushed by DHCP, then start the ntpd process after the system has been fully booted up.

mmomtchev
  • 131
  • 3
  • Oh cool ! That's the generalized @Ikkachu solution. I juste read that, in Ubuntu at least, ntpdate has been replaced with timedatectl. Thanks tout ! – David Verdin Jun 28 '23 at 18:01