- db-wg - mailman.ripe.net

registry scoped members and excl-members NWI proposal
by Sasha Romijn 02 Nov '26

02 Nov '26

Hello db-wg, James and I have recently presented draft-ietf-grow-rpsl-registry-scoped-members and draft-bensley-rpsl-exclude-members in the RIPE92 and RIPE93 sessions. We just published new versions of these drafts. Feedback so far has been positive, and while details will still develop, we'd like to suggest an NWI for the RIPE Database to implement these two drafts. As RIPE Database has no set resolver/expansion, this concerns adding two new fields along with validation and generation rules. We are still working on some issues around uniqueness across registries, and the practicalities of editing objects with auto-generated content. You can see our work on this in the respective GitHub repositories, and we hope to settle that soon. Once we write implementations, new issues will probably surface, and there are still other rough edges in the text. However, we feel the core is solid. Draft Problem Statement: The as-set and route-set objects are used in the IRR for automatic filter generation. However, resolving the members of these sets has insufficient flexibility, causing operational difficulties. Particularly, references between sets can be ambiguous in the IRR, and some indirectly referred set objects resolve to undesirably large prefix lists, with insufficient controls available for the operator. Draft Solution Definition: Implement the drafts draft-ietf-grow-rpsl-registry-scoped-members and draft-bensley-rpsl-exclude-members in the RIPE Database. As the RIPE Database does not resolve sets, the scope is to add new fields to as-set and route-set, with a number of new validation and generation rules. These drafts are still in development, so details may still change. We welcome your input and support on making this an NWI. If you have comments relating more to the drafts than RIPE Database implementation, they might fit better on the IETF GROW wg list: https://mailman3.ietf.org/mailman3/lists/grow@ietf.org/ References: https://datatracker.ietf.org/doc/draft-ietf-grow-rpsl-registry-scoped-membe… https://datatracker.ietf.org/doc/draft-bensley-rpsl-exclude-members/ https://github.com/mxsasha/rpsl-registry-scoped-members https://github.com/jwbensley/rpsl-exclude-members Sasha

1 0

Problem Statement for Additional RIPE-NONAUTH Cleanups
by Edward Shryane 29 Oct '26

29 Oct '26

Dear colleagues, Following the discussion on cleaning up the RIPE-NONAUTH database last year: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/SFN4AKUI2G3XCZ… and also following the discussion at the DB-WG session at the RIPE 91 and RIPE 92 meetings, here is a problem statement to reduce the size of the RIPE-NONAUTH database. Introduction ------------ The objects in the RIPE-NONAUTH database are not authoritative, and were created anonymously with a well-known password as out-of-region data in the RIPE IRR database. We don’t know who created this data or whether it is still valid. There are very few (< 100) updates per year, which suggests the data is not being maintained. The RIPE-NONAUTH database now contains about 44,526 objects (about the same since RIPE 92). The existing cleanup jobs and maintainers are not deleting much data. I propose to implement additional cleanups to further reduce the size of the NONAUTH database. Scope ----- I propose to implement two additional cleanups of objects in the RIPE-NONAUTH database, as previously discussed. (1) Delete NONAUTH objects with a matching VALID ROA. This will affect approximately 16,497 objects. (2) Delete NONAUTH objects with a matching object in another RIR database. This will affect approximately 27,449 objects. The implementation should initially reduce the size of the NONAUTH database by about 60%, and will continue to reduce over time. Out of Scope ------------ * I do not propose to delete the NONAUTH database completely, only to implement these additional cleanups. * RIPE-NONAUTH database objects will continue to be returned in queries. * Any objects created under IANA or ICANN action will be excluded. See https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/D7242C4PRTXOP… * Mirroring the NONAUTH database using NRTM will still be supported. Conclusion ---------- I’d like to propose creating a new Numbered Work Item for this problem statement. If the WG agrees with the problem statement, I will follow up with a more detailed Solution Definition, including: * Defining how to match candidate objects in the RIPE-NONAUTH database * Notifying maintainer(s) of affected objects in advance * Allowing maintainer(s) to opt-out (so their object is not deleted) * Documenting the cleanups on the website Regards Ed Shryane RIPE NCC

