- db-wg - mailman.ripe.net

RIPE Database Quarterly Planning Q4 2023
by Edward Shryane 29 Sep '23

29 Sep '23

Dear colleagues, The next quarterly plans for the RIPE Database are now available on our website: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning In this quarter, we will continue to work on publishing the source code to our web application and move the RIPE Database documentation to a new interface. By sharing these plans with you, we want to inform you of the ongoing developments on the RIPE Database and get your feedback on other work items you would like us to focus on. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact the DB team directly at ripe-dbm(a)ripe.net . Regards Ed Shryane RIPE NCC

1 0

Whois release 1.108
by Miguel Herran 27 Sep '23

27 Sep '23

Dear colleagues, RIPE Database release 1.108 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 27th September. This release includes the following main changes: * NRTM: Use base64 instead of Hex * NRTM: JSON Text Sequences * RDAP: Add remarks * Update: Warn when http * Remove Lucene support * Elasticsearch do not rebuild from scratch * Elasticsearch use phrase without prefix due to bug * Elasticsearch scape colons * Jakarta / EE9 The release notes are on the website: https://apps.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-108 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ Please let us know if you find any issues with this release in the RC environment. Regards Miguel Herrán RIPE NCC

2 1

Fwd: Geofeed purpose
by Theodoros Fyllaridis 14 Sep '23

14 Sep '23

Dear Colleagues, We would like to provide you with an update on the amendments to the RIPE Database Terms and Conditions. The RIPE Database Terms and Conditions may be amended by either the RIPE NCC (Article 8.2) or the Policy Development Process (Article 8.3). After a long discussion, the Database Working Group reached consensus that providing geolocation information is an agreed additional purpose of the RIPE Database. This consensus was not the outcome of the Policy Development Process. Based on this mandate, the RIPE NCC will work on amending the Terms and Conditions to include this new purpose, as per Article. 8.2 and according to the process set out in the Adoption Process for RIPE NCC Corporate Documents: https://www.ripe.net/about-us/legal/corporate-governance/adoption-process-f…. The proposed text will be based on the community's consensus that geolocation information about the usage of Internet number resources is necessary to facilitate Internet operations. The text will then be reviewed by the RIPE NCC Executive Board in accordance with the aforementioned Adoption Process for RIPE NCC Corporate Documents. Kind regards, Theodoros Fyllaridis Legal Counsel RIPE NCC

1 0

denying access to RIPE DB for proven spammers
by Sergey Myasoedov 14 Sep '23

14 Sep '23

Hi, I would like to discuss the possible changes to the RIPE Database for the LIRs or brokers sending targeted spam with proposed address resources transactions. As far as I know, RIPE DB T&C does not contain a statement about restricting the use of RIPE DB for those abusive traders. Should the community request the NCC to develop how to limit RIPE DB usage? Please feel free to comment. -- Kind regards, Sergey Myasoedov

3 3

About IP resources
by Cunchang Huang 01 Sep '23

01 Sep '23

Cunchang Huang Is there any way to get all the resources under this Id through orgId?

1 0

Geofeed purpose
by denis walker 08 Aug '23

08 Aug '23

Colleagues The conversation on deploying geofeed died shortly after RIPE 85. The last comment was from myself asking if anyone was willing to propose some wording for a new purpose covering the use of the RIPE Database for geolocation information. No one proposed any wording. So below I have made a proposal for a new purpose. Your comments are appreciated. cheers denis co-chair DB-WG The RIPE Database contains information for the following purposes: Ensuring the uniqueness of Internet number resource usage through registration of information related to the resources and Registrants Publishing routing policies by network operators (IRR) Facilitating coordination between network operators (network problem resolution, outage notification etc.) Provisioning of Reverse Domain Name System (DNS) and ENUM delegations Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information. Scientific research into network operations and topology Providing information to parties involved in disputes over Internet number resource registrations to parties who are authorised under the law to receive such information. Providing information about the geolocation usage of Internet number resources.

