DynDNS updates failing – hostnames kept pointing at the last reported address

Since 18 September, around 18:00 (CEST), DynDNS hostnames have been unable to publish a new IP address. All hostnames are affected, regardless of domain or plan.

What this means: DNS records stay on the last address that was published successfully. If your public IP changed during that time – on many connections it does overnight – your hostname no longer points at you. No existing record was changed or deleted, no data was lost, and there was no unauthorised access at any point.

What you need to do: Usually nothing. Your router reports its address again on its next run and the hostname corrects itself. If your device gave up after repeated failures, disconnecting and reconnecting DynDNS once in the router is enough.

Cause: This one is on me. I shipped a change that writes a timestamp to the database before every DNS update. That query was missing a type annotation for one parameter, which PostgreSQL cannot infer in that position, so it refused to run the statement. Because it sits immediately before the DNS update itself, the update never happened. The update history showed this as a generic error, which delayed finding it.

Status: The fix is ready and currently rolling out. I will post a further update here as soon as it is active on all servers. An automated test now also checks every change for database queries that fall into the same trap – the same check immediately found a second spot in the code, which was corrected as a precaution. Failures of this kind will report their actual cause in the update history instead of a generic message.

Letting this run undetected for the better part of a day was avoidable. I apologise for the inconvenience this has caused.