- db-wg - mailman.ripe.net

Last call for feedback for NWI-20 (Updating contact method requirements and adding new ones)
by David Tatlisu 06 Apr '26

06 Apr '26

Hi Everyone, After a lot of lively discussion just before RIPE 91, and a short presentation at RIPE 92 it appears that the community is largely in favor of this proposal. Behind the scenes, Ed and his team are ready to start the implementation. Should you have any input on this proposal, please post it before *11 April 2026. *Kind regards, David On behalf of the Database WG Chairs.

1 0

Extending API Keys
by Fallon Albrecht 01 Apr '26

01 Apr '26

Dear colleagues, We are extending the API key model introduced for the RIPE Database to the remaining API Keys in the LIR Portal, providing a more secure and flexible way to manage access across services. API keys for My resources and IP Analyser can now be created directly within the services where they are used, while centrally visible and manageable via RIPE NCC Access. You can read more about these changes and what they mean for you here: https://labs.ripe.net/author/fallon-albrecht/extending-api-keys-beyond-the-… Kind regards, Fallon Albrecht Manager Business Applications

1 0

Something wrong?
by Hank Nussbacher 22 Mar '26

22 Mar '26

Hi, When attempting to update an in-addr.arpa object today, I repeatedly get: Unexpected error: please retry later Did not happen yesterday. Is it just me or everyone? Regards, Hank

6 11

RIPE Database 1.121.2 Release
by Edward Shryane 18 Mar '26

18 Mar '26

Dear colleagues, RIPE Database release 1.121.2 has just been released to the production environment. The only change from release 1.121.1 is a fix for a cross-site vulnerability affecting the Syncupdates service. We have removed support for the HTTP GET method in Syncupdates to update an object using a URL-encoded object. Now we only support the POST method. This helps to protect the RIPE database from Cross-Site Scripting (XSS) exploits, and the GET method was rarely used (the last update was in mid-January). We are following our internal Vulnerability Management policy remediation timelines and therefore not waiting for the normal release cycle. Regards Ed Shryane RIPE NCC

1 0

RIPE Database 1.121.1 Release
by Edward Shryane 16 Mar '26

16 Mar '26

Dear colleagues, RIPE Database release 1.121.1 has just been released to the production environment. The only change from release 1.121 is a fix for a cross-site vulnerability affecting the Syncupdates service. We are following our internal Vulnerability Management policy remediation timelines and therefore not waiting for the normal release cycle. Regards Ed Shryane RIPE NCC

1 0

Whois 1.121 Release
by Edward Shryane 04 Mar '26

04 Mar '26

Dear colleagues, RIPE Database release 1.121 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Wednesday 4th March. Whois release 1.121 contains the following changes : * Removed support for MD5 passwords in mntner and IRT object types * NWI-21: Added "reg-nr:" attribute to the organisation object type * Run GRS mirror imports after dump is updated, not all at midnight * Fix RDAP publicIds array * Return top-level IANA allocation or redirect RDAP domain queries The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/6db089c3...94ed67c2 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ The data in the Release Candidate environment is a dummified copy of production from 16th February. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Removing MD5 Hashed Passwords from IRT Objects in the RIPE Database
by Edward Shryane 18 Feb '26

18 Feb '26

Dear colleagues, On 4th March along with the Whois 1.121 release to production, we also plan to remove MD5 hashed passwords from all IRT objects. This has already been done for all MNTNER objects in January. On 14th January, we informed 171 affected IRT maintainers that we will remove all passwords from IRT objects following the next Whois release, and also notified the DB-WG: https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/WQWBPPB2AMTVI… We plan to email the remaining 135 affected IRT maintainers today to remind them of the plan and announce the specific date. We have asked the maintainers to switch to an alternative authentication method, including X.509, PGP or SSO. MD5 hashed passwords in IRT objects are used to authenticate adding an mnt-irt: reference to IRT objects in inet(6)num objects. This has only been done a handful of times this year, so we expect the impact to be low. Please let us know if you have any questions or comments on this plan. Regards Ed Shryane RIPE NCC

1 0

ENUM (e164.arpa): background, scope, and coordination steps
by Hisham Ibrahim 17 Feb '26

17 Feb '26

