Dear colleaguesm
We have deployed Whois release 1.123 to the Release Candidate (RC) environment for testing. We plan to deploy to production on Wednesday 8th July.
The Whois 1.123 release contains the following changes :
* Fix version query encoding (port 43 should use latin-1 by default) and support charset flag with version flags
* Improved resiliency to API keys backend failures and improved logging
* Normalise decomposed Unicode in descr: or remarks: attributes
* HTTP APIs use UTF-8 encoding by default
* RDAP Relation Search uses domains not domain element
The full list of changes can be found in the source repository:
https://github.com/RIPE-NCC/whois/compare/e93028c...d75e67c
The data in the Release Candidate environment is a dummified copy of production from 21st June.
For more information about the Release Candidate environment :
https://docs.db.ripe.net/Release-Notes#release-candidate-environment
Please let us know if you find any issues with this release in the RC environment.
Regards
Ed Shryane
RIPE NCC
Dear colleagues,
Some of you will remember me from my years on the NCC's Database team. This
time I am writing from the other side of the table, as a resource holder,
with an idea I think is worth the WG's consideration.
The ask in one paragraph: let a resource holder optionally tell the RIPE
NCC's RDAP service to refer queries for the more-specifics of their space
to an RDAP server the holder runs, and let clients optionally follow that
referral. Nothing is mandatory on either side. A holder that offers nothing
behaves exactly as today, and a client that does not follow simply sees the
covering object, as today. It is the RDAP analogue of the reverse DNS
delegation we already do with domain: and nserver:.
Why this matters: an RDAP walk that starts from the IANA bootstrap (RFC
9224) and reaches https://rdap.db.ripe.net/ stops at the covering
allocation. If the holder maintains a large, dynamic set of more-specifics
and runs a conformant RDAP server for them, there is no way for the RIPE
response to hand the client down to it.
The last hop is undiscoverable unless you already know the holder's server
exists. RDAP is meant to be walked, not memorised, so that hop ought to be
discoverable too. And I should say this is not theoretical for me: we
publish per-assignment registration data for our own space from our own
RDAP server, and running into exactly this gap is what prompted this mail.
The real prize, I think, is registration data hygiene. A holder with a lot
of assignment activity has two poor options today. Register nothing below
the allocation, which leaves coarse, unhelpful data for abuse handling,
research and routing. Or bulk-load large numbers of assignment objects that
start drifting out of date the day they land, which means stale data and
central database bloat. An optional referral to the place where the data is
actually maintained gives the community accurate, current, granular
registration data served from the source, keeps the central database lean,
and preserves an unbroken, machine-walkable chain from the bootstrap to the
exact object. It rewards holders for publishing good, live data rather than
penalising them for it.
The principle is not new for us, only the object of it is. Registrants
already maintain their own sub-allocation and assignment data directly.
Reverse DNS for the same space is already delegated to the holder's
nameservers. And the WG has handled referral concepts before: we retired
referral-by: at RIPE 68, though that was an authentication-time mechanism
that had stopped earning its keep, which is a different animal from a
data-locality referral, and domain referrals go back to the late-90s
threads on this list. What has changed is that the standards now express
this cleanly, so there is little to invent:
* RFC 7480 section 5.2 already lets a server that is not authoritative
answer with a 30x and a Location header. The redirect primitive exists.
* RFC 9910 (RDAP RIR Search, Standards Track, January 2026) defines the
rdap-up and rdap-down relations for navigating the number hierarchy, and
rdap.db.ripe.net already emits these today. An rdap-down or related link to
the holder's base URL is a natural carrier for the referral, with the
holder's server publishing rdap-up back to the RIPE object so the hierarchy
stays consistent and loop-safe.
* regext is actively working on explicit RDAP referrals right now
(draft-ietf-regext-rdap-referrals, "Explicit RDAP Redirects", -04, July
2026): a client can ask to be redirected straight to a related RDAP record,
and the draft's own examples already cover IP space. It is early, but it is
the natural vehicle for the down-referral, and IP-space input from this WG
would land at exactly the right time.
So the genuinely new part is a member-facing, opt-in way to register that
base URL (scoped strictly to the holder's own space, TLS only), plus the
NCC emitting an already-standardised referral.
Where I would love the WG's steer: is there appetite for an optional,
member-configurable RDAP referral for more-specifics, built on the
referrals work above rather than anything bespoke? If there is, I am glad
to take it forward as a concrete RIPE NCC feature request and/or a slot at
the next db-wg session, and to keep it aligned with the NRO and regext so
it stays consistent across RIRs. I can also prototype the down-referral
against a live, conformant server that already publishes the up link back
to the RIPE object.
All the best,
Kaveh
