Going in circles without a real-time clock

Original Article ↗ Hacker News Discussion ↗

Bootstrapping accurate time on devices without a real-time clock turns out to be surprisingly fragile, especially when modern security features like DNSSEC, TLS, and WireGuard all rely on a roughly correct system clock. Commenters describe circular failures where a Raspberry Pi or router can’t validate NTP servers because its time is wrong, so it can’t fix the time, breaking VPNs, certificate validation, and even DNS. Proposed mitigations range from cheap RTC or GPS-based stratum‑1 time servers to DHCP- or HTTP-based “good enough” time hints and systemd wiring, alongside criticism of NTP.org using DNSSEC and broader concerns about Raspberry Pi’s suitability and reliability in production setups.

Bootstrapping Time & DNSSEC / NTP Deadlocks

  • Main failure mode: devices without RTC start far from real time, fail DNSSEC validation for NTP pool domains, and thus can’t reach NTP to fix their clocks.
  • Some argue enabling DNSSEC on ntp.org undermines its mission because many clients will be badly skewed; others counter that without DNSSEC, MITM attackers can redirect NTP and feed malicious time.
  • Suggested workarounds:
    • Temporarily disable time-based DNSSEC checks on boot.
    • Use last-known-good time plus TLS certificates/OCSP ranges to narrow current time.
    • Use HTTP Date header for insecure but simple bootstrapping.
    • Use tools like tlsdate-style approaches or Roughtime (not widely deployed yet).
    • OpenWrt example: start DNS with “no timecheck” until NTP syncs once.

WireGuard and Time Synchronization

  • WireGuard relies on a per‑peer monotonic counter (often derived from time) for key rotation and replay protection.
  • Not strictly wall‑clock synchronized, but large backward jumps or skew can break sessions; some report peers needing restarts after clock corrections.
  • People try systemd ordering (start WireGuard after time-sync.target), with uncertain reliability.

RTC Modules, GPS, and Time Servers

  • Many recommend adding an RTC or GPS to Pis and routers:
    • Cheap I2C RTCs (~$1) work well for most, but others report fragile hardware.
    • GPS + PPS gives microsecond‑level accuracy; several run Pi-based stratum‑1 servers.
    • Projects exist that bundle overlayFS, GPS, and chrony to make robust time servers.
  • Counterpoint: RTCs add BOM cost, board space, batteries, and still have drift/failure modes; some designs intentionally omit them and rely on network time.

Raspberry Pi Ecosystem & Reliability

  • Repeated complaints about:
    • Lack of RTC on older Pis and Pi 5 requiring a separate battery.
    • SD card corruption under write‑heavy workloads; mitigations include overlayFS, high‑endurance cards, or moving OS to USB/NVMe.
  • Some claim Pis are increasingly unsuitable for “production” compared to small x86 PCs; others are happy using them as low‑power desktops, GPIO controllers, and NTP servers.

DHCP and Other Time-Bootstrapping Ideas

  • Several want DHCP to provide a coarse current timestamp for RTC‑less devices.
  • Critics note time is more security‑sensitive than IP configuration; trusting DHCP time can enable certificate abuse.
  • Proposed compromise: treat DHCP-supplied time as a one‑shot bootstrap, bounded by other local timestamps and not used for long‑term trust.