- db-wg - mailman.ripe.net

RIPE 91 draft agenda & call for presentations
by David Tatlisu 20 Sep '25

20 Sep '25

Hi Everybody, RIPE 91 in Bucharest, Romania, will start in about four weeks. Our session will start at 9:00 in the side room on Thursday, 23 October. We still have a fairly open agenda and would love to have you present. If you are interested in presenting, please contact the working group chairs at db-wg-chairs(a)ripe.net. Please take a look at the NWIs to foster good discussion at the meeting. The NWIs are viewable at https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/ Below is the current draft agenda; please feel free to offer feedback as appropriate. Best regards, Peter and David DB-WG Chairs A. Introduction - 15 min Welcome Scribe Agenda B. NWI Review - 15 mins, WG Chairs C. Operational Update - 30 mins. Edward Shryane, RIPE NCC D. [ YOUR PRESENTATION COULD BE HERE ] - 10-30 minutes, WG Chairs Z. AOB (open discussion)

1 0

FMP remark
by Miguel Mosquera 19 Aug '25

19 Aug '25

Dear colleagues, After we removed inactive MD5 passwords from maintainers, most of these objects have no auth attributes. This is why tomorrow we plan to add the remark "Use Forgot Maintainer Password to recover access to this object, see https://apps.db.ripe.net/db-web-ui/fmp" to maintainers with no authentication attributes (approximately 9k). Please let us know if anyone does not agree with this update. Best Regards Miguel RIPE NCC

1 1

RIPE Database OAuth 2.0 release
by Mahesh Aggarwal 13 Aug '25

13 Aug '25

Dear colleagues, We are pleased to inform that starting this week, RIPE NCC members can use OAuth 2.0 to authenticate applications that interact with the RIPE Database. Please refer to this article for further information : https://labs.ripe.net/author/adonis_stergiopoulos/oauth-20-available-for-th… Please let us know if you have any questions regarding this. Regards Mahesh Aggarwal RIPE NCC

1 0

RDAP for e164.arpa
by Cynthia Revström 07 Aug '25

07 Aug '25

Hi Ed and DB-WG, I just noticed that the RIPE DB RDAP interface returns a 500 error when querying for ENUM domains[1] (except for specifically the top level e164.arpa domain, which results in a 400 error). This seems to be due to an assumption that all domains in the RIPE DB are reverse DNS domains for IP addresses, which is not the case as ENUM domains are also in there. Is this an intentional decision or was this just an oversight? If it was just an oversight, consider this a bug report. :) If it was an intentional decision then I would be interested in hearing what the reasoning was. [1]: Example: https://rdap.db.ripe.net/domain/6.4.e164.arpa -Cynthia

5 7

Whois Release 1.118.1
by Edward Shryane 04 Aug '25

04 Aug '25

Dear colleagues, RIPE Database release 1.118.1 has been released to the PRODUCTION environment. Unfortunately a regression was found in the 1.118 release that was causing some route(6) object queries and updates via the REST API to fail: https://github.com/RIPE-NCC/whois/pull/1843 We have now deployed a fix for this regression, with no other changes from the 1.118 release. We did not wait for the usual 2 week testing period in the RC environment because this was an unintentional change and was impacting some of our users. The exact changes are available in the source repository: https://github.com/RIPE-NCC/whois/compare/505c5f7a...whois_1118_1_release?e… The release notes are on the website: https://docs.db.ripe.net/Release-Notes#ripe-database-release-1-118-1 We apologise for the inconvenience and thanks to the users for reporting this issue. Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.118
by Miguel Mosquera 29 Jul '25

29 Jul '25

