- db-wg - mailman.ripe.net

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

09 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

2 1

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

RIPE92 Database Working Group Minutes
by Peter Hessler 11 Sep '26

11 Sep '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 0

[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

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