- db-wg - mailman.ripe.net

Whois 1.124 Release
by Edward Shryane 13 Aug '26

13 Aug '26

Dear colleagues, We have deployed Whois release 1.124 to the Release Candidate (RC) environment for testing. We plan to deploy to production on Thursday 27th August. The Whois 1.124 release contains the following changes : * Added support for OIDC 2.0 authentication * NRTMv3 server should skip invalid objects * Do not unescape characters in UTF-8 substitution * Added Content Security Policy (CSP) header * Added HTTP Strict-Transport-Security (HSTS) header * Added text/plain responses to Versions API * Added unformatted responses to Versions API The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/compare/c0593407...9095208c The data in the Release Candidate environment is a dummified copy of production from 11th August. 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

1 0

Resolved: NRTM issue affecting reverse DNS provisioning
by Mahesh Aggarwal 13 Aug '26

13 Aug '26

Dear colleagues, Between 00:06 on 2 August and 12:30 (UTC) on 4 August, we experienced an issue affecting our Near Real Time Mirroring (NRTM) service. Since our reverse DNS provisioning system also uses NRTM, updates to the global DNS were delayed over this period. All pending updates were processed once we applied a fix to the NRTM issue. We plan to publish a brief post-mortem report with more details soon. You can always check the status of our services at status.ripe.net <http://status.ripe.net/>. Kind regards, Mahesh Aggarwal RIPE NCC

2 1

Whois 1.123 Release
by Edward Shryane 08 Jul '26

08 Jul '26

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

1 1

Optional RDAP referral to a holder's own RDAP server for more-specifics
by Kaveh Ranjbar 06 Jul '26

06 Jul '26

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

3 4

Replacing well-known passwords in the RIPE and TEST databases
by Edward Shryane 21 May '26

21 May '26

Dear collegaues, There was a comment during this morning's DB-WG session that the well-known password for LIM-MNT (the Limericks Working Group Maintainer) in the RIPE database has been replaced. Apologies this has not been properly documented. Now the LIM-MNT has two new auth: attributes: * auth: PGPKEY-EB331265 * https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=PGPKEY-EB331265&t… * auth: X509-3861 * https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=X509-3861&type=ke… Both key-cert objects contain the private key in remarks: attributes, so you can use either to authenticate as LIM-MNT. Separately, we have also added auth: attributes to the TEST-ROOT-MNT maintainer in the TEST database, so users can bootstrap their objects there. * auth: PGPKEY-2B4DEF0D * https://apps-test.db.ripe.net/db-web-ui/lookup?source=test&key=PGPKEY-2B4DE… * auth: X509-1 * https://apps-test.db.ripe.net/db-web-ui/lookup?source=test&key=X509-1&type=… Both key-cert objects also contain the private key in remarks: attributes, so you can authenticate as TEST-ROOT-MNT. We will update the DB documentation with this information. Regards Ed Shryane RIPE NCC

1 0

RIPE91 Database Working Group Minutes
by Peter Hessler 21 May '26

21 May '26

Hello Database Working Group, The draft minutes from our session at RIPE91 has been published on the RIPE website, available at https://www.ripe.net/community/wg/active-wg/db/minutes/ripe-database-workin… We'd like to thank Antony from the RIPE NCC for preparing the draft. Please review the minutes, and send any necessary corrections to the working group mailing list. Peter Hessler, On behalf of the DB WG Co-Chairs

1 1

Whois Release 1.122.1
by Edward Shryane 14 May '26

14 May '26

Dear colleagues, We have just released RIPE database release 1.122.1 to the production environment. The only change from release 1.122 is a fix to add a size limit to RDAP relation search queries. We did not wait for the usual 2 week testing period in the RC environment because receiving many such queries at once can impact the production service for other users. Regards Ed Shryane RIPE NCC

1 0

Public ENUM article and RIPE 92 Services WG discussion
by Hisham Ibrahim 12 May '26

12 May '26

Dear colleagues, I wanted to share an article on the current operational status of Public ENUM under e164.arpa. The article is based on a 2026 operational review carried out by the RIPE NCC and looks at the status of current delegations and the questions this raises for the future support of Public ENUM. I plan to present this topic during the Services Working Group session at RIPE 92, where I hope we can discuss the findings and possible next steps with the community. Article: https://labs.ripe.net/author/hisham_ibrahim/operational-review-of-public-en… Best regards, Hisham

1 0

Call for co-chair volunteers
by David Tatlisu 11 May '26

11 May '26

Hi Everyone, My current term as a DB-WG co-chair will expire at RIPE 92. To me it's a little hard to believe how quickly time passed, and looking back a lot has changed. As per the chair selection process any member of the RIPE community may stand for chair. If you have any questions about the experience, training opportunities or would like to express your interest in this position, please contact the chairs at db-wg-chairs(a)ripe.net *by 21 April. *Kind regards, David On behalf of the Database WG Chairs.

6 6

NWI-21: "Registration Number" Implementation Plan
by Edward Shryane 05 May '26

05 May '26

Dear colleagues, Following is the implementation plan for the NWI-21 "Registration Number" feature. We plan to go live with this feature on Thursday 30th April, in time for the RIPE 92 meeting in May. Introduction ------------ Adding a registration number to organisations in the RIPE Database was proposed by Marco Schmidt at the Address Policy session at RIPE 91. See slides 14 to 17 : https://pretalx.ripe.net/media/ripe91/submissions/FJ7YSH/resources/RIPE91_U… Following the RIPE Meeting, a Problem Statement was published to the DB-WG: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/77NQDFTMHLIOLE… Following the discussion, consensus was declared on the Problem Definition and the Solution Definition was agreed by the Database working group: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/6S5ZIQ4TTCPNQF… RIPE Database ------------- The Database team is responsible for adding a new "reg-nr:" attribute to the organisation object template in the RIPE database. The attribute will only be added to organisations co-maintained by the RIPE NCC and cannot be modified by the organisation’s maintainer. The value is free text, as the value will vary by registry. The "reg-nr:" attribute will be visible in filtered Whois query responses and will be included in the nightly database dump files once we have finalised updating the relevant documentation.. RIPE Database Web Application ----------------------------- The Database team will add the "reg-nr:" attribute to organisations in query and lookup responses, and will be highlighted as a RIPE NCC managed attribute. As "reg-nr:" is a RIPE NCC managed attribute, users will not be able to add a "reg-nr:" to an organisation object themselves. The web application will not provide a link to a registry website. After internal review, it was decided that this would introduce significant complexity and would require ongoing maintenance effort considering that registry platforms and URLs can change over time. Registry Team ------------- The Registry team is responsible for validating the existing registration number data before it is published. The data should be consistent, where possible, for each national or regional company registry. Also, the Registry team is responsible for ongoing updates to the registration number. Internal Registry Software -------------------------- The Software Engineering team is responsible for synchronising the registration number from the internal registry to the RIPE database, after the Registry team has performed its validation. The software will perform the following validation for an organisation’s registration number: * Not have any leading/trailing whitespace * Only consist of Latin-1 characters * Not contain a "#" (reserved for a comment in RPSL) * Maximum length 60 characters If the organisation is a natural person or government entity, then "reg-nr: Not Applicable" is published. Regards Ed Shryane RIPE NCC

7 12