6 15

Entry Deduplication
by Peter Potvin 04 Aug '23

04 Aug '23

Hey there DB-WG, Apologies in advance if this is the wrong mailing list for this. I noticed that the RIPE DB Query UI automatically deduplicates entries (i.e. multiple instances of an ASN in an AS-SET only appears once) through the webUI, however when queried through whois on any modem operating system the entry shows the raw data including the duplicates within it. I'm a bit curious as to how this is done, and whether it's possible/planned to have the same functionality implemented in the WHOIS back-end that RIPE uses. Regards, Peter Potvin | Executive Director ------------------------------------------------------------------------------ *Accuris Technologies Ltd.* 56A Mill St E, Unit #470, Acton, ON L7J 1H3 Canada Email: peter.potvin(a)accuristechnologies.ca Office: +1 (877) 352-6105 Network Operations Center: +1 (877) 321-1662

2 1

July 2023 Database Working Group update
by David Tatlisu 04 Aug '23

04 Aug '23

Hello everyone, The mailing list has been buzzing this month! This mail is intended to serve as a summary of what happened on the mailing list and behind the scenes. ####################################################################################################################### By far, one of the most active threads concerned the correct *use of the "route" and "route6" objects in a DDOS mitigation scenario. *[1] *Context:* Kaupo Ehtnurm runs a multihomed AS, and one of his upstream providers offers DDOS mitigation service. To ensure all traffic passes through the DDOS mitigation service, they announce a more specific prefix. Kaupo explains that to achieve this, they need to create ROAs and Route objects. ROAs have a max-length field, which allows Kaupo to use just one ROA for a /32 IPv6 with the max-length set to /48. As route objects do not have a max-length field, they explain that they would have to create 65536 /48 route6 objects for their /32, which is difficult to manage. They ask why route objects don't have a comparable "max-length" field.* **Related discussion:* Most of the discussion does not concern the possible reasons why a "max-length" field for route-objects does not exist, but rather discusses operational practice and the actual behavior of DDOS mitigation announcements. Job Snijders explains some of the possible reasons this field does not exist [2]. Job [2] and Nick Hilliard [3] have recommended reading BCP 185 / RFC 9319 for additional information regarding best practices. *Majority consensus:* From what I was able to determine, the following statements are the majority consensus: * Most networks will accept the more specific prefixes, even without a more-specific route object. [4] [5] [6] [7] o Networks have their own reasons for why or why not they might filter more-specifics. [7] [8] [9] o Some traffic might still take the aggregate route instead of the more-specific, this shouldn't be a problem in practice. [10] o Testing the behavior of routes using tools like RIPE Atlas might yield different results, but is said to be unlikely. [7] * Creating a route object for every /48 in a /32 is not recommended. [11] [12] o Announcing and creating route objects for slightly longer prefixes like a few /33 or /34 instead of many /48 might be an acceptable compromise. [13] ####################################################################################################################### Another very active thread was started by Denis Walker, Co-chair of this working group, and concerned*the participation of working group chairs in discussions. *[14] *Context:* Starting the discussion, Denis Walker has explained that he – following feedback from community members – has decided to reduce his community engagement temporarily to evaluate the effect on the working group. He explains that he has not seen current NWIs progress during this time, and that, in his opinion, the lack of engagement by co chairs does not work in some working groups. He states that he will return to his original level of engagement. *Majority consensus: *From what I was able to determine, the following statements are the majority consensus: * Overall, people support active working group chairs that drive discussion, but do not support working group chairs taking a side as a working group chair. [15] [16] [17] * Working group chairs can express their personal opinion when they remove themself from the working group position. [18] [19] *Related discussion:* Most of the discussion has been about co-chair neutrality in discussions. Denis referenced RIPE documents outlaying the responsibilities of a co-chair, where one co chair expressing their opinion to drive discussion is not prohibited. [20] This was followed up by Nick Hilliard, referencing information regarding non-RIPE chair responsibilities. [21] In the end, a policy proposal to clarify the rules was mentioned. [22] [23] ####################################################################################################################### *News from the NCC* * The "rev-srv:" attribute, which was deprecated in 2009, was removed on July 27th. The maintainers of about 34,711 affected objects were informed. [24] * The "NONE" authentication scheme, which was deprecated in 2004, was removed on July 27th. The maintainers of about 613 affected objects were informed. [25] * Client certificate authentication is planned for the database. The NCC has a working implementation internally and is working on getting it ready for production. * The NCC is working on impact analysis concerning a "tuple" solution for NWI-4, where the prefix and status are considered part of the primary key. This will be published soon. * Preparing for the open-source release, the web application for the RIPE Database service is being audited by an external company. This audit is planned to finish by the end of August. #######################################################################################################################* Personal note * Please do not hesitate to tell me if you think I should have included something, or I misrepresented something. I didn't want to go into too much detail, and contemplated a lot about the things to include. You are welcome to contact me if you'd like changes to the format, or you would just like to mention that you thought it was good. I appreciate all feedback. * * ####################################################################################################################### *All the links* Route objects for DDOS mitigation: [1] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007843.html [2] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007859.html [3] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007855.html [4] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007855.html [5] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007867.html [6] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007856.html [7] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007862.html [8] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007866.html [9] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007868.html [10] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007861.html [11] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007865.html [12] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007865.html [13] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007861.html The participation of working group chairs in discussions: [14] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007869.html [15]https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007873.html [16] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007880.html [17] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007891.html [18] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007872.html [19] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007875.html [20] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007883.html [21] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007886.html [22] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007889.html [23] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007890.html NCC news: [24] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007877.html [25] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007878.html

