Summary

  • APNIC says a connection-drain step during maintenance of one load-balancer node was inadvertently run against the other node, causing an outage. Its notice lists eight affected services, spanning the member portal, registry API, DASH, REx and several RPKI functions.
  • The notice gives a 14:44–15:01 UTC+10 window on 1 October, a 17-minute interval by subtraction, but labels the duration 15 minutes. It says APNIC is reviewing maintenance and failover procedures; it gives no user count or validation result for new safeguards.

Analysis

The most consequential line in APNIC’s 2 October notice is not the service list. It is the mismatch between the intended maintenance target and the node that received the connection-drain action. APNIC says one load-balancer node was being maintained, but the step to drain connections was inadvertently run against the other node and caused an outage.

The notice names eight affected services: the MyAPNIC Member Portal, registry-api.apnic.net, DASH, the Notification Platform, REx, RPKI rsync, the RPKI Provisioning and Publication Protocol, and rsc-verifier.apnic.net. That is a wide set of member-facing, registry and RPKI-related functions in one incident record. The list establishes the reported service scope; it does not establish that all eight were wholly unavailable for the same interval or that they share an identical internal path.

The clock is less tidy. APNIC records a start at 14:44 and an end at 15:01, both UTC+10. Those displayed minute marks are 17 minutes apart, while the notice’s duration field says 15 minutes. The page offers no seconds-level times or explanation. The discrepancy is small, but it matters when a notice is the public record used to compare service interruptions: readers should not be asked to choose silently between the duration and the timestamps.

APNIC says it is reviewing maintenance and failover procedures so they are clearer and include further safeguards. That is a stated review, not evidence that a revised procedure has been approved, tested or put into operation. The notice does not identify an action owner, a completion date, a target-verification check or service-by-service recovery times.

The boundary is equally important. The affected list includes RPKI services, but APNIC does not report a stale or incorrect route-origin authorization, a routing impact, data loss, a security event or a number-resource registration error. Nor does the notice quantify members or users affected. The 1 October event is also distinct from APNIC’s two September MyAPNIC incidents, which had different stated causes; no common cause is established.

A useful follow-up would be a short, privacy-safe record of what changed and how the safeguard was checked: which maintenance target was intended, how the target is confirmed before draining connections, which service checks closed the incident, and how the public duration is calculated. None requires publishing internal addresses, credentials or topology. Until such evidence appears, the defensible account is the one APNIC itself provides: a misdirected maintenance step caused an outage across eight listed services, and a review is under way.

Sources