Summary

  • RIPE Database updates failed intermittently for almost eight hours on 28 October, including reverse-DNS requests.
  • RIPE NCC’s follow-up says none of those failed requests would have changed a delegation: some asked for no change, while others failed Zonemaster checks.

The incident report has two endings. On 28 October, RIPE NCC said some database updates were not being processed and that domain objects had an impact on reverse DNS. On 30 October, the status history added the finding that none of the failed requests would have changed a reverse delegation.

That second update changes the useful question. The service failed; the delegated DNS state did not change as a result of those failed requests. The distinction matters because a database update is one step in a longer chain, not a synonym for a published change.

RIPE NCC places the incident window between 11:42 and 19:40 UTC on 28 October. The status page’s initial report appeared at 20:04 CET. A fix was being monitored by 20:23, and the incident was marked resolved at 20:32. The later investigation, posted on 30 October, split the failed requests into two groups: some contained no changes; the others failed predelegation checks in Zonemaster.

A reverse delegation starts with a domain object in the RIPE Database. Its nserver attributes identify the name servers that should answer for a reverse zone. RIPE NCC uses Database records to produce DNS zones, so changing an accepted object can eventually change the delegation visible through the parent zone.

Submission alone does not perform that change. The Database checks whether the listed servers are configured correctly. RIPE’s documentation says updates with ERROR or CRITICAL results are rejected; after a successful update, delegation data may take up to 24 hours to appear in DNS. The pipeline has at least three distinct states: request received, object accepted, parent-zone publication.

The October incident interrupted the first part of that pipeline. The follow-up says the requests that failed were no-ops or would have been rejected by the validation gate anyway. That is a narrower and more useful account than treating every failed database transaction as a changed DNS record. It also gives operators a concrete way to read a service alert: ask which state failed, then check the record and the delegated zone.

RIPE NCC has not published the number of failed submissions or the underlying technical defect; those details would show the scale and cause of the interruption.

Sources