Summary

  • APNIC’s public status history records the RSC verifier under maintenance from 01:30 to 02:45 UTC on 6 October, while a rollout strategy was being changed.
  • At 02:45 the incident was marked complete; the status RSS recorded the verifier as operational with a reported average response time of 780 milliseconds.

The status history for APNIC’s rsc-verifier.apnic.net records a 75-minute maintenance window on 6 October. Its in-progress notice said the endpoint might be unavailable while APNIC changed the rollout strategy. At 02:45 UTC, the record moved to “Maintenance completed.” The status feed logged the component as Operational at the same time and attached a 780-millisecond average response time.

That is a service-state change, not a release note. The public record does not name the software version, explain what changed in the rollout, count affected users, report failed checks, or describe an acceptance test. The 780-millisecond figure is one status-feed statistic at the end of the window, not a service-level guarantee or proof that every user could validate an object.

The distinction matters because the public verifier is only one way to check an RPKI Signed Checklist. APNIC describes an RSC as an RPKI object through which a resource holder can sign files or documents with a certificate associated with specified IP resources or ASNs. A recipient can verify that signature locally with rpki-client or use APNIC’s public online service. The verification endpoint makes the process accessible; it is not the source of the signature’s authority.

The maintenance record therefore supports a narrow conclusion: APNIC’s public RSC verification endpoint entered a planned maintenance state and was reported operational at the stated end. It does not establish that signing, certificate issuance, repository publication, ROA processing, or BGP routing was interrupted. Nor does it show whether any particular RSC could or could not be checked during the window. Local verification remains a separate path, subject to a user having a suitable tool and the necessary RPKI data.

That boundary is useful beside APNIC’s other recent service notices. A 1 October announcement described a separate load-balancer error affecting eight services, including the RSC verifier; the public sources reviewed do not connect that event to the 6 October maintenance. A later notice for 13 October concerned a different endpoint, the RPKI rsync service. Dates and components matter: these are not one continuous outage.

For operators using RSCs in BYOIP, onboarding, or other proof-of-resource workflows, an online validator can reduce friction for a counterparty. A resilient process should still state whether the counterparty accepts local validation, which implementation it trusts, what resource scope it checks, and how a result is retained. That turns a website’s availability into an access question instead of making it an unstated cryptographic dependency.

Sources