2 1

Authoritative check for domain objects seems to cache nameserver response
by Kjartan Hrafnkelsson - HI 02 Aug '23

02 Aug '23

Dear colleagues, When creating domain objects for reverse DNS delegation of a RIPE assigned inetnum or inet6num, I have observed behaviour where entering a nameserver not authoritative for the in-addr.arpa or ip6.arpa zone results in that nameserver being temporarily unable to be used for delegation. The interface keeps rejecting that particular nameserver for the reason of 'not being authoritative for <zone>', even if the nameserver's configuration has been updated accordingly. What I personally suspect is happening here is that the service on the backend of RIPE NCC's database has sent a DNS request to the specified nameserver, received a response, and cached it. I'm writing this email to ask a couple of questions: Is this intended behaviour? if it is, should it perhaps be changed? and if so, how should changes be implemented? I'm excited to hear back from you, especially as many colleagues within the networking space have expressed frustration from forgetting to configure their nameservers first or misconfiguring them and then having to wait a day or two to re-do the delegation. I had tried my best to search the db-wg list archives for a similar discussion before writing this entry but could find nothing of substance, please forgive me if this has been discussed before and perhaps decided on :) Best, -- Kjartan, AS51019 +354 784-0020 kjh14(a)hi.is

2 1

Removing RIPE-NCC-NONE-MNT remarks from objects in the RIPE database
by Edward Shryane 27 Jul '23

27 Jul '23

Dear colleagues, The "NONE" authentication scheme was deprecated in the RIPE database in 2004: https://www.ripe.net/publications/news/announcements/deprecation-of-the-non… At that time, "remarks:" attributes were added to objects in the RIPE database to explain this change: remarks: Maintainer RIPE-NCC-NONE-MNT removed and object remarks: LOCKED by the RIPE NCC due to remarks: deprecation of the NONE authentication scheme. remarks: Please visit the following URL to unlock this object remarks: http://www.ripe.net/db/none-deprecation-042004.html As mentioned in my Operational Update at RIPE86, I propose to remove these obsolete remarks from all objects, on *Thursday 27th July*. This change will affect approximately 613 objects. We plan to notify the maintainers of all affected objects afterwards. If you have any questions or comments, please let me know. Regards Ed Shryane RIPE NCC

1 1