Summary

  • RIPE NCC’s new RISwhois-rs gives a two-decade-old route lookup its first test suite and cuts scheduled data refreshes from eight hours to one.
  • The service still answers a specific question: which prefixes and origin ASes RIPE RIS has observed, at which collectors and when. The public record has not yet shown the test inventory or a migration plan.

A familiar question, asked in a very old accent

whois -h riswhois.ripe.net 193.0.0.1 is not the sort of command that wins a design award. It is the sort of command that gets the answer onto a terminal before anybody has opened a dashboard. Since 2003, RIPE NCC’s RISwhois has given operators a quick lookup over BGP data collected by RIPE’s Remote Route Collectors. Its output looks like RPSL, the language many network people already know how to read.

That interface has now received a new engine. At RIPE 93 on 26 October, RIPE NCC developer Sam van Kampen presented RISwhois-rs, a successor built over the preceding months. RIPE NCC’s daily meeting report says the old service had no test suite, a gap that limited development. The team has added one.

The release has an unusually good punchline: the registry’s first production Rust service is a WHOIS-style query tool. A protocol older than most cloud platforms has acquired a newer engine, and the people maintaining it can finally change code with a set of checks instead of crossing their fingers over every edit.

What the answer contains

RISwhois sits on top of routing observations. A query for an address, prefix or ASN can return matching route prefixes, origin ASNs, the collectors where a route was seen, update timestamps and the number of RIS peers that observed it. The -R option can add RPKI origin-validation information. A traceroute tool can also use a WHOIS server to attach ASN information to hops.

The format is part of the product. An operator does not need to learn a new web interface to ask whether RIS has seen a route. A command-line client can request the familiar object-like response over port 43. That small compatibility promise is what turns an internal data set into an operational instrument: a script, a human or a diagnostic tool can use the same doorway.

The doorway was deliberately plain from the start. RIPE NCC’s November 2003 announcement described ten route collectors and more than 200 IPv4 and IPv6 peers. The service combined their recent routing-table snapshots to show where a prefix appeared and which AS originated it. The purpose was not to reproduce the registry’s record of what someone had registered. It was to make the route collectors’ view queryable in a format that existing tools could understand.

A RISwhois result records what participating collectors received, where they received it and when. Operators can line that outside view of announced routing up with their own telemetry and ask a useful question: which collector saw which route, and at what update time?

A fresher snapshot, not a live feed

The scheduled snapshot now ages less between refreshes. During a routing change, a query can move from “this was in the last scheduled view” toward a more recent observation, provided the route was received and included by the relevant collectors.

That is a practical change for incident work. An operator checking whether a new announcement has appeared can run the query again without waiting through most of a work shift. A support engineer comparing an observed route with an origin-validation result gets a fresher RIS snapshot. A monitoring job can make decisions on a shorter data clock.

RIS Live is RIPE NCC’s near-real-time stream of BGP messages. RISwhois is the scheduled query service: ask about an address, prefix or ASN and inspect the routes its collectors observed. One follows incoming messages; the other gives operators a compact view over collected routing data.

RIPE NCC also publishes compressed IPv4 and IPv6 summaries over HTTPS as dump and dump6 files. The server generates them on request, so each downloaded file has its own generation time; the service’s scheduled refresh is a separate clock. Anyone comparing a bulk file with a later query needs both timestamps, or the comparison starts with the wrong clock.

Tests change the cost of touching old software

“There was no test suite” is a small sentence with a large maintenance shadow. RISwhois accepts several query forms, emits a structured response, carries compatibility options, and can include RPKI validation fields. Each behavior gives a future edit somewhere to go wrong. Without repeatable tests, maintainers must rely more heavily on manual checks and a cautious appetite for change.

A test suite gives maintainers a place to state which behaviors they intend to preserve and to recheck them whenever the implementation changes. For a command-line service, useful cases would include address and prefix lookups, exact and more-specific matching, IPv4 and IPv6 output, persistent connections, peer counts, timestamps, RPKI fields and malformed queries. The official meeting post does not publish this list, so readers cannot yet see which parts of the compatibility surface the tests cover.

Rust is part of the same maintenance story. RIPE NCC called RISwhois-rs its first production Rust service and said the language offered a low barrier to doing things properly. The report names speed, maintainability and extensibility as goals. It publishes no measured latency comparison, repository link or test result.

The useful result is the new release discipline: a test suite now sits beside an implementation that can be developed more actively. Hourly refreshes are the visible operational change. Tests are the less visible change that may make future improvements cheaper to review and safer to ship.

The next release note should show its work

RISwhois has made a quiet promise for two decades: ask in an old language, get a concise view of new routing evidence. RISwhois-rs keeps that bargain while giving the service a modern implementation and a shorter refresh interval. That is a sensible upgrade for a tool used to interrogate an observation system.

The next useful public record would name the production cutover date, describe whether clients need to change, list the query and output cases covered by the test suite, and publish the measured query-latency comparison. A versioned compatibility note would let operators check their scripts before the old service disappears. These are concrete release facts; they are also the difference between “we rewrote it” and “you can trust what changed.”

Primary records: RIPE NCC’s RISwhois launch announcement, 2003 · current RISwhois documentation · Sam van Kampen’s RIPE 93 session · RIPE 93 daily meeting report, 26 October 2026.