7 11

RIPE92 Database Working Group Minutes
by Peter Hessler 25 Oct '26

25 Oct '26

Hello Database Working Group, The draft minutes from our session at RIPE92 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 Hans 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

My Resources Usability and Resource Check features deployed
by Edward Shryane 19 Oct '26

19 Oct '26

Dear colleagues, Today we have deployed a new version of the Resources page on the DB website: https://apps.db.ripe.net/db-web-ui/myresources/overview We have introduced some usability improvements based on user feedback, including displaying resources as a tree to make the hierarchy visible, which replaces the table view. We have also introduced resource checks, which allows a user to understand what needs attention. This functionality will also appear in the Assisted Registry Check workflows in the LIR Portal. If you are attending the RIPE 93 meeting next week, we encourage you to sign up for a Usability Testing session, which will include the Resources page. Please follow this link to book a session: https://calendar.app.google/1SJjYrqmdHgHuMP16 Please let us know your feedback. Regards Ed Shryane RIPE NCC

1 0

whois server surprisingly looks up items based on "netname" even when query is for ASN
by Ben Cartwright-Cox 06 Oct '26

06 Oct '26

A surprise I just encountered was I was checking AS215165 (who recently had their aut-num object deleted) and I was surprised to see the whois server reply back with a inetnum having (I assume) matched the netname instead! I know the whois server logic is a bit mythical but this seems like a obvious case of the clear intention of the user is not what is being delivered, and I assume this will confuse other programs as well What do we think? (Example output below)-- $ whois AS215165 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See https://docs.db.ripe.net/terms-conditions.html % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2a13:2200:a::/47' % Abuse contact for '2a13:2200:a::/47' is 'xxxx' inet6num: 2a13:2200:a::/47 netname: AS215165 # 2150 country: GB admin-c: YZS9-RIPE tech-c: YZS9-RIPE status: ALLOCATED-BY-LIR mnt-by: mnt-tw-sky-digital-1 created: 2025-02-25T02:19:45Z last-modified: 2025-02-28T02:42:00Z source: RIPE org: ORG-YZS3-RIPE

2 1

[RIPE 93] Call for presentations
by David Tatlisu 07 Sep '26

07 Sep '26

Hi Everyone, RIPE 93 is coming up fast, and we still have a wide open agenda. If you would like to present a topic related to the RIPE Database, please do not hesitate to reach out to db-wg-chairs(a)ripe.net, or upload a proposal in Pretalx. https://pretalx.ripe.net/ripe-93/cfp Kind regards, David On behalf of the Database WG Chairs.

1 0

Whois Release 1.124.1
by Edward Shryane 31 Aug '26

31 Aug '26

Dear colleagues, We have just released RIPE database release 1.124.1 to the production environment. The only change from release 1.124 is a fix to only use the signing certificate in Client Certificate authentication. We did not wait for the usual 2 week testing period in the RC environment as this fixes a security vulnerability which was reported last week. We did not find any evidence that this vulnerability was exploited. Regards Ed Shryane RIPE NCC

1 0

Whois 1.124 Release
by Edward Shryane 27 Aug '26

27 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 1

Fwd: Draft liaison statement on Public ENUM under e164.arpa for the September 2026 ITU-T Study Group 2 meeting
by Hisham Ibrahim 17 Aug '26

17 Aug '26

