- db-wg - mailman.ripe.net

Whois Release 1.117
by Edward Shryane 03 Apr '25

03 Apr '25

Dear colleagues, RIPE Database release 1.117 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 17th April. Whois release 1.117 contains the following changes : Inetnum status hierarchy : * Parent status for LIR-PARTITIONED PA cannot be ASSIGNED PA (#1669) * ASSIGNED PA Cannot have less/more specific ASSIGNED PA (#1672) * Aggregation by LIR Parent should not be allowed for Aggregation by LIR (#1673) * Do not allow LIR-PARTITIONED PA under SUB-ALLOCATED PA in (#1702) RDAP RIR Search: * RDAP Self Links Must Have the Type Set (#1685) * RDAP Validate Correct Key Before Redirect (#1689) * RDAP Fix Relation For Cross-Prefix Inetnum Range (#1693) * RDAP Bottom should check Parent does not CONTAINS search term (#1701) * RDAP Non Existing Search IP Terms in TOP and UP (#1703) * RDAP Add "-rdap" prefix to Relations And Change links (#1700) * RDAP Minimum status for Relations (#1705) NRTMv4: * NRTMv4 Correct aut-num object class name in delta file (#1692) * NRTMv4 Client Reject Deltas When Discontinuous and reinitialise (#1699) * NRTMv4 Client Reject update in case client is ahead instead of reinitialise (#1698) OAuth 2.0 (not ready for production use yet) : * Support OAuth 2.0 (#1688) The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/66dd8671...fba36664 The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-117 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 31st March. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 0

Removing all MD5 Hashed Passwords Not Used for Authentication in the past year
by Edward Shryane 02 Apr '25

02 Apr '25

Dear colleagues, According to January's updated migration plan to remove all MD5 hashed passwords from the RIPE database in 2025 : https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/NGCRQWJPF7MT24… In Q2 2025, the RIPE NCC plans to remove all MD5 hashed passwords that have not been used for authentication in the past year, to reduce the risk of having so many MD5 hashes in the database in case of a data breach. Using 1st January 2024 as a cut-off, we found this will affect approximately 17,000 out of 62,000 maintainers. Accordingly, between this April and June, we will split these affected 17,000 maintainers into small groups and email each group separately, explaining that we plan to remove any such hash(es) from their mntner object. We will give each group at least one week's notice before updating their mntner object. We will not quote a password hash in any email to avoid exposing it, the maintainer is expected to know which password(s) are in active use. Affected maintainers will be free to create a replacement MD5 hashed password themselves. However as passwords will be removed by the end of 2025, we will encourage them to switch to an alternative authentication method instead, such as API keys. Most affected maintainers have an alternative method of authentication. However, approximately 3,000 of those do *not* have any alternative. If a maintainer is left without any authentication method, the Forgot Maintainer Password process will have to be followed to regain access to the maintainer. We plan to leave these maintainers until last. Please let us know your comments and/or questions regarding this planned change. Regards Ed Shryane RIPE NCC

2 3

RIPE NCC User Research on OAuth 2.0 Authentication
by Edward Shryane 14 Mar '25

14 Mar '25

Dear colleagues, On 16 April, the RIPE NCC will host an Open House from 13:00 to 14:00 CET to discuss and demo the new OAuth 2.0-based authentication solution for maintainers in the RIPE Database. We have developed a prototype and would like to share it with the community to gather your feedback and find out what your needs are. Please join us for this online discussion. Whether you are a database maintainer, network operator or just interested in authentication developments, your feedback will help shape the final implementation. You can sign up at: https://ripe.net/s/open-house-oauth2-authentication Regards Ed Shryane RIPE NCC

1 0

Mailupdates were not applied to the RIPE database
by Edward Shryane 13 Mar '25

13 Mar '25

Dear colleagues, Between approximately 12:34 UTC on March 11th and 08:18 UTC on March 13th, some mailupdates messages were not applied to the RIPE database. This was due to an upgrade of the database software. The current Long Term Support (LTS) release of Mariadb dropped a reference to mysql which the mailupdates script depended on. If you did not receive any acknowledgement for a mailupdates message during this time, then please re-submit the mailupdate. The DB team apologies for any inconvenience this incident may have caused. Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.116
by Edward Shryane 03 Mar '25

03 Mar '25

Dear colleagues, RIPE Database release 1.116 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Monday 3rd March. Whois release 1.116 contains the following changes : * RDAP Relation Searches Endpoint (#1603) * Fixes to RDAP RIR-Search (Basic Searches) Feature (#1611) * Return Abuse-c Entity for RDAP organisation Entity Query (#1659) * Update key-cert lookup URL in update notification (#1631) * Warn if mbrs-by-ref in set object is changed (#1662) * Warn on override if set membership claim is not supported by mbrs-by-ref (#1660) * NRTMv4 use EC p256 key instead of ec25519 (#1645) * Remove old NRTMv4 Update Notification File Links (#1652) * Do not send the SOURCE in NRTMv4 relative URLs (#1654) The full list of changes is available in the source repository: https://github.com/RIPE-NCC/whois/compare/930e4aba...66dd8671?expand=1 We plan to enable API keys functionality in test envionments after this production release. The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-116 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

2 1

Something wrong?
by Hank Nussbacher 28 Feb '25

28 Feb '25

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

2 3

Whois Release 1.115.1
by Edward Shryane 03 Feb '25

03 Feb '25

Dear colleagues, We have just deployed Whois release 1.115.1 to production. This release contains a single change since release 1.115 last week. We fixed an issue where the mntner details were not parsed properly when authenticating an API key, even though the API key was valid. We did not wait for the usual 2 week testing period in the RC environment because this issue was sometimes causing updates using API key authentication to fail. There was no other impact to application security, and no other changes were included. Thanks to the community member who reported this issue. Regards Ed Shryane RIPE NCC

1 0

Using API Keys in the RIPE Database
by Edward Shryane 31 Jan '25

31 Jan '25

Dear colleagues, We have now enabled API keys for authenticating updates in the RIPE database. We have written a RIPE Labs article including a video on how to use this feature: https://labs.ripe.net/author/ed_shryane/using-api-keys-in-the-ripe-database/ Please let me know if you have any comments. Regards Ed Shryane RIPE NCC

2 2

Chicken and egg in regards to inverse
by Hank Nussbacher 30 Jan '25

30 Jan '25

We have a customer with an inverse object (in-addr.arpa) whereby the 3 nameservers listed are long extinct and need to be replaced. So the customer went to Cloudflare and paid to use their 2 nameservers (specifically harley.ns.cloudflare.com and teagan.ns.cloudflare.com). Yet, when I go to RIPE to update their inverse record I get many standard errors that the nameservers do not exist yet to serve this inverse domain. The customer tried to create the zone in cloudflare, but CF asks them to change the DNS in the RIPE object, but to change the RIPE object they need first to have an active DNS zone…. So what is one to do in such a case? Thanks, Hank

3 3

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

30 Jan '25

Dear colleagues, You will find below an updated draft of the migration plan to remove MD5 hashed passwords from the RIPE Database in 2025. The original migration plan was announced last September to the DB-WG and at RIPE 89 in October: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/FTOPBPOGWIQFQP… Thank you all for your valuable feedback, which we have taken into consideration, and in summary we now plan to deploy support for OAuth 2.0 in mid-2025, and we will delay the phase-out of MD5 hashed passwords completely to the end of 2025. The updated migration plan is as follows: * 30 January: Introduced support for API keys in the RIPE Database. * Q2 2025: Remove all MD5 hashed passwords that have not been used for authentication in the past year. This new step reduces the risk of having so many MD5 hashes in the database in case of a data breach, while minimising inconvenience for maintainers that are actively using passwords. This step will affect about 14,000 maintainers which have an alternative method of authentication (out of 62,000 total maintainers), and about 2,000 maintainers with no alternative method of authentication other than passwords. We will communicate this in advance to the DB-WG and to affected maintainers, and encourage them to switch to an alternative authentication method. * Q3 2025: Introduce support for OAuth 2.0 authentication, which will provide automation, including key rollover. * Q3 2025: Communicate to the DB-WG and affected maintainers that we plan to remove support for MD5 hashed passwords before the end of 2025. * Q3 2025: Select batches of maintainers to migrate away from passwords. * Warn that we will remove their MD5 hashed passwords in one month * Assist anyone who asks for help to switch to an alternative * Remove MD5 hashed passwords in batches * Q4 2025: Remove support for MD5 hashed passwords altogether. After that, any maintainers without an alternative authentication method must follow the “Forgot Maintainer Password” process, or contact the RIPE Database support directly. Please let us know if you have any comments on the details and timing. Regards Ed Shryane RIPE NCC

1 0