Summary

  • APNIC says an unintended Cloudflare configuration change applied stricter browser integrity checks to RDAP from 27 January 2026 at 15:45 to 28 January at 09:45, UTC+10.
  • During those 18 hours, approximately 10% of RDAP requests with User-Agent strings unlike common browser User-Agent strings were blocked.
  • DDoS and bot protection are legitimate controls. The narrower problem is that RDAP is designed for machine clients, while browser resemblance is only a self-asserted software signal.
  • Four low-rate requests in September—without a User-Agent, with a named automation string, with a curl string and with a browser-like string—all returned the same RDAP JSON. That is a current canary, not proof about every client or the January event.
  • A small edge-to-origin receipt can test supported client classes, response semantics, rollout and rollback without disclosing WAF rules or bypass thresholds.

Eighteen hours on the wrong side of the service

APNIC’s service announcement is unusually direct. The incident began on Tuesday, 27 January 2026 at 15:45 and ended on Wednesday, 28 January at 09:45, both UTC+10. RDAP was the affected service. The duration was 18 hours. APNIC attributed the event to a change in its Cloudflare configuration that unintentionally performed stricter browser integrity checks. Approximately 10% of requests containing User-Agent strings that did not match common browser User-Agent strings were blocked during that time.

That account identifies a control boundary more precisely than the word “outage” does. A request could be syntactically suitable for RDAP, addressed to the right service and made by software behaving like software, yet fail before the registry application supplied its protocol response. The differentiating evidence was not a resource holder’s authority, an authenticated identity, a query’s semantic validity or even its rate. It was how much the caller’s software label looked like a browser.

The distinction matters because an edge block and an origin error are not interchangeable observations. One says the request was classified before the registry service decided it. The other says the service received the request and returned a result. A synthetic monitor that exercises only a browser-shaped client can report health while an automation-shaped client sees a different service. An origin log can look clean while the intermediary has already removed part of the demand.

APNIC did not publish the exact status codes, challenge bodies, locations, User-Agent values or request counts behind the estimate. Nothing in the notice proves that every non-browser client failed, that a particular tool was affected, or that a particular network decision was delayed. “Approximately 10% of requests” is the available denominator. Turning it into a number of users, operators or applications would manufacture facts the notice does not contain.

The strongest defence is at the edge

There is a strong case for the control that failed. A public registry query service attracts automation because automation is one of its purposes; it can also attract scraping, abusive rates and denial-of-service traffic. APNIC has an obligation to keep the service usable, not merely to accept every packet that names the endpoint.

APNIC’s 2020 account of its RDAP infrastructure says traffic for rdap.apnic.net and National Internet Registry RDAP services reaches Cloudflare, which provides load balancing and DDoS protection before proxying requests towards infrastructure in Google Cloud. That design gives APNIC reach and resilience without requiring each origin to absorb every request directly. Edge classification is therefore part of the running service, not an irrelevant layer outside it.

Cloudflare’s Browser Integrity Check documentation describes a related operational purpose. The feature examines HTTP headers associated with abusive traffic and can challenge requests whose User-Agent is missing or non-standard. It is reasonable for a security product to treat a strange header pattern as one risk signal. It is also useful that Cloudflare documents ways to scope or disable the feature selectively through configuration rules.

The conclusion is not that APNIC should remove Cloudflare, turn off bot controls, disclose its filters or allow unlimited queries. None follows from the incident. The fair question is smaller: on a hostname serving a machine protocol, which client classes must reach a protocol-readable disposition, and what test proves that a browser-oriented heuristic has not become the admission rule for all of them?

RDAP is not a website wearing JSON

APNIC’s own 2021 discussion of RDAP explains why the client population cannot be reduced to browsers. RDAP carries structured JSON over HTTP or HTTPS. The response is readily machine parsable. A single client can handle answers from most RDAP services, in contrast with the variation inherited from traditional WHOIS. HTTP caching can make repeated retrieval more efficient.

The IETF specifications lead to the same operating model. RFC 9082 defines uniform RESTful query patterns for domain, nameserver, entity, IP network and autonomous-system data. RFC 7480 defines how RDAP uses HTTP. Browsers are possible clients—the HTTP specification discusses cross-origin access precisely because in-browser applications exist—but they are not the privileged shape of the protocol. Command-line tools, libraries, inventory systems, abuse desks and registry-to-registry processes can all speak HTTP without imitating a graphical browser.

This is where the January classifier crossed the service’s semantics. A browser integrity check is built around a normal form for interactive web traffic. RDAP’s normal form includes unattended programs. Applying the former to the latter does not necessarily reject malformed RDAP. It may reject an honest description of the client class that RDAP was built to serve.

The word “honest” should not be romanticised. A bot can send a browser-like header, and a benign tool can send a sparse one. That is the point. Resemblance is neither necessary nor sufficient evidence of legitimate use. It can contribute to a layered score, but it cannot carry the authority that the classification outcome gives it.

User-Agent identifies software, not mandate

RFC 9110 describes the User-Agent field as information about the software making a request. Its grammar is a series of product identifiers and comments. The field helps servers tailor responses and diagnose interoperability. It is supplied by the client, can be omitted in some circumstances, can be simplified, and can be made to masquerade as another product.

It does not authenticate the operator. It does not say whether that operator is an APNIC member, a researcher, an incident responder or an abusive collector. It does not establish consent, query purpose, rate entitlement or legal authority. A string beginning with a familiar browser product cannot confer those things; a string naming a small script cannot take them away.