Dear colleagues, RIPE Database release 1.118 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Tuesday 29th July. Whois release 1.118 contains the following changes : Resources : * Add prefixlen Attribute to Inet(6)num (#1816) * LIR-PARTITIONED PA inetnum status is not valid under ALLOCATED UNSPECIFIED (#1825) * Run RIR Authoritative Resources Task Every Hour and Import Data Only When Updated (#1749) * Removing mbrs-by-ref maintainer from set causes aut-num update containing member-of to fail (#1770) RDAP RIR Search: * Implemented administrative status on RDAP lookup but not rir-search (yet) (#1778, #1730, #1722) * Remove HTTP status code from RDAP response "title" element. (#1777) ACL: * Do not apply accounting for an Authenticated Maintainer's own Objects (#1723) The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/fba36664...505c5f7a The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-118 More information on the Release Candidate environment can be found on our website: https://docs.db.ripe.net/Release-Notes/ The data in the Release Candidate environment is a dummified copy of production from 14th July. Please let us know if you find any issues with this release in the RC environment. Regards Miguel Herrán RIPE NCC

2 1

Removing all MD5 Hashed Passwords Not Used for Authentication in the past year (updated)
by Edward Shryane 16 Jul '25

16 Jul '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… And to update my previous mail from 31st March: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/4QNPE24MIDFRSG… In Q2 2025, the RIPE NCC plans to remove all MD5 hashed passwords that have not been used for authentication since 1st January 2024, to reduce the risk of having so many MD5 hashes in the database in case of a data breach. We found this will affect approximately 17,000 out of 62,000 maintainers. We have now split these maintainers into four batches and will notify the first batch by email *tomorrow* 11th June. We will send a reminder email for this first batch in one week (18th June), and then finally remove any inactive password hashes for the first batch in two weeks (25th June). We will wait one week before starting on the next batch of maintainers, and also give each batch two weeks notice. This should be enough time to suffiently notify affected maintainers, and to complete the process by mid-July, so we can begin to notify maintainers who are *actively* using password hashes (giving them 6 months notice before support for passwords is removed by end 2025). If maintainers need more time, or if we have many support requests, then we can adjust the timeline accordingly. Please let us know your comments and/or questions regarding this planned change. Regards Ed Shryane RIPE NCC

1 1

Status of my NWI proposal
by Leo Vegoda 13 Jul '25

13 Jul '25

Hi, Where are we with the NWI I posted a while back. It got some suggestions for amendment and they all seem sensible. Do you need something from me? Thanks, Leo

1 0

Proposal: Privacy in RIPE database objects
by Rodolfo García Peñas (kix) 26 Jun '25

26 Jun '25

Hi, I would like to make a proposal regarding the database so that privacy can be included in the objects. Among the main objectives of the database [1] are "To provide accurate registration information of these resources in order to meet a variety of operational requirements" and "Facilitating coordination between network operators (network problem resolution, outage notification etc.)", and therefore the database contains information to facilitate these actions. However, this information can be used to obtain information about individuals and entities in order to carry out unwanted actions (network recognition, phishing, etc.). To prevent network information and contact information from being obtained, objects with anonymized information are stored in the database, role objects are used instead of person objects, non-real information is used, or inetnum objects are not created. Some mailing threads related to these issues have been seen on the mailing list [2][3]. My proposal is that the database offers privacy regarding the information it contains, allowing real information to be stored while protecting LIRs and end users by providing filtered information. To this end, I propose using a system similar to "domain privacy" in DNS registries to hide desired information: - Use the option to hide sensitive information in mandatory fields. - Provide an option to maintain contact with the person responsible for the object. Example: person: Privacy protected address: Privacy protected address: Privacy protected e-mail: Privacy protected (contact link) phone: Privacy protected (contact link) remarks: For mail filtering or abuse problems contact with the abuse mailbox nic-hdl: ABCD1-RIPE mnt-by: Privacy protected (contact link) created: 2008-11-13T15:53:02Z last-modified: 2024-09-23T13:25:48Z source: RIPE One proposal is to use a Boolean model for each field (or for all fields in the object) to indicate whether the information should be "protected" or "public." Another example option would be to include levels such as "public" (publicly accessible), "LEA" (accessible by LEAs), "LIR" (accessible by other authenticated LIRs), and "private" (fully private). This information could be included by default at the user or LIR level using the LIR portal. For email or telephone communication, the platform could act as a mail intermediary or by providing anonymized email addresses, facilitating coordination between network operators/users. IMO, first, we must reach a consensus on whether this option is useful for database management, and then we can discuss implementation details. Regards, Rodolfo García (kix) PS. Thanks Jordi, Miguel for your help. [1] https://docs.db.ripe.net/What-is-the-RIPE-Database/Purpose-and-Content-of-t… [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… [3] https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/MEOS4MD7ZYLVOA… The content of this email reflects personal opinions and does not represent the views of any organization.

4 7

status levels
by denis walker 03 Jun '25

03 Jun '25

Colleagues Maybe I asked too many questions in one email, so I'll take it bit by bit. Is it reasonable to limit the number of levels of SUB-ALLOCATED PA to 4? That is the most we have now in the RIPE Database. Or do you have another number in mind...maybe even 1? Should there be a limit on the number of levels in a LEGACY hierarchy? Currently it is infinite. cheers denids

5 17