Dear colleagues, I am sharing this message the DNS, Database, 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 coop-WG mailing list. Regards Hisham ---------- Forwarded message --------- From: Hisham Ibrahim <HMI(a)ripe.net> Date: Mon, 17 Aug 2026 at 17:40 Subject: Draft liaison statement on Public ENUM under e164.arpa for the September 2026 ITU-T Study Group 2 meeting To: <cooperation-wg(a)ripe.net> Dear colleagues, Following the earlier discussions on Public ENUM under e164.arpa, I have prepared the following draft liaison statement for the September 2026 ITU-T Study Group 2 meeting. In my draft I tried to: - clarify the RIPE NCC’s position following SG2-C-0196*, - support the confirmation of the revised interim procedures**, - outline how the responses to TSB Circular 123*** could inform the treatment of individual delegations, - and provide an updated overview of the operational status of the current delegations. I would appreciate feedback on my draft and I would appreciate it if you could share any comments or concerns, particularly on the technical, procedural or governance aspects, by 25 August, so that the RIPE NCC can incorporate the feedback before finalizing the submission. Many thanks in advance for your review. Regards, Hisham * https://www.ripe.net/media/documents/ENUM_liaison_statement_ITU_T_SG2.pdf ** https://www.itu.int/en/ITU-T/inr/enum/Pages/procedures.aspx *** https://www.itu.int/md/T25-TSB-CIR-0123/en To: ITU-T Study Group 2, September 2026 Meeting Title: RIPE NCC liaison statement on ENUM (e164.arpa) Dear colleagues, The RIPE NCC thanks ITU-T Study Group 2, the Telecommunication Standardization Bureau, the Internet Architecture Board, Member States and ENUM delegation operators for their continued engagement concerning Public ENUM under e164.arpa. The RIPE NCC operates the e164.arpa zone as the IAB’s designated operator under the established coordination arrangements involving the IAB, ITU-T and the RIPE NCC. 1. RIPE NCC position At the February 2026 meeting of Study Group 2, the RIPE NCC submitted contribution SG2-C-0196. The contribution arose from an operational question concerning support for ENUM domain objects through the Registration Data Access Protocol, but also raised broader questions concerning the future status of ENUM and e164.arpa. Following subsequent engagement with the IAB, ENUM delegation operators and members of the RIPE community, the RIPE NCC recognizes that those broader questions did not accurately reflect the established distribution of responsibilities. This statement therefore clarifies and supersedes the relevant parts of SG2-C-0196. For the avoidance of doubt, the RIPE NCC supports the continued operation of Public ENUM under e164.arpa and is not proposing its closure. SG2-C-0196 no longer represents a request for Study Group 2 to determine the technical or architectural future of ENUM or e164.arpa. Any future consideration of a system-wide change would require coordination involving the IAB, the relevant IETF and ITU-T processes, the RIPE NCC and affected stakeholders. 2. Operational status and revised procedures The RIPE NCC has reviewed the 46 current delegations recorded in the RIPE Database. Of these, 23 showed no DNS issue at the top delegation level, 17 appeared non-operational and six showed partial DNS issues. These findings identify a registry-maintenance and data-accuracy issue. They do not provide a sufficient basis for a system-wide conclusion concerning Public ENUM or e164.arpa. The RIPE NCC therefore welcomes the revised Interim procedures for Geographic Country Codes (ENUM administration ad interim) contained in TD423 Rev.1/PLEN. The revised procedures provide an appropriate mechanism for addressing individual non-operational or expired temporary delegations while preserving functioning delegations and the ability of Member States to confirm, update, withdraw or subsequently restore their delegations. Responses to TSB Circular 123 may provide useful information concerning the status and intentions of individual national delegations. The RIPE NCC considers that such information should inform individual cases under the revised procedures, rather than a system-wide conclusion concerning Public ENUM or e164.arpa. 3. Request to Study Group 2 The RIPE NCC respectfully invites Study Group 2 to: - confirm that the revised procedures contained in TD423 Rev.1/PLEN will come into force at the September 2026 meeting and will provide the applicable mechanism for addressing individual non-operational or expired temporary delegations; and - continue coordination with the IAB, the RIPE NCC, the relevant IETF processes and affected stakeholders on any broader questions concerning the technical or long-term status of ENUM and e164.arpa. Once the revised procedures come into force, the RIPE NCC intends to apply them systematically and transparently, including by refreshing its technical assessment, engaging with relevant delegation operators where possible and submitting substantiated cases to TSB. The question of Registration Data Access Protocol support is separate from the continued operation of Public ENUM and will be considered through the appropriate technical and community processes. The RIPE NCC remains committed to working constructively with Study Group 2, TSB, the IAB, Member States, delegation operators and the RIPE community to maintain e164.arpa in a stable, accurate and technically sound manner.

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