Dear colleagues, This message summarises recent discussion regarding ENUM (e164.arpa) and clarifies the scope and next steps. The RIPE NCC has operated the e164.arpa registry for many years under instructions and coordination arrangements established with the ITU-T and IAB. These arrangements, and the operational context for how the registry is run, are described here: https://www.ripe.net/manage-ips-and-asns/dns/enum/iab-instructions/ Recently, a request was raised in the RIPE Database Working Group to support ENUM (e164.arpa) in RDAP for querying the RIPE Database. We noted that RDAP support for ENUM is not currently implemented, but could be added if there is clear interest. We also checked current query patterns and found a few hundred ENUM-related queries per day in DNS and in Database; so low usage, but not zero. Following discussion on the Database WG mailing list, including replies in support, we proposed implementing RDAP support for ENUM. While this is a limited operational change, it was recognised that anything touching E.164 and e164.arpa can raise political questions that go beyond the purely technical. As e164.arpa is directly linked to the ITU E.164 numbering system, the relevant points of contact are typically national administrations and the entities they designate. This led us to consult ITU-T Study Group 2 to clarify the status of ENUM and its usage and needs for ongoing support. ITU-T will ask member states for their feedback and share this with us. ITU-T provides an established and coordinated channel to reach those administrations, and importantly confirm whether any delegating authorities still rely on the service, so our technical decisions are informed by real-world use and help us avoid unnecessary operational risk, confusion, or compliance headaches (including in the context of regulatory frameworks such as NIS2). We are also reaching out to the IAB regarding these operations, which the RIPE NCC performs under its instruction on behalf of the global DNS and Internet community. I am sharing this message with the DNS, Database, Cooperation and RIPE NCC Services Working Group mailing lists to ensure all relevant working groups are informed. If you wish to share thoughts in response, please reply to the thread on the RIPE NCC Services WG mailing list. Best regards, Hisham Ibrahim Chief Community Officer, RIPE NCC

1 0

ASN Reuse
by Antonis Chariton 30 Jan '26

30 Jan '26

Hello DB WG, As RIPE has been handing out new ASNs from previous allocations that have been returned for several months now, I wanted to ask if there’s any plan to clean up an entry somehow before reassigning the AS. With the current system you can request an AS, get it, and then have ROAs (ASPAs too?) / route{6,} / as-set objects, etc. from the previous one or more owners. I recently got an AS with valid ROAs and route objects for some IPv4 still pointed its way from a couple of operators ago (according to the bgp.tools history). For bonus points, it’s also included in a DE-CIX IXF feed and shows up as connected there :) Does it make sense to clean up objects or notify entities including an AS upon its return back to the available pool? Since you can’t really know who will get it and when, it’s unlikely you really mean to authorize announcements with a ROA, or IRR routes. It also probably doesn’t make any logical sense to include it in an as-set. I stumbled upon this when I tried generating filters with bgpq* and it added a few unknown /22s without me recognizing them. Pim here (in Cc) also had the same question :) Thanks, Antonis

9 17

Updated Migration Plan to Remove MD5 Hashed Passwords from the RIPE Database
by Edward Shryane 14 Jan '26

14 Jan '26

Dear colleagues, The RIPE NCC database team published an updated plan in January to deprecate MD5 hashed passwords by the end of 2025: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/NGCRQWJPF7MT24… Since then, we have been working towards this deadline: * Added support for API key and OAuth 2.0 authentication * Notified maintainers and removed inactive passwords in June (including any passwords not used since January 2024) * Notified maintainers by email who are actively using passwords in July, September, October and November * Added a warning to the database web query page that passwords are deprecated * Added a warning to Whois update responses that passwords are deprecated I presented at the DB-WG session at RIPE 91 that use of password authentication is still very high: 32% of all updates used password authentication, by about 150 maintainers. By last week, this has decreased to 17% of all updates by about 105 maintainers. There is still a risk that the database community may not be ready for the end of year deadline. Taking this into consideration, I propose the following updated plan for the end of year deadline: * At the beginning of January (e.g. Monday January 5th at midday CET), remove all passwords from the RIPE database, after notifying maintainers and the working group. * Allow maintainers to add a password back to their maintainer if they still really need to use one (e.g. for operational reasons). * In the following Whois release, around the end of January, remove support for passwords altogether, again after notifying maintainers and working group. This gives us a rollback plan in case there are maintainers that need some extra time, and still allows us to follow through with deprecating passwords. In the meantime, we will continue to monitor use of password authentication. We also want to hear from any maintainers who need assistance with the migration, we are happy to help. Please let us know your questions or comments. Regards Ed Shryane RIPE NCC

2 7