HubDNS: hub.turnkeylinux.org server clock ~302s slow so all FQDN updates rejected as "expired"

[WannabeCoder777]

All hubdns-update runs fail with:

error: FQDN update error: Request timestamp: Wed, 12 Aug 2026 07:46:35 GMT expired. It must be within 300 secs/ of server time.'

The client clock is correct; the Hub's is not. Measured in a single command:

date -u; curl -sI https://www.cloudflare.com | grep -i ^date:; curl -sI https://hub.turnkeylinux.org/ | grep -i ^date:
Wed Aug 12 08:03:58 UTC 2026
date: Wed, 12 Aug 2026 08:03:58 GMT
Date: Wed, 12 Aug 2026 07:58:56 GMT

Client and Cloudflare agree to the second. hub.turnkeylinux.org is 302 seconds behind, just past its own 300s tolerance, so valid requests are rejected. Repeated over ~15 minutes, the offset held steady at 302s, so this is a persistent skew rather than jitter.

The response comes straight from gunicorn with no cache headers (no Age, no X-Cache), so this is the application server's own clock, not a CDN artifact:

curl -sI "https://hub.turnkeylinux.org/?cb=$(date +%s)" | grep -iE '^(date|age|x-cache|cf-|via|server):'
Server: gunicorn/19.0.0
Date: Wed, 12 Aug 2026 07:54:17 GMT

The API endpoint reports the same skew:

curl -sI "https://hub.turnkeylinux.org/api/hubdns/?cb=$(date +%s)" | grep -i ^date:
Date: Wed, 12 Aug 2026 07:54:36 GMT

Client side checks out:

• timedatectl reports System clock synchronized: yes
• Total runtime of hubdns-update is ~1.3s, so there's no client-side delay between timestamp generation and transmission
• cmd_update.py contains no timestamp logic — the Date header is built by pycurl_wrapper/libcurl

This should affect every HubDNS user, not just this host. Most will likely see it as hourly cron failure mail and assume their own clock is at fault.

Environment: TurnKey Core (Debian 12 bookworm) LXC on Proxmox VE, hubdns 1.3+1+g13e1dbf

Suggested fix: resync NTP on the Hub. Widening the 300s window would also add resilience against future drift.

[WannabeCoder777]

The problem still seems to be the server time being off, but let me just correct my original post:

I had this backwards at first.

That timestamp in the error message isn't coming from my client. I tested with libfaketime at -302s, +302s, +600s, and -86400s (a full day back), and every single run reported the same timestamp, always about 302 seconds behind my clock. That's the Hub's clock, not mine. Shifting my end changes nothing.

My guess is the Hub takes my update and then signs its own request to Route53 using its skewed clock, AWS rejects that, and the error gets handed back to me word for word. Would explain the slightly odd "300 secs/ of server time" phrasing, since that reads like AWS wording rather than TurnKey's.

If that's right, the 300 second window is AWS's, not yours, and there's nothing I can do on my side to work around it. Doesn't change the root cause or the fix though. The Hub's clock still needs resyncing.