- db-wg - mailman.ripe.net

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

15 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

6 10

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

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

NWI-21: "Registration Number" Implementation Plan
by Edward Shryane 05 May '26

05 May '26

Dear colleagues, Following is the implementation plan for the NWI-21 "Registration Number" feature. We plan to go live with this feature on Thursday 30th April, in time for the RIPE 92 meeting in May. Introduction ------------ Adding a registration number to organisations in the RIPE Database was proposed by Marco Schmidt at the Address Policy session at RIPE 91. See slides 14 to 17 : https://pretalx.ripe.net/media/ripe91/submissions/FJ7YSH/resources/RIPE91_U… Following the RIPE Meeting, a Problem Statement was published to the DB-WG: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/77NQDFTMHLIOLE… Following the discussion, consensus was declared on the Problem Definition and the Solution Definition was agreed by the Database working group: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/6S5ZIQ4TTCPNQF… RIPE Database ------------- The Database team is responsible for adding a new "reg-nr:" attribute to the organisation object template in the RIPE database. The attribute will only be added to organisations co-maintained by the RIPE NCC and cannot be modified by the organisation’s maintainer. The value is free text, as the value will vary by registry. The "reg-nr:" attribute will be visible in filtered Whois query responses and will be included in the nightly database dump files once we have finalised updating the relevant documentation.. RIPE Database Web Application ----------------------------- The Database team will add the "reg-nr:" attribute to organisations in query and lookup responses, and will be highlighted as a RIPE NCC managed attribute. As "reg-nr:" is a RIPE NCC managed attribute, users will not be able to add a "reg-nr:" to an organisation object themselves. The web application will not provide a link to a registry website. After internal review, it was decided that this would introduce significant complexity and would require ongoing maintenance effort considering that registry platforms and URLs can change over time. Registry Team ------------- The Registry team is responsible for validating the existing registration number data before it is published. The data should be consistent, where possible, for each national or regional company registry. Also, the Registry team is responsible for ongoing updates to the registration number. Internal Registry Software -------------------------- The Software Engineering team is responsible for synchronising the registration number from the internal registry to the RIPE database, after the Registry team has performed its validation. The software will perform the following validation for an organisation’s registration number: * Not have any leading/trailing whitespace * Only consist of Latin-1 characters * Not contain a "#" (reserved for a comment in RPSL) * Maximum length 60 characters If the organisation is a natural person or government entity, then "reg-nr: Not Applicable" is published. Regards Ed Shryane RIPE NCC

7 12

reg-nr entity types
by Cynthia Revström 04 May '26

04 May '26

Hi db-wg and ncc-services-wg, I'm not sure if this necessarily belongs in db-wg or ncc-services-wg but I felt like it might be of interest to both. Now that the reg-nr fields have been populated I have noticed some interesting places where it is present and where it is omitted. As far as I understand it, it is supposed to be omitted from orgs referring to natural persons (I assume including sole proprietors) and government agencies while being included for basically all other kinds of entities. When looking at the data for some Swedish entities I noticed that for both non-profit associations and government agencies, there were those with reg-nr and those without. I would expect non-profits to have reg-nr (except for the cases when they don't have one) while I would expect gov agencies not to have one. One example of a gov agency having reg-nr is SUNET, the Swedish NREN: ORG-SA58-RIPE As SUNET is also the employer of one of the current RIPE NCC EB members I would expect that the NCC would be somewhat familiar with the fact that it is a gov agency. I highlighted that I was worried about this kind of issue when we discussed this proposal in the db-wg in November so I can't say that I'm too surprised. I am however thankful that I at least haven't observed any cases of a natural person having a reg-nr on them as that was my biggest worry by far. -Cynthia

2 1

Whois 1.122 Release
by Edward Shryane 30 Apr '26

30 Apr '26

Dear colleagues, We have deployed Whois release 1.122 to the Release Candidate environment for testing. We plan to deploy to production on Thursday 30th April. The Whois 1.122 release contains the following changes : * Support UTF-8 in Free Text Attributes ("descr:" and "remarks:"). * NWI-20: Adjusting contact method requirements and adding new methods. * Do not allow "mnt-lower:" on inetnum ASSIGNED PA * Allow user to remove mnt-lower from ASSIGNED resources UTF-8 in Free Text Attributes ("descr:" and "remarks:") Implementation ---------------------------------------------------------------------- We have implemented support for UTF-8 in "descr:" and "remarks:" attributes, as described in the Solution Definition and Impact Analysis: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/V363E7FTMOXXZ3… Be aware that only Unicode code points included in IDNA 2008 are supported. Any unsupported characters are substituted with a "?". In addition to the existing latin-1 encoded dump and split files, we will also be publishing daily dump and split files with UTF-8 encoding, named with a "utf8.gz" extension. These files will be available on the FTP site after the production release at : https://ftp.ripe.net/ripe/dbase/ NWI-20: "Adjusting contact method requirements and adding new methods" Implementation ------------------------------------------------------------------------------------- We have implemented NWI-20 as described in the Solution Definition: https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/CYCFEN2S3XTY3… We have implemented the following changes to the object templates: * The "e-mail" attribute becomes mandatory on person. * The "address" attribute becomes optional on both person and role. * The "phone" attribute becomes optional on person. * Added a new "contact:" as an optional attribute type on person, role, organisation, irt. Be aware that the "contact:" attribute value may contain a URI fragment (i.e. a "#" character), for example signal.me (see https://signal.miraheze.org/wiki/Signal.me_URLs) This is normally interpreted as an RPSL comment as defined in RFC 2622. We have decided to treat the URI fragment character in "contact:" attributes as part of the attribute value and *not* as the beginning of a comment. Other Changes ------------------------------------------------------------------------------------- The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/6a2a42c...052a4c13 The release notes are in DB documentation: https://docs.db.ripe.net/Release-Notes The data in the Release Candidate environment is a dummified copy of production from 13th April. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Making Resource Holders Easier to Identify: Introducing reg-nr: in the RIPE Database
by Marco Schmidt 30 Apr '26

