Summary

  • RIPE NCC posted its NRTM and split-files incident postmortem at 15:03 CEST on 13 August 2026.
  • The report says an invalid RPSL object stopped the mirroring stream and left clients out of sync from that point.
  • RIPE NCC says it has changed newline handling and NRTM behaviour, with both fixes due in Whois 1.124 on 27 August.

A malformed object met a stop-the-stream rule

RIPE NCC says its NRTM mirroring service was affected from approximately 00:06 UTC on 2 August until 12:30 UTC on 4 August. Its 13 August postmortem identifies the immediate failure mode: an invalid RPSL object was written to the RIPE Database, the NRTM service reached that object and stopped, and clients became desynchronised from the database from that point onward.

The incident page had already recorded a dependent consequence. Reverse-DNS provisioning relies on NRTM, and updates to domain objects were not appearing in global DNS while the issue was being investigated. RIPE NCC later said that pending domain-object updates had been processed and published, then marked the incident resolved on 4 August. The postmortem is not a claim about every mirror or every downstream resolver; it explains the documented service path that failed.

Two defensive changes, with a future release date

The report links the invalid object to a code change in Whois release 1.122, introduced in April. Additional newlines in descr: and remarks: attributes were inadvertently permitted, allowing invalid RPSL to be written. RIPE NCC says it has changed UTF-8 code-point substitution so that it no longer writes those extra newlines.

It also says the NRTM server previously failed with an internal error instead of skipping an invalid RPSL object. The stated new behaviour is to skip the invalid object and log an error; the database team can then correct it so that the update can appear later in the stream. Both changes are scheduled for the upcoming Whois 1.124 release, due Thursday 27 August. That is a published plan, not proof that the release has already happened.

The control lesson is continuity, not invisibility

RIPE NCC has added a monitor that requests a recent range of NRTM updates and validates the response. That is a useful shift from observing that a service answers to checking whether a recent slice of the stream is usable. It does not make malformed data harmless, and it does not establish the state of any individual mirror after the incident.

For operators consuming registry data, the narrow lesson is to preserve a way to detect a stream that has stopped making semantic progress, not merely a process that remains reachable. The public report gives no client list, route list, or independent measurement of downstream recovery. It does show why validation at both write time and stream time belongs in the same operational chain.

Sources