- db-wg - mailman.ripe.net

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

Whois 1.124 Release
by Edward Shryane 13 Aug '26

13 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 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

Replacing well-known passwords in the RIPE and TEST databases
by Edward Shryane 21 May '26

21 May '26

Dear collegaues, There was a comment during this morning's DB-WG session that the well-known password for LIM-MNT (the Limericks Working Group Maintainer) in the RIPE database has been replaced. Apologies this has not been properly documented. Now the LIM-MNT has two new auth: attributes: * auth: PGPKEY-EB331265 * https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=PGPKEY-EB331265&t… * auth: X509-3861 * https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=X509-3861&type=ke… Both key-cert objects contain the private key in remarks: attributes, so you can use either to authenticate as LIM-MNT. Separately, we have also added auth: attributes to the TEST-ROOT-MNT maintainer in the TEST database, so users can bootstrap their objects there. * auth: PGPKEY-2B4DEF0D * https://apps-test.db.ripe.net/db-web-ui/lookup?source=test&key=PGPKEY-2B4DE… * auth: X509-1 * https://apps-test.db.ripe.net/db-web-ui/lookup?source=test&key=X509-1&type=… Both key-cert objects also contain the private key in remarks: attributes, so you can authenticate as TEST-ROOT-MNT. We will update the DB documentation with this information. Regards Ed Shryane RIPE NCC

1 0

RIPE91 Database Working Group Minutes
by Peter Hessler 21 May '26

21 May '26

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

Whois Release 1.122.1
by Edward Shryane 14 May '26

14 May '26

Dear colleagues, We have just released RIPE database release 1.122.1 to the production environment. The only change from release 1.122 is a fix to add a size limit to RDAP relation search queries. We did not wait for the usual 2 week testing period in the RC environment because receiving many such queries at once can impact the production service for other users. Regards Ed Shryane RIPE NCC

1 0

Public ENUM article and RIPE 92 Services WG discussion
by Hisham Ibrahim 12 May '26

12 May '26

Dear colleagues, I wanted to share an article on the current operational status of Public ENUM under e164.arpa. The article is based on a 2026 operational review carried out by the RIPE NCC and looks at the status of current delegations and the questions this raises for the future support of Public ENUM. I plan to present this topic during the Services Working Group session at RIPE 92, where I hope we can discuss the findings and possible next steps with the community. Article: https://labs.ripe.net/author/hisham_ibrahim/operational-review-of-public-en… Best regards, Hisham

1 0

Call for co-chair volunteers
by David Tatlisu 11 May '26

11 May '26

Hi Everyone, My current term as a DB-WG co-chair will expire at RIPE 92. To me it's a little hard to believe how quickly time passed, and looking back a lot has changed. As per the chair selection process any member of the RIPE community may stand for chair. If you have any questions about the experience, training opportunities or would like to express your interest in this position, please contact the chairs at db-wg-chairs(a)ripe.net *by 21 April. *Kind regards, David On behalf of the Database WG Chairs.

6 6