30 Apr '26

Dear colleagues, We’re happy to share that, as of 30 April, the reg-nr: attribute is now available in the RIPE Database following the completion of NWI-21. https://www.ripe.net/community/wg/active-wg/db/numbered-work-items/ First proposed at RIPE 91 in the Address Policy Working Group and then discussed further in the Database Working Group, it’s now in place ahead of RIPE 92. This is a great example of how community input can quickly turn into something tangible and useful. Thank you to all who provided feedback and contributed to this outcome. The reg-nr: attribute adds the official company registration number of resource holders to organisation objects co-maintained by the RIPE NCC. This makes it easier to clearly identify organisations, especially where names are similar or the same. Please note that this does not apply to all organisation objects. For privacy reasons, a reg-nr: with value "Not applicable" will be published for natural persons and governmental organisations. If you come across information that appears incorrect or incomplete, please let us know by sending an email to ripe-dbm(a)ripe.net. Our Member Services team will follow up. More details are available in the RIPE Labs article: https://labs.ripe.net/author/marco_schmidt/making-resource-holders-easier-t… Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

Whois 1.122 Release
by Edward Shryane 16 Apr '26

16 Apr '26

Dear colleagues, We have deployed Whois release 1.122 to the Release Candidate environment for testing. We plan to deploy to production on Thursday 30th April. The Whois 1.122 release contains the following changes : * Support UTF-8 in Free Text Attributes ("descr:" and "remarks:"). * NWI-20: Adjusting contact method requirements and adding new methods. * Do not allow "mnt-lower:" on inetnum ASSIGNED PA * Allow user to remove mnt-lower from ASSIGNED resources UTF-8 in Free Text Attributes ("descr:" and "remarks:") Implementation ---------------------------------------------------------------------- We have implemented support for UTF-8 in "descr:" and "remarks:" attributes, as described in the Solution Definition and Impact Analysis: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/V363E7FTMOXXZ3… Be aware that only Unicode code points included in IDNA 2008 are supported. Any unsupported characters are substituted with a "?". In addition to the existing latin-1 encoded dump and split files, we will also be publishing daily dump and split files with UTF-8 encoding, named with a "utf8.gz" extension. These files will be available on the FTP site after the production release at : https://ftp.ripe.net/ripe/dbase/ NWI-20: "Adjusting contact method requirements and adding new methods" Implementation ------------------------------------------------------------------------------------- We have implemented NWI-20 as described in the Solution Definition: https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/CYCFEN2S3XTY3… We have implemented the following changes to the object templates: * The "e-mail" attribute becomes mandatory on person. * The "address" attribute becomes optional on both person and role. * The "phone" attribute becomes optional on person. * Added a new "contact:" as an optional attribute type on person, role, organisation, irt. Be aware that the "contact:" attribute value may contain a URI fragment (i.e. a "#" character), for example signal.me (see https://signal.miraheze.org/wiki/Signal.me_URLs) This is normally interpreted as an RPSL comment as defined in RFC 2622. We have decided to treat the URI fragment character in "contact:" attributes as part of the attribute value and *not* as the beginning of a comment. Other Changes ------------------------------------------------------------------------------------- The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/6a2a42c...052a4c13 The release notes are in DB documentation: https://docs.db.ripe.net/Release-Notes The data in the Release Candidate environment is a dummified copy of production from 13th April. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 0

Re: ENUM (e164.arpa): background, scope, and coordination steps
by Hisham Ibrahim 08 Apr '26

08 Apr '26

