RIPE’s update failures outlasted its recovery notice

RIPE’s update-failure window outlasted its green light by eight minutes

Why it matters

A 30 October follow-up says none of the failed reverse-delegation requests would have changed the data. Its failure window still runs eight minutes beyond the original incident page’s resolution.

Theo March30 October 2026Reading Time 2 minLast update: 30 October 2026

Conceptual illustration of the two clocks in RIPE NCC’s linked incident records and the later finding that failed requests did not change reverse delegations.

Summary

A RIPE NCC record published on 30 October places intermittent database update failures from 11:42 to 19:40 UTC on 28 October; the first incident page marked the event resolved at 19:32 UTC.
The follow-up says none of the failed requests would have changed a reverse delegation: each was a no-op or failed Zonemaster predelegation checks. The original record says major impact; the later one says none.

The RIPE Database’s public clock and the later failure window do not stop together. RIPE NCC’s first incident page marked the update problem resolved at 20:32 CET on 28 October, or 19:32 UTC. A follow-up added on 30 October says updates failed intermittently through 19:40 UTC. That is eight minutes after the original closeout.

The same follow-up starts the failure period at 11:42 UTC. RIPE NCC’s first public investigation note appeared at 20:04 CET, 19:04 UTC: seven hours and 22 minutes later. The original timeline then moved the RIPE Database from partial outage to operational at 20:23 CET and marked the incident resolved nine minutes after that.

The new detail changes the operational reading. The first notice said some updates were not processed and that some domain objects affected Reverse DNS. The later record says the failed requests would not have changed reverse delegations: they contained no changes or failed Zonemaster predelegation checks. RIPE’s reverse-DNS documentation explains why those checks matter: a domain object requests delegation, and nameserver checks come before RIPE NCC propagates it.

So the records describe failed write attempts, not failed changes to the delegation ledger. They do not report a DNS-resolution outage. The status API gives the first incident an impact label of “major” and the linked follow-up “none”; it does not explain the difference. Nor does it give a count of failed requests or identify their objects. That count and object list would tell operators how many submissions need a local closeout.