Bug#1150806: systemd-timesyncd: DNSSEC/NTP bootstrapping deadlock with Unbound after Pi loses RTC power

[Pryodon]

Package: systemd-timesyncd
Version: 257.13-1~deb13u1
Severity: normal

On a Raspberry Pi 5 running Raspberry Pi OS Lite (64-bit, Debian 13.7
Trixie), systemd-timesyncd was unable to recover the system clock after
the device had been unplugged for approximately two days. The resulting
DNSSEC/NTP bootstrapping deadlock also prevented the Pi's Unbound DNS
resolver from serving several domains to the rest of the home network.

System:
  Hardware: Raspberry Pi 5, no RTC backup battery
  Image: Raspberry Pi OS, pi-gen reference 2026-06-18 (stage2)
  OS: Debian GNU/Linux 13.7 (trixie), arm64
  Kernel: 6.18.50+rpt-rpi-2712
  systemd: 257.13-1~deb13u1 (Debian trixie/main)
  systemd-timesyncd: 257.13-1~deb13u1 (Debian trixie/main)
  Unbound: 1.26.1-0+deb13u1 (Debian trixie-security)
  DNS resolver on Pi: Unbound at 127.0.0.1, validating DNSSECwe
  Original NTP configuration: Debian pool hostnames

Steps and observed failure:
1. Shut down the Pi and unplug it from power for about two days.
   Without RTC backup power, its system clock was stale on boot.
2. On October 13, 2026, the Pi still showed October 11:
     $ date -u
     Sun 11 Oct 21:38:11 UTC 2026
   timedatectl reported "System clock synchronized: no" and an RTC
   value in January 1970.
3. The local validating resolver returned SERVFAIL for some domains:
     $ host 1.debian.pool.ntp.org
     Host 1.debian.pool.ntp.org not found: 2(SERVFAIL)

     $ dig @127.0.0.1 pryodon.com A +dnssec
     ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

     $ dig @127.0.0.1 pryodon.com A +cd
     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
     ;; ANSWER: 104.21.76.46 and 172.67.187.174

   Thus Unbound could retrieve the answer with DNSSEC checking
   disabled for the query but failed normal validation. Its configured
   root trust anchors (key IDs 20326 and 38696) were both VALID.
   Switching forwarders to 1.1.1.1/1.0.0.1 did not help.
4. Because systemd-timesyncd needed DNS to resolve its NTP hostname,
   synchronization could not start:
     $ timedatectl timesync-status
     Server: n/a (1.debian.pool.ntp.org)
     Packet count: 0
   This persisted rather than recovering automatically, disrupting DNS
   for clients using the Pi.

Recovery and workaround:
- Manually correcting the system clock immediately restored DNS.
- I then configured /etc/systemd/timesyncd.conf as:
    [Time]
    NTP=162.159.200.1 162.159.200.123
- After restarting systemd-timesyncd, it synchronized successfully:
    Server: 162.159.200.1 (162.159.200.1)
    Offset: +580us
    Packet count: 1

(The static IP addresses are for Cloudflare's NTP servers.)

Expected behavior:
On a system without a reliable battery-backed RTC, available network
connectivity should permit automatic time recovery even if DNSSEC
validation fails due to the incorrect local clock. Alternatively,
systemd-timesyncd or the packaging/documentation should make this
dependency and a DNS-independent NTP fallback more apparent.

Related reports:
  https://github.com/systemd/systemd/issues/5873
  https://github.com/systemd/systemd/issues/15607
  https://bugs.debian.org/898530

Debian bug #898530 describes a fix that bypasses DNSSEC validation for
timesyncd lookups through systemd-resolved. This case uses Unbound as
the validating resolver, and the failure is still reproducible in
principle despite that earlier fix. I am reporting it in case a
resolver-independent fallback or additional documentation is needed.

I have not deliberately reproduced the outage since applying the
numeric NTP workaround.