The WHOWAS query service takes historical data imported from the RIPE database
last and history tables and produces an INR and timestamp indexed list of
RDAP objects, and exposes an API to serve RDAP-like responses.
docker build -t whowas-server .
# And have some patience…
docker run --name whowas-server -d -p 80:8080 whowas-server <arguments>
# And probably have more patience…
You may wish to mount a volume with application.properties to further configure
the server, or provide command line arguments with property settings.
The server will need to load some data before it can usefully start up. Data can be loaded directly from a RIPE database, or from a snapshot file.
The server is very memory-hungry; the docker container by default will allocate a 10G heap, and the typical runtime space requirement for the history of APNIC is between 5G and 8G.
Provide an application.properties file or suitable arguments to configure a Spring
data source. See the test properties
for an example.
See below for how to create a snapshot file.
Provide an application.properties file or suitable argument to set the snapshot.file
property to some (volume mounted) file a snapshot may be read from. If the snapshot
cannot be read, the server will fall back to attempting to read from a RIPE database,
and so you may use a snapshot to speed up the start time of a server, and reduce the
load on the database instance.
Snapshots may be written to the location given by the snapshot.file property by
invoking the snapshot actuator endpoint, either using HTTP over the management
port (by default, this is port 8081, which is not exposed by the above docker command)
or using JMX (not exposed by default).
Snapshots only make sense if data has already been loaded from a RIPE database.
- The server never refreshes itself, so once it's started up, it's serving a static view.
- Snapshotting and restarting will update to the latest data in the database
- IPv4, IPv6, and entity URLs work, domains and aut-nums do not.
- Searching for 0/0 is slower than it could be
For each object type, the service will create an "applicable date range" from the time of the object's change until the time of the next object with the same key is encountered, as a left-closed interval.
Next, for the Internet number resource object types, recursively for each
referenced additional object, the date range will be split for each date
range at which there's an interval for the referenced object. That is, if
some inetnum holds between times person object it refers
to has two periods inetnum records created with the two different person object
values assigned respectively. This will continue until all referenced objects
have been accounted for.
Finally, these related collections of WHOIS objects will be converted to their equivalent RDAP representations, and stored in an AVL tree.
This tree can be queried through a simple web responder.