Summary

  • A 10 September RIPE NCC Whois commit makes the NRTMv4 service enumerate and validate sources through NrtmSourceSlaveDao, backed by the read-side datasource.
  • The source-aware notification DAO can retry the master after an empty payload lookup, but the service first resolves the source through the replica; a missing catalogue row therefore never reaches that fallback.
  • This is a code-order observation, not evidence of deployment, replica lag or an outage. A source-catalogue admission receipt would cover the narrow transition without abandoning the read replica.

The interesting part of commit 252681a0865d5a10dbcfeaeeaf81bf33ef2c3855 is not that a service reads from a replica. Mature systems do that constantly. The interesting part is where the fallback begins.

RIPE NCC’s public Whois repository records the change at 10:56 UTC on 10 September 2026 under the plain title “Use read-only (slave) source DAO in NRTMv4 Service”. It touches three files. The existing NrtmSourceDao becomes Spring’s primary implementation. A 20-line subclass, NrtmSourceSlaveDao, passes nrtmSlaveDataSource into the same query logic. NrtmService then replaces the former DAO type with that subclass.

There is a strong defence for this design, and it belongs before any criticism. The source catalogue is small. Its configured names change much less often than clients fetch publication material. Sending repeated public reads away from the primary can reduce contention and keep serving concerns apart from the write path. NRTMv4 itself is not cavalier about evidence: its Update Notification File is signed, its snapshot and delta references carry hashes, and its session and version rules let a client detect discontinuity and reload.

The code also already contains a source-aware notification lookup that retries against the master when an empty result came from a slave context.

That is a considerable control surface. It is also why the remaining gap can be described without melodrama.

Two uses of one catalogue

NrtmService consults the new DAO in two places that matter here. Its root HTML handler calls getSources() and constructs one Update Notification link for every source returned. Its file handler uses the same DAO to turn a source name from the URL into an NrtmSource object. If no row with that name appears, the private getSource() method throws an “Invalid source” bad request.

For an Update Notification request, the relevant expression is compact: the service calls findLastNotification(getSource(source)). Java must evaluate getSource(source) before it can invoke findLastNotification. The catalogue query therefore decides whether the second component is allowed to start.

The second component is deliberately defensive. UpdateNotificationFileSourceAwareDao asks for the latest notification payload. If the result is empty and its current source context is a slave, it temporarily selects the corresponding master, repeats the payload query and restores the original context in a finally block. This is a proper fallback for the case it was written to handle: a known source exists, but the latest notification record is not visible through the first context.

It cannot handle a source that the earlier DAO did not return. No NrtmSource object reaches it. The fallback is downstream of the gate.

The distinction is easy to miss because “read from the slave, fall back to the master” sounds like a property of the whole request. In the public code it is a property of one later lookup. The root listing has no equivalent retry. The direct notification path has a retry for payload absence, but only after source-name admission has succeeded.

The transition case, not the steady state

This does not make an established feed suspect. The captured DAO constructor receives the configured main and non-authoritative source names, and catalogue rows for a settled service are likely to be long lived. If those rows are already present on the serving replica, source enumeration and validation proceed normally. The notification lookup then retains its own fallback. Nothing in the repository proves that the current source rows are absent, delayed or inconsistent.

The meaningful boundary appears when state changes. A source could be introduced, recreated, restored after a datasource event or admitted after a configuration change. For some interval, a primary may know the source while the serving replica does not. At the root page, that source would simply not be offered by the captured code. On a direct Update Notification request, the name would be rejected before the payload fallback. Those are consequences of control flow if the premise occurs; they are not observations that it has occurred.

The public commit also does not prove production deployment. It is not enough to find code on a main branch and describe a live incident. There is no captured release mapping, no observed response, no replication metric and no affected client in this evidence package. Calling this a vulnerability would be especially misleading. The boundary concerns rollout readiness and the location of a check, not unauthorised access.

The narrowness matters. It keeps a useful engineering question from turning into a generic complaint about replicas. Read replicas are not defective versions of databases. Their contract is usually bounded staleness or asynchronous convergence. The governance task is to decide which events are safe under that contract. High-volume reads of stable catalogue state can be. Activating a new public source is a different event because it changes what names the service will admit.

What the protocol already proves

Revision 11 of the NRTMv4 Internet-Draft describes a one-way synchronisation protocol for Internet Routing Registry records over HTTPS. A publication has one Update Notification File, an active Snapshot File and zero or more Delta Files. The notification states the current database version and points to the snapshot and deltas.

The notification is a JSON Web Signature object. A client is configured with its URL, an IRR database name and a public signing key. The signed payload contains the hashes of the referenced files. Clients verify the source name, the signature and the SHA-256 hashes. A session_id scopes monotonically increasing versions; when the session changes, a client must reload from the newest snapshot rather than silently assume continuity across a lost history. Snapshots and deltas are immutable for a session and version.

These rules answer serious questions. Did this notification come from the expected signer? Does the downloaded snapshot match the signed reference? Are deltas continuous within this publication session? Should the client abandon incremental recovery and reload?

They do not answer an earlier server-side question: had the catalogue row that admits the source reached the datasource used by the HTTP service when activation began? A client cannot validate a signed publication it is not yet allowed to request. Nor should the wire protocol have to carry the entire deployment topology of its publisher. This is an internal admission invariant, not a proposed NRTMv4 extension.

Admit a source with a receipt

The least disruptive response is a source-catalogue admission receipt. It can remain private, with only aggregate readiness made public if there is an operational reason. Its job is to convert a timing assumption into a completed step.

For each source activation, the receipt would record the source name and rollout generation; the primary-side approval or creation time; the serving datasource expected to answer catalogue queries; a replica observation time or comparable readiness watermark; and the first successful retrieval of a valid signed Update Notification through the intended serving path. It would attach the session and version observed, a reference to the active signing key, a root-listing check and a direct-path check. An approver, activation time, rollback condition and supersession link would close the record.

There is no need to expose database hostnames, replication offsets, row identifiers or credentials. A statement such as “serving catalogue observed generation X before source Y was activated” is the useful fact. The underlying measurements can remain restricted.

The activation rule can be equally modest: create or approve the source on the write side; wait until the catalogue is observable on the datasource used by NrtmService; retrieve and verify its first signed notification through that path; then expose it. If readiness does not arrive within a defined window, hold activation or temporarily use an explicitly authorised lookup path. Do not make the later notification fallback carry a responsibility it does not currently have.

Tests should mirror the boundary. One integration test can arrange for the master catalogue to contain a new source while the slave catalogue does not and confirm the chosen behaviour—held activation, a bounded catalogue fallback or another explicit response. A second can make the source visible while withholding the notification payload and confirm that the existing notification fallback still works. Those are different states and deserve different assertions.

This receipt also avoids a worse design reaction: moving every catalogue query back to the primary because one transition needs coordination. Control should be placed at the low-frequency event that changes the admissible set, not taxed onto every high-frequency read.

Sources