Dear colleagues, I would like to follow up on my previous message regarding ENUM (e164.arpa) and share a brief update on where things currently stand. As noted earlier, the RIPE NCC has been reviewing the operational status of the e164.arpa registry in light of its very limited usage, recent discussion in the RIPE Database Working Group, and the broader considerations surrounding the service operated by the RIPE NCC. Since my last email, the Internet Architecture Board (IAB) has discussed the matter at its last meeting. At this stage, the IAB has indicated that it would like to hear further feedback from the community before taking any further position. ITU-T has also initiated a consultation with Member States on the possible closure of the ENUM system under e164.arpa. As mentioned previously, this is an important part of understanding whether the service is still needed by the relevant delegating authorities and whether there is a continued operational justification for maintaining it. While the immediate trigger was a limited operational question, the topic also touches on broader considerations around community input, governance responsibilities, and coordination with relevant external bodies such as the IAB, IANA and ITU-T. For the RIPE NCC, the goal remains to approach this carefully and transparently: to understand whether there is still a real need for the service, to avoid unnecessary operational or compliance risk, and to ensure that any future steps are informed by both community feedback and the views of the appropriate stakeholders. I will present on this topic at RIPE 92, where I will provide more background, summarise the discussions to date, and invite further feedback from the RIPE community. In the meantime, I encourage anyone with views on this matter to share them on the RIPE NCC Services Working Group mailing list so that the discussion can continue openly and with the benefit of community input. Best regards, Hisham Ibrahim Chief Community Officer RIPE NCC On Tue, 17 Feb 2026 at 16:09, HMI IMH <hibrahim(a)ripe.net> wrote: > Dear colleagues, > > This message summarises recent discussion regarding ENUM (e164.arpa) and > clarifies the scope and next steps. > > The RIPE NCC has operated the e164.arpa registry for many years under > instructions and coordination arrangements established with the ITU-T and > IAB. These arrangements, and the operational context for how the registry > is run, are described here: > https://www.ripe.net/manage-ips-and-asns/dns/enum/iab-instructions/ > > Recently, a request was raised in the RIPE Database Working Group to > support ENUM (e164.arpa) in RDAP for querying the RIPE Database. We noted > that RDAP support for ENUM is not currently implemented, but could be added > if there is clear interest. We also checked current query patterns and > found a few hundred ENUM-related queries per day in DNS and in Database; so > low usage, but not zero. > > Following discussion on the Database WG mailing list, including replies in > support, we proposed implementing RDAP support for ENUM. While this is a > limited operational change, it was recognised that anything touching E.164 > and e164.arpa can raise political questions that go beyond the purely > technical. > > As e164.arpa is directly linked to the ITU E.164 numbering system, the > relevant points of contact are typically national administrations and the > entities they designate. This led us to consult ITU-T Study Group 2 to > clarify the status of ENUM and its usage and needs for ongoing support. > ITU-T will ask member states for their feedback and share this with us. > > ITU-T provides an established and coordinated channel to reach those > administrations, and importantly confirm whether any delegating authorities > still rely on the service, so our technical decisions are informed by > real-world use and help us avoid unnecessary operational risk, confusion, > or compliance headaches (including in the context of regulatory frameworks > such as NIS2). > > We are also reaching out to the IAB regarding these operations, which the > RIPE NCC performs under its instruction on behalf of the global DNS and > Internet community. > > I am sharing this message with the DNS, Database, Cooperation and 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 Services WG mailing list. > > Best regards, > Hisham Ibrahim > Chief Community Officer, > RIPE NCC >

1 1

Call for presentations
by David Tatlisu 07 Apr '26

07 Apr '26

Hi Everyone, RIPE 92 is coming up, and we still have 10 - 20 minutes of space in our agenda. If you have something in mind and would like to present in Edinburgh, please get in contact with us via db-wg-chairs(a)ripe.net, send a message on this list or upload a proposal in Pretalx. https://pretalx.ripe.net/ripe-92/cfp We are very flexible and can accept talks *until 19 May.* * *Kind regards, David On behalf of the Database WG Chairs.

1 0

Last call for feedback for NWI-20 (Updating contact method requirements and adding new ones)
by David Tatlisu 07 Apr '26

07 Apr '26

Hi Everyone, After a lot of lively discussion just before RIPE 91, and a short presentation at RIPE 92 it appears that the community is largely in favor of this proposal. Behind the scenes, Ed and his team are ready to start the implementation. Should you have any input on this proposal, please post it before *11 April 2026. *Kind regards, David On behalf of the Database WG Chairs.

1 0

Extending API Keys
by Fallon Albrecht 01 Apr '26

01 Apr '26

Dear colleagues, We are extending the API key model introduced for the RIPE Database to the remaining API Keys in the LIR Portal, providing a more secure and flexible way to manage access across services. API keys for My resources and IP Analyser can now be created directly within the services where they are used, while centrally visible and manageable via RIPE NCC Access. You can read more about these changes and what they mean for you here: https://labs.ripe.net/author/fallon-albrecht/extending-api-keys-beyond-the-… Kind regards, Fallon Albrecht Manager Business Applications

1 0

Something wrong?
by Hank Nussbacher 22 Mar '26

22 Mar '26

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

6 11