That makes User-Agent useful evidence of software and weak evidence of mandate. A protection system may still use it alongside rate, behaviour, reputation and other signals. But when the edge turns a weak signal into a hard gate, clients learn a perverse lesson: the reliable way to use a machine protocol is to lie about being a browser. The classifier then destroys the evidence it hoped to use. Honest automation disappears from the labels while the risky traffic learns the permitted costume.

The incident notice does not say that this was APNIC’s intended policy. It says the effect was unintended. That is an important defence. It turns the episode from an argument about motive into a configuration-control problem: a generic security default or change acquired a scope wider than the service contract.

Rate limiting and bot challenges are different receipts

RDAP does not promise unlimited use. RFC 7481 explicitly treats availability and denial-of-service resistance as security concerns. An operator can throttle a client, use authentication where additional access is appropriate and design controls that preserve service for others. RFC 7480 recommends HTTP 429 for rate limiting; a client should reduce its rate and honour Retry-After when the server supplies it.

Those semantics are valuable because a machine can act on them. A 429 says that the request rate, rather than the caller’s browser resemblance, is the immediate constraint. Retry-After can say when another attempt is sensible. Authentication can separate public access from a service tier whose authority has actually been established.

This does not mean RFC 7480 required APNIC or Cloudflare to return 429 for every request affected by the January security configuration. A bot challenge and a rate limit are distinct controls, and the incident record does not expose enough response detail to classify every block. The more defensible inference is that machine-readable outcomes should remain visible by client class. If a valid automation request is challenged at the edge, the service owner should know that happened even when the origin did not.

Four requests show a repaired moment, no more

On 5 September 2026, a small canary queried https://rdap.apnic.net/ip/202.12.29.0 four times at low rate. Each request asked for application/rdap+json. One supplied no explicit User-Agent. One supplied a purpose-named automation User-Agent. One used curl/8.7.1. The fourth used a browser-like Mozilla and Safari string.

All four returned HTTP 200, content type application/rdap+json, and a 3,857-byte body. The body digest was identical in every case: d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853. The response headers showed Cloudflare on the path.

That is useful present evidence. At that endpoint, from that network path, at that time and at that rate, the four declared client classes converged on the same registry response. It supports the restrained statement that the sampled condition is not reproducing now.

It cannot prove the historical cause independently of APNIC’s notice. It did not test every endpoint, method, geography, edge location, source network or query rate. It cannot prove that no other rule distinguishes clients or that a future configuration change will preserve the equality. A canary is a timestamped observation, not a certificate of universal repair.

A service receipt can be thinner than the security rule

The missing artifact is not a public copy of the WAF. APNIC can keep exact rules, thresholds, reputational inputs and bypass-resistant controls private. What users need is evidence about the externally promised classes of service.

Start with four registry-controlled canaries: a request without User-Agent, a purpose-named automation client, a common command-line client and a browser. Run them through the actual edge and preserve both the edge disposition and the origin disposition. Record status class, RDAP content type and whether a standards-readable retry instruction exists where rate limiting applies. A canary blocked before origin should not vanish into an origin-only success rate.

Add the change lineage: configuration identifier, scope, reviewer, rollout time, rollback time and validation time. The receipt does not need to name a sensitive expression. It needs enough scope to prove that a browser-oriented rule is not unintentionally governing the whole RDAP hostname or path. Publish an aggregate blocked share by supported client class where that can be done without teaching an attacker the threshold.

APNIC already has a user-perspective measurement vocabulary. Its Q2 2025 registry-availability report describes an RDAP check as successful when it produces a non-error HTTP response in under five seconds, with availability calculated as successful tests divided by total tests. A client-class dimension would make that perspective more representative without discarding the existing measure.

APNIC’s Q1 2026 secretariat update says all core registry services met or exceeded 99.99% availability. The summary does not provide the denominator or detailed method needed to reconcile that sentence with an 18-hour event affecting an estimated share of RDAP requests. It would be wrong to declare the statement false. The useful response is to publish the measurement join: which client classes, which edge outcomes and which service intervals enter the number.

What this incident does not prove

No evidence reviewed here shows that APNIC’s RDAP is currently unavailable, that every machine client was blocked, or that an identifiable operator suffered a specific loss. No public source supplies the exact block response, the affected User-Agent list or the security threshold. The September canary is too narrow to fill those gaps.

Nor does the incident establish that APNIC or Cloudflare ignored an RFC. Standards define protocol behaviour and useful error semantics; production security controls sit around them and require local judgement. The operational failure APNIC acknowledged was an unintended configuration effect. The accountability question is whether APNIC can demonstrate, in the running chain, that the effect remains bounded and detectable.

That is enough for a serious conclusion. A public machine protocol should not have to dress as an interactive browser to cross its first control point. The solution is not trust in a label or hostility to the edge. It is a receipt that keeps protection, client class and protocol outcome separately observable.

Sources

  1. APNIC, Service Announcement: 28 January 2026
  2. APNIC Blog, A new infrastructure to serve RDAP
  3. APNIC Blog, Is RDAP ready to replace whois?
  4. APNIC Blog, APNIC registry services availability during Q2 2025
  5. APNIC Blog, APNIC Secretariat Q1 2026 update
  6. Cloudflare Docs, Browser Integrity Check
  7. RFC 7480, HTTP Usage in RDAP
  8. RFC 7481, Security Services for RDAP
  9. RFC 9082, RDAP Query Format
  10. RFC 9110, HTTP Semantics