Summary

  • APNIC reports that one network firewall detected a hardware fault and rebooted between 19:10 and 19:18 UTC+10 on 28 August 2026. It says the event interrupted six named service surfaces.
  • The list combines MyAPNIC and a registry API that can change registry state, Orbit communications, world-readable FTP data, RPKI provisioning/publication and RPKI rsync retrieval. These operations do not share one completion model.
  • APNIC does not report data loss, corruption, duplicate updates or a security incident. It also does not publish per-surface recovery, pending-task, queue-drain or representation-consistency states.
  • A small operation-state incident receipt could preserve the single infrastructure event while distinguishing accepted, committed, visible, retryable and still-draining work without exposing member data or private topology.

Eight minutes, six unlike questions

APNIC's 28 August service announcement is admirably concrete about its outer boundary. The event began at 19:10 and ended at 19:18 in the UTC+10 time zone. One of APNIC's network firewalls detected a hardware fault and rebooted. APNIC says that caused interruptions to MyAPNIC Member Portal, registry-api.apnic.net, Orbit, FTP, “RPKI Provisioning and Publication protocol” and RPKI rsync.

The notice also gives a next action. APNIC is investigating with the hardware vendor and working to improve traffic failover between network firewalls so that similar events cause less interruption. Its service-announcement feed preserves the same start, end and hardware-fault description.

Those facts support a bounded account. They do not show that APNIC's entire registry stopped, that every listed surface was unavailable for all eight minutes, or that any record or RPKI object was damaged. An interruption may be a timeout, refused connection, partial error rate, stalled task, delayed publication or failed retrieval. The public notice does not choose among those states for each service.

That distinction becomes important because the affected list is not one application viewed through six names. It is a set of interfaces through which different parties perform different work. The infrastructure incident can have one start and one end while the operations crossing it have several endings.

A registry request may outlive its connection

The registry API gives the sharpest example. APNIC's launch documentation says members can use it to retrieve delegation information and manage Whois records, reverse-DNS records, Route Origin Authorisations and route objects. It is not merely a status page. It accepts operations that can change public registry or routing-security state.

APNIC also documents two safeguards that make a network interruption more subtle than “success” or “failure”. Reverse-DNS and abstract route-management batches take effect transactionally where possible. All updates are asynchronous task objects. After a client submits an update, it receives a task URL to poll; the completed task contains the outcome.

There are therefore at least four moments that a member may care about: whether the request reached the service, whether it was admitted as a task, whether its work committed, and whether the resulting state became visible. A client whose connection disappeared between those moments cannot infer the answer from the firewall's recovery time.

The safest action depends on the missing state. If the request was never admitted, a retry may be ordinary. If it became a task, polling that task may be safer than submitting a second update. If it committed but one representation remained stale, a second write may add confusion instead of correcting it. None of those outcomes is alleged here. They are the decision branches that the API's documented architecture creates.

MyAPNIC adds another representation. APNIC says API functions map to MyAPNIC: changes to registered routes made through the API appear in MyAPNIC for the account, and changes made through MyAPNIC are visible through the API. A recovered portal page can therefore prove that one read worked. It does not necessarily prove that an earlier task completed, that every cache refreshed, or that the two views reconciled at the same instant.

An incident closure for these interfaces should answer the member's operational question, not merely the network team's device question. “Traffic resumed at 19:18” and “your accepted task is safe to poll rather than resubmit” are both useful statements. They are not interchangeable.

Orbit and FTP do not carry the same persistence promise

APNIC describes Orbit as a community communications platform and an evolution of mailing lists. It hosts announcements, discussion lists, SIG exchanges and archives. A reader may open an archive; a participant may post; a subscriber may receive a message through mail delivery. The service notice names Orbit but does not say which of those paths was interrupted.

That omission is not evidence that a post was lost. It simply prevents one end time from answering all possible user questions. A failed archive read can be retried without creating a second public message. An uncertain post submission needs a visibility check before it is sent again. Delayed mail delivery has yet another completion condition.

FTP sits further toward public distribution. The RIR Statistics Exchange Format says delegated-statistics files are publicly visible, require no access control and are exposed through persistent file names, including a latest path. The format also specifies record counts and validation materials.

Here again, the word “affected” is too broad to describe an object state. A fetch may fail while the published file remains intact. A scheduled file may be generated but not yet reachable through one path. A latest reference and its dated target may update at different moments. The 28 August notice reports none of those conditions, and it gives no basis for claiming that any of them occurred.

The proportionate public result would be a small classification: read interruption only; publication delayed; object unchanged; latest pointer checked; backlog drained; or state unknown. That is enough for a consumer to decide whether to refetch or compare hashes. It does not expose the server layout.

“RPKI affected” contains more than one direction

The RPKI labels make the same issue more consequential, but not more dramatic. APNIC's Certification Practice Statement distinguishes several interfaces. The provisioning protocol supports interactions between a resource certificate issuer and a subject. The publication protocol supports a publisher sending signed products to a repository. Repositories then expose objects to relying parties through rsync and through the RPKI Repository Delta Protocol, or RRDP.

The protocol specifications preserve those distinctions. RFC 6492 defines request/response interactions for resource-certificate provisioning. RFC 8181 defines publication operations between publishers and repositories. RFC 8182 defines RRDP over HTTPS for repository synchronization.

APNIC's notice names provisioning and publication together, then names RPKI rsync separately. It does not name RRDP. The responsible reading is narrow: the listed interfaces experienced interruptions within the incident. The omission of RRDP does not prove that it remained available, failed, sat outside the firewall path or shared the same state by implication.

Nor does an interrupted repository fetch mean that routers suddenly lost their current routing policy. Relying-party software normally works from locally validated material and refreshes it periodically. The public record does not identify validator behaviour, cache age, object expiry, publisher retries or any routing consequence.

The useful post-incident questions are typed. Did a provisioning request receive its matching response? Did a publication operation commit or require a retry? Did the rsync endpoint return to service, and was the exposed object set consistent with the repository's intended state? Was RRDP observed, and if not, is its state deliberately outside this notice? Asking those questions does not presume a bad answer.

The aggregate clock has a legitimate job

There is a strong defence of APNIC's short notice. It is an operational alert, not a forensic report. Eight minutes is a brief event. APNIC named the physical class of trigger, the affected surfaces, the vendor investigation and a failover improvement. Many status notices disclose less.

One infrastructure clock is also useful. It tells incident responders when the fault began and when APNIC considered the event ended. It supports broad availability reporting and lets users correlate their own observations. A public taxonomy that demanded a full transaction ledger before an alert could be posted would delay the alert and create its own harm.

APNIC has already shown awareness of measurement boundaries. Its Q4 2025 availability report combines external probes with user-perspective successful-request and error-rate data, then excludes overlapping periods to avoid counting the same incident twice. That method recognises that endpoint observation and user request outcome are distinct evidence surfaces.

The next step is not a longer apology. It is a later closure object that keeps those surfaces distinct. The alert can remain fast and compact; the operation-state receipt can follow once observations have been reconciled.

A receipt for states, not secrets

The minimum receipt begins with a stable incident ID and keeps APNIC's eight-minute infrastructure window. Under it, each affected interface receives a direction and operation class: member-to-registry update, task poll, community post or read, public-file publication or retrieval, RPKI provisioning, RPKI publication, repository rsync retrieval, and RRDP observation if APNIC chooses to report it.

For each class, the receipt needs only bounded states. Was work not received, rejected before admission, accepted, committed, rolled back, still pending, visible through a named representation, safe to retry, safe only to poll, or not observable? When did the interface recover? Did a queue remain, and when did it drain? Was a cross-representation check completed? Unknown should be a valid value.

Counts can be privacy-safe bands. Evidence can be hashes or internal log references with a public assertion rather than raw member requests. The firewall topology, vendor serial numbers, member identities, object contents, credentials and exploit-sensitive details can remain protected.

This record would not convert APNIC into an auditor of every client. It would clarify the boundary between the state APNIC can observe and the actions users must take. It would also remain correctable. If later log reconciliation changes a class from “unknown” to “accepted and completed”, the new state should preserve the earlier publication rather than erase it.

The 28 August notice closes a device-centred incident at 19:18. That is useful evidence. For a registry write, a community message, a public file and an RPKI repository read, completion is a property of the operation. One clock can index them all. It cannot finish them all by declaration.

Sources