Summary

  • APNIC’s 5 August 2026 notice says a configuration-change problem made api.apnic.net unavailable from 09:52 to 10:51 UTC+10, a stated duration of 59 minutes.
  • The notice names APNIC Login, the APNIC Conference Website, MyAPNIC, the APNIC Website and Membership Applications as affected. It does not name the separately published host registry-api.apnic.net.
  • APNIC’s Registry API specification describes the hyphenated host as an authenticated, state-changing interface for Whois, reverse DNS and route records, plus delegation retrieval. Nothing in the frozen record establishes whether it was up or down during the 5 August event.
  • A useful incident record therefore needs a stable service identity, function and authority class, not just an umbrella label such as “API.” Unknown dependency and integrity states should remain explicit rather than being filled by inference.

One hyphen changed the unit of the claim

The smallest fact in APNIC’s 5 August service announcement is also the most consequential. The hostname in its cause statement is api.apnic.net. The hostname in APNIC’s live Registry API specification is registry-api.apnic.net. They differ by the word “registry” and one hyphen.

That textual boundary matters because the two public descriptions attach different authority to the names. The 5 August service announcement says a problem with a configuration change caused api.apnic.net to become unavailable. It records a start at 09:52 and an end at 10:51 in UTC+10. It lists five affected services. APNIC also says it was improving monitoring and introducing further safety measures around configuration changes.

This is useful disclosure. It gives readers a clock, a proximate change class and an enumerated impact surface. It avoids the empty phrase “technical issue.” The notice still leaves one operational question unresolved: what authority did the named host exercise for each listed service?

The word “API” cannot answer that question. It describes a way for software to interact, not what the interaction is allowed to do. An API can serve public information, broker an identity session, submit a membership form, display a conference programme or alter registry records. Those functions carry radically different recovery priorities and integrity risks. A status notice that identifies only the class of interface asks the reader to supply the missing authority from context.

In this case, context is unusually dangerous because APNIC publishes a different service whose name contains the same letters and whose documented powers are much greater. A reader who shortens both hostnames to “APNIC API” can accidentally turn a five-service access incident into a registry incident. Another reader can make the opposite mistake and assume that the absence of the hyphenated hostname proves it was unaffected. The public evidence supports neither shortcut.

The notice names five surfaces, not one system

The five affected entries are not interchangeable labels. APNIC Login is an identity surface. The current MyAPNIC service page describes MyAPNIC as the secure portal through which members manage Internet resources, records, routing and DNS security, accounts and contacts. Membership Applications is an intake workflow. The APNIC Website and Conference Website are public-information surfaces with different audiences and publishing rhythms.

The notice puts them in one incident list, but a list is not a topology diagram. It does not say that every service was wholly unavailable for the entire 59 minutes. It does not identify which one detected the fault first, whether they all depended directly on the named host, or whether some experienced a secondary symptom. It gives a blast-radius statement at the product-name level, not a dependency graph.

Historical APNIC material helps define the vocabulary but cannot fill the current diagram. The 2020 article “MyAPNIC is changing” describes APNIC Login as an identity-management platform implementing single sign-on and says more systems would be connected. The 2021 product review records MyAPNIC’s move towards microservices and preparations for a new SSO platform. Those are dated architectural observations. They do not prove the production dependency paths in August 2026.

That boundary is important for accountable reporting. “APNIC Login affected MyAPNIC” may be a reasonable hypothesis. It is not an observed relation in the incident notice. “Five services were listed as affected” is observed. A mature status record should carry both kinds of information without allowing one to masquerade as the other.

APNIC documents a different interface for registry authority

The live APNIC Registry API OpenAPI document supplies the authority contrast. It calls the product “APNIC Registry API,” gives the server as registry-api.apnic.net, and documents functions for managing Whois, reverse-DNS and route records and retrieving delegation details. State-changing submissions are handled as asynchronous tasks. APNIC’s APNIC 58 product-demonstration page also points users to that hostname and describes changes involving Whois, RPKI and reverse DNS.

These are not powers that should be casually imported into another hostname. The registry interface sits close to the authoritative records by which a member describes resource contacts, reverse delegation and routing intent. An availability problem there can have a different meaning from losing a conference page or a login screen. Even where a portal eventually invokes the same underlying business operation, the public endpoint, authentication boundary, submission semantics and recovery evidence remain different.

APNIC’s own service reporting demonstrates that it can name the distinction. Its separate 28 August service announcement explicitly includes registry-api.apnic.net in an affected-service list. That later notice is not evidence about the 5 August system state, and its incident analysis belongs elsewhere. It is relevant only because it shows that the hyphenated hostname is part of APNIC’s public operational vocabulary.

The correct conclusion is deliberately narrow. The 5 August notice did not name that host. The source package does not say whether Registry API requests succeeded, failed, were tested or depended on the same changed configuration. “Not named,” “not observed,” “not tested” and “unaffected” are four different states. Only the first is established here.

Availability without authority is an incomplete status

Operational readers do not all ask the same first question. A conference attendee wants to know whether a programme page will load. A prospective member wants to know whether an application was accepted. A network operator wants to know whether a route object or reverse-DNS update entered the registry. A security team wants to know whether the incident affected confidentiality or integrity, rather than availability alone.

A single label cannot serve all of them unless it has a stable definition behind it. The missing object is not a larger narrative post-mortem. It is a small service-identity receipt that can be read by a person and compared by a machine.

For each affected surface, the receipt should publish a stable service ID, public hostname, human label, function and authority class. The authority vocabulary can remain compact: public information, identity, workflow intake, registry read, registry write, or another controlled value. It should then record the observed state and observation point. If a service was inferred to be affected through a dependency rather than measured directly, that inference needs its own field and confidence.

The same record should preserve start, detection, mitigation and restoration times instead of forcing one interval to represent every operation. That does not repeat the separate lesson of APNIC’s 28 August firewall event; it makes timing subordinate to a correctly identified service. A clock attached to the wrong unit is precise but not informative.

Integrity and data-loss states deserve explicit nulls. The 5 August notice makes no claim of lost or corrupted records. A status schema should therefore say unknown or not observed, whichever the operator can support, rather than leaving readers to interpret silence as reassurance. It should also distinguish a service restored to users from a dependency whose health has merely been inferred.

Finally, the receipt needs an evidence cutoff and correction history. Product names and architectures change. APNIC’s own 2020 and 2021 descriptions show that identity and portal designs evolve. A dated map does not pretend to expose permanent internal topology; it lets readers know which public contract was current when the incident statement was made.

The useful disclosure is small

There is a reasonable security limit. APNIC need not publish credentials, internal addresses, exploit-relevant settings or private failover design. A service map can expose function and authority without exposing implementation. In fact, a deliberately small public contract is easier to keep accurate than a decorative architecture diagram.

The test is local and deterministic. Given an incident ID and a public service ID, can a member determine which hostname and authority class were observed, which named surfaces were affected, which relationships were inferred, and which material states remain unknown? If the answer requires guessing what “API” means, the record is not yet complete.

APNIC deserves credit for publishing the 59-minute interval, the configuration-change connection and the five affected services. The next improvement is not a broader promise. It is one line of identity for each line of impact. One hyphen should not carry the whole burden of separating a login and website incident from a possible registry-authority incident.

Sources