- db-wg - mailman.ripe.net

Re: [db-wg] NWI-7: abuse-c implementation plan
by Andreas Worbs 11 Jul '17

11 Jul '17

Yes, go ahead :) Am 11.07.17 um 09:02 schrieb denis walker via db-wg: -- Mit freundlichem Gruß Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

1 0

Re: [db-wg] NWI-7: abuse-c implementation request
by Gert Doering 11 Jul '17

11 Jul '17

Hi, On Wed, Jun 28, 2017 at 01:56:49PM +0200, Tim Bruijnzeels via db-wg wrote: > Here is the RIPE NCC's impact analysis and proposed implementation plan for the changes to ???abuse-c:??? that the working group seeks. I think the proposed implementation makes sense, reducing overhead for maintaining the abuse contacts, while at the same time still giving a very clear order of precedence when querying -> works for me! Gert Doering -- long time LIR DB user -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Piotr Strzyzewski 11 Jul '17

11 Jul '17

On Mon, Jul 10, 2017 at 07:37:37PM +0200, denis walker via db-wg wrote: Dear All > It is almost two weeks since Tim sent out a proposed implementation > plan and timeline. Can we assume no comments mean acceptance? If > anyone has any specific comments can we here them please. I see no reasons to wait for implementing the plan. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Sebastian Wiesinger 11 Jul '17

11 Jul '17

> Colleagues > It is almost two weeks since Tim sent out a proposed implementation > plan and timeline. Can we assume no comments mean acceptance? If > anyone has any specific comments can we here them please. Hello, after two weeks of vacation I'm back and I support this implementation. Happy to see this topic come to conclusion this time! Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by denis walker 10 Jul '17

10 Jul '17

Colleagues It is almost two weeks since Tim sent out a proposed implementation plan and timeline. Can we assume no comments mean acceptance? If anyone has any specific comments can we here them please. Regardsdenisco-chair DB-WG From: Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> To: William Sylvester <william.sylvester(a)addrex.net> Cc: DB-WG <db-wg(a)ripe.net> Sent: Wednesday, 28 June 2017, 13:57 Subject: Re: [db-wg] NWI-7: abuse-c implementation request Dear working group, Here is the RIPE NCC's impact analysis and proposed implementation plan for the changes to “abuse-c:” that the working group seeks. We expect that this will have a MEDIUM impact on the RIPE NCC. The RIPE Database Group Software team will have to implement changes, but because a clean-up of “abuse-mailbox:” is also in-scope of this proposal we also expect impact on our Customer Service department due to questions from users of the RIPE Database. We propose an implementation using the following phases: 1) Allow “abuse-c:” on INET(6)NUM and AUT-NUM objects We will deploy a new version of whois where the “abuse-c:” attribute will be allowed to exist on INET(6)NUM and AUT-NUM objects. The syntax will be the same as for the ORGANISATION object: abuse-c: [optional] [single] [inverse key] The Abuse Finder logic will be updated to use the first "abuse-c:" found in this order of priority: -the local "abuse-c:" in the resource object -the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the resource object -search up the resource object hierarchy (less specific objects) --the "abuse-c:" in the less specific resource object --the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the less specific resource object The search will stop when the top level resource object is reached. In addition to this we plan to introduce a business rule that will disallow “abuse-mailbox:” to be modified, or (re-)added to any object, other than ROLE objects. This will enable us to do a phased clean-up of this data without invalidating objects. 2) Clean up of “abuse-mailbox:” on ORGANISATION objects Three cases exist: A) “abuse-mailbox:” is present and it is the same as the “abuse-mailbox:” in the also present “abuse-c:” reference (8919 cases) In this case we propose to simply delete the “abuse-mailbox:” attribute and inform the holder. We will work on a clear text for this email, but the main message would be: "We removed “abuse-mailbox:” from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with the same email address in its its “abuse-mailbox:” attribute. No action is required.” B) “abuse-mailbox:” is present and it is different from the “abuse-mailbox:” in the also present “abuse-c:” reference (1848 cases) Note that some of these cases have been caused by the fact that since the introduction of “abuse-c:” LIRs can no longer modify the value of the “abuse-mailbox:” attribute. The intent was that “abuse-mailbox:” would have been cleaned up earlier, but unfortunately that dit not happen. That being said “abuse-c:” has been kept up to date by the LIR, and out of the two is also the one that is being shown on the Abuse Finder. Therefore we propose to delete the “abuse-mailbox:” attribute in these cases, and send a different notification to the holder with the following main message: "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with that uses $email_2 in its “abuse-mailbox:” attribute. If the latter is correct no action is required. However if you want to modify the email address in your “abuse-c:” ROLE object, you can do so here (link to webupdates).” C) “abuse-mailbox:” is present, and there is no “abuse-c:” reference (28312 cases) We *could* create “abuse-c:” ROLE objects for these cases, using the same maintainers as the ORGANISATION object. However, the “abuse-mailbox:” attribute has not been shown in the Abuse Finder, and this change could lead to wrong or out-of-date addresses suddenly receiving abuse reports. Therefore we suggest that we delete the attribute instead, and send the following main message to the holder of the ORGANISATION object: "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, if you wish to add an email address for abuse reports you can do so by editing your object here (link to web updates for the ORGANISATION object)." 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) In these cases we propose to send a warning email to the holders of these objects with the following main message: “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." And then 4 weeks later we will preform the clean-up and refer back to this communication. 4) Clean up whois code Now that “abuse-mailbox:” only appears where it should, we will be able to update the whois code itself so that “abuse-mailbox:” is no longer syntactically allowed on objects other than ROLE objects. This will allow us to remove the business rule added in phase 1 and simplify the whois code and maintenance. We will also update the RIPE Database Documentation to reflect this. 5) Inverse queries As requested we can change the behaviour of the “pn” short cut to also search for “abuse-c:” in inverse queries. I.e. one can use: whois -r -i pn uk41-ripe Instead of: whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 22 May 2017, at 20:56, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation request > Date: 22 May 2017 at 19:59:44 GMT+2 > To: DB-WG <db-wg(a)ripe.net> > > > DB-WG Members, > > Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described. > > This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem statement of NWI-7 as follows: > > 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects > 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects > 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically > 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects. > 5) Clean up data relating to the deprecated attributes. > 6) Update the 'person' keyword to take account of "abuse-c:" > > Thank you all for your work on this proposal! > > Kind regards, > > William > on behalf of DB-WG co-chairs > > >

1 0

New on RIPE Labs: Unifying the LIR Portal and RIPE Database User Experience
by Mirjam Kuehne 10 Jul '17

10 Jul '17

Dear colleagues, Over the years, the core services of the RIPE NCC, such as the LIR Portal and RIPE Database, have seen many changes. We are now going to unify the interfaces. Please find more details on RIPE Labs: https://labs.ripe.net/Members/AlexBand/unifying-the-lir-portal-and-ripe-dat… Kind regards, Mirjam Kühne RIPE NCC

1 0

Re: [db-wg] NWI-7: abuse-c implementation request
by Tim Bruijnzeels 28 Jun '17

28 Jun '17

Dear working group, Here is the RIPE NCC's impact analysis and proposed implementation plan for the changes to “abuse-c:” that the working group seeks. We expect that this will have a MEDIUM impact on the RIPE NCC. The RIPE Database Group Software team will have to implement changes, but because a clean-up of “abuse-mailbox:” is also in-scope of this proposal we also expect impact on our Customer Service department due to questions from users of the RIPE Database. We propose an implementation using the following phases: 1) Allow “abuse-c:” on INET(6)NUM and AUT-NUM objects We will deploy a new version of whois where the “abuse-c:” attribute will be allowed to exist on INET(6)NUM and AUT-NUM objects. The syntax will be the same as for the ORGANISATION object: abuse-c: [optional] [single] [inverse key] The Abuse Finder logic will be updated to use the first "abuse-c:" found in this order of priority: -the local "abuse-c:" in the resource object -the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the resource object -search up the resource object hierarchy (less specific objects) --the "abuse-c:" in the less specific resource object --the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the less specific resource object The search will stop when the top level resource object is reached. In addition to this we plan to introduce a business rule that will disallow “abuse-mailbox:” to be modified, or (re-)added to any object, other than ROLE objects. This will enable us to do a phased clean-up of this data without invalidating objects. 2) Clean up of “abuse-mailbox:” on ORGANISATION objects Three cases exist: A) “abuse-mailbox:” is present and it is the same as the “abuse-mailbox:” in the also present “abuse-c:” reference (8919 cases) In this case we propose to simply delete the “abuse-mailbox:” attribute and inform the holder. We will work on a clear text for this email, but the main message would be: "We removed “abuse-mailbox:” from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with the same email address in its its “abuse-mailbox:” attribute. No action is required.” B) “abuse-mailbox:” is present and it is different from the “abuse-mailbox:” in the also present “abuse-c:” reference (1848 cases) Note that some of these cases have been caused by the fact that since the introduction of “abuse-c:” LIRs can no longer modify the value of the “abuse-mailbox:” attribute. The intent was that “abuse-mailbox:” would have been cleaned up earlier, but unfortunately that dit not happen. That being said “abuse-c:” has been kept up to date by the LIR, and out of the two is also the one that is being shown on the Abuse Finder. Therefore we propose to delete the “abuse-mailbox:” attribute in these cases, and send a different notification to the holder with the following main message: "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with that uses $email_2 in its “abuse-mailbox:” attribute. If the latter is correct no action is required. However if you want to modify the email address in your “abuse-c:” ROLE object, you can do so here (link to webupdates).” C) “abuse-mailbox:” is present, and there is no “abuse-c:” reference (28312 cases) We *could* create “abuse-c:” ROLE objects for these cases, using the same maintainers as the ORGANISATION object. However, the “abuse-mailbox:” attribute has not been shown in the Abuse Finder, and this change could lead to wrong or out-of-date addresses suddenly receiving abuse reports. Therefore we suggest that we delete the attribute instead, and send the following main message to the holder of the ORGANISATION object: "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, if you wish to add an email address for abuse reports you can do so by editing your object here (link to web updates for the ORGANISATION object)." 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) In these cases we propose to send a warning email to the holders of these objects with the following main message: “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." And then 4 weeks later we will preform the clean-up and refer back to this communication. 4) Clean up whois code Now that “abuse-mailbox:” only appears where it should, we will be able to update the whois code itself so that “abuse-mailbox:” is no longer syntactically allowed on objects other than ROLE objects. This will allow us to remove the business rule added in phase 1 and simplify the whois code and maintenance. We will also update the RIPE Database Documentation to reflect this. 5) Inverse queries As requested we can change the behaviour of the “pn” short cut to also search for “abuse-c:” in inverse queries. I.e. one can use: whois -r -i pn uk41-ripe Instead of: whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 22 May 2017, at 20:56, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation request > Date: 22 May 2017 at 19:59:44 GMT+2 > To: DB-WG <db-wg(a)ripe.net> > > > DB-WG Members, > > Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described. > > This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem statement of NWI-7 as follows: > > 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects > 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects > 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically > 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects. > 5) Clean up data relating to the deprecated attributes. > 6) Update the 'person' keyword to take account of "abuse-c:" > > Thank you all for your work on this proposal! > > Kind regards, > > William > on behalf of DB-WG co-chairs > > >

1 0

Re: [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE*
by Tim Bruijnzeels 21 Jun '17

21 Jun '17

Dear Working Group, The average update rate to the RIPE Database is 12 updates per minute. As shown the system is capable of handling a sustained rate of over 700 updates per minute for inetnums through mail updates without issues. That is 60 times the average rate. Cases where people actually need to do updates exceeding this rate are very few and far in between. This does not warrant allocating resources to improve this further - our efforts are better spent in other areas such as improving the usability of the user interface to help people manage their content better. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0

Re: [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE*
by Horváth Ágoston János 20 Jun '17

20 Jun '17

Hi Jeroen, I'm probably the most relevant person to asnwer your question right now, having been a core developer during the ripe database reimplementation project in 2013. We did that by running side by side with the old, C version of the ripe database software. As such, we were in no position to change the underlying database or its format. And guess what, the underlying database is coming from the previous server's reimplementation project, all the way from 2000. Reminds me of the story of the NASA booster rocket and the roman horse. There have been minor updates done over the years (like switching to innodb and sql transactions), the basics are still the same. Its data model is 100% optimized for query performance (since queries outnumber updates 100 to 1 or more). And most importantly, since updates (can and often do) have effect on one another, they are strictly serialized (as in, single-threaded). On top of that, all updates go through a rigorous rule checks before being accepted and taking effect. All this translates to that update performance. Note that the update performance is much higher for simple object types (say, person; my last knowledge was over 2000 objects/min), and very slow for complex ones (namely aut-num, with all the extra DNS checks). In practice, it was never an issue that a longer update ran for hours. This performance could be improved greatly given enough priority though. It was always a simple case of this requiring quite some dirty hack or major refactors, while this issue was always considered a minor nuisance, not enough to warrant either. BTW, if you look at the update graph you included, you see that updates are normally almost negligible compared to your batch. Thus most users of ripe database updates see very quick response times. I'd maintain that unless this really stops you from achieving your goals, it's probably best to leave the engineers work on deeper / more pressing issues. Like the fact that the RIPE DB actually needs a massive documentation and a day long training course even for basic usage. And even then, people are struggling with the weird object hierarchy and rules. While could be considered an acceptable approach in '99, this is way outdated by today's standards and user expectations. Cheers, Agoston On Tue, Jun 20, 2017 at 2:23 PM, Jeroen Massar via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: Jeroen Massar <jeroen(a)massar.ch> > To: db-wg(a)ripe.net > Cc: > Bcc: > Date: Tue, 20 Jun 2017 14:22:49 +0200 > Subject: 2017 and RIPEdb only handles 700 updates per *MINUTE* > https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates > > (see attached png for the current version as over time it will disappear) > > shows a nice peak with a max of 723.47 updates. > > Thus either the software is really bad, the updates are rate limited, or > the queries are so high that no further performance is to be expected. > > > As alluded to in the other thread, if there was less junk (those 400k > inet6nums for instance) then likely this would all scale better.... > > Are the RIPE DB-WG chairs still actively involved in the maintenance of > the RIPE Database!? > > As two of the co-chairs are working for RIPE NCC, are they able to tell > why such a process is slow and why these problems that are being raised > over and over on the various lists are not being resolved? > > Greets, > Jeroen >

1 0

Re: [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE*
by denis walker 20 Jun '17

20 Jun '17

HI Jeroen The three DB-WG co-chairs (2 of whom are former RIPE NCC staff) are still actively involved in overseeing the maintenance of the RIPE Database. We don't have any 'hands on' involvement. Things may have changed a little since I was working on the RIPE Database so I am sure Tim will correct me if I am wrong here. Updates sent by email are queued and processed sequentially. It is a batch process, not real time as with Syncupdates or Webupdates. If you submit a single email with a huge number of objects, each of those objects are processed one at a time sequentially. If you submit several emails in quick succession with that huge list of updates spread over them, the emails will be queued and processed sequentially. Not sure now if there is only one queue or several for email updates. AFAIK the database can only update a single object at a time, no matter how many processors are running to feed updates to the database. The bottom line is, if you submit a huge number of objects to be updated it will take some time to complete. The number of daily queries massively outweighs the number of updates. So performance is naturally optimised to serve the query load. The average number of updates is easily handled, but when you get spikes it does slow down the update process for a while. The number of objects in the database makes no difference to performance on either queries or updates. So a large amount of junk will not affect performance. To address a couple of your points from your previous email. No one has ever defined what the "country:" attribute in an INET(6)NUM object means. It could be the location of the registries head office, their data centre, their service desk, their user base... It is not uncommon to see this value 'apparently' conflict with netname or address. If you believe 40% of the INET6NUM objects in the RIPE Database are junk, that is something the RIPE NCC Registration Services needs to comment on. cheersdenisco-chair DB-WG From: Jeroen Massar via db-wg <db-wg(a)ripe.net> To: db-wg(a)ripe.net Sent: Tuesday, 20 June 2017, 14:23 Subject: [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE* https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates (see attached png for the current version as over time it will disappear) shows a nice peak with a max of 723.47 updates. Thus either the software is really bad, the updates are rate limited, or the queries are so high that no further performance is to be expected. As alluded to in the other thread, if there was less junk (those 400k inet6nums for instance) then likely this would all scale better.... Are the RIPE DB-WG chairs still actively involved in the maintenance of the RIPE Database!? As two of the co-chairs are working for RIPE NCC, are they able to tell why such a process is slow and why these problems that are being raised over and over on the various lists are not being resolved? Greets, Jeroen

1 0

2017 and RIPEdb only handles 700 updates per *MINUTE*
by Jeroen Massar 20 Jun '17

20 Jun '17

https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates (see attached png for the current version as over time it will disappear) shows a nice peak with a max of 723.47 updates. Thus either the software is really bad, the updates are rate limited, or the queries are so high that no further performance is to be expected. As alluded to in the other thread, if there was less junk (those 400k inet6nums for instance) then likely this would all scale better.... Are the RIPE DB-WG chairs still actively involved in the maintenance of the RIPE Database!? As two of the co-chairs are working for RIPE NCC, are they able to tell why such a process is slow and why these problems that are being raised over and over on the various lists are not being resolved? Greets, Jeroen

2 1

Re: [db-wg] Cleaning up SixXS inet6nums & 400.000++ junk inet6nums from 2a07:7ec0::/29 in the RIPE database
by Ronald F. Guilmette 20 Jun '17

20 Jun '17

In message <mailman.1675.1497881039.4885.db-wg(a)ripe.net>, Jeroen Massar <jeroen(a)massar.ch> wrote: >Really, a Dutch address, claiming a British country, while the prefix >clearly show "NL" as prefix. > >Website at http://www.onlineserviceproviderbv.nl/ is empty... You may have a bit more luck if you try this: http://onlineserviceproviderbv.nl/ But anyway, it still does seem quite odd that the IPv6 space of this "Dutch" company is apparently being routed by a company located in India whose main stock in trade is the manufacturing of portable searchlights. http://bgp.he.net/AS58905#_prefixes6 --> adwiser.co --> "Point Blank Range Pvt Ltd" --> https://www.indiamart.com/pointblank-rangeprivate-limited/ But it is all rather humorous, don't you think? (I personally prefer my Internet criminals to be ones with a sense of humor. It makes the process of hunting them down at least somewhat entertaining.) And if you would like to see even -more- humor, try this google search: "+31 20 218 2999" It would seem that your "Dutch Internet Service Provider" has another business which is even more notable (and even more linked to, going by the google results ordering), i.e. they also are apparently selling some sort of service that allegedly will help us all to MAKE MONEY FAST while gambling on sports games. https://oddstreak.com/terms-of-service https://oddstreak.com/ Terrific! I just can't wait to make my fortune betting on futbol and/or cricket matches, full time, and with every last penny I have. These people vitrually guarrantee that if I just put in the time and effort, and if I just give them a little bit of money every month, I'll soon be wealthy beyond my wildest dreams. I confess that it does seem just slightly odd that these people who are behind this commercial enterprise, having invested all of the time and energy needed to build a sophisticated mathematical system that will allow any ordinary man on the street (like me) to beat the odds and to come out a winner, would not have applied this system -themselves-, you know, to help their own betting. I mean gee! They have this sophisticated betting system which will allow you to win all the time, so why aren't they themselves presently lounging on a beach somewhere without a care in the world? I guess they are just too generous, and they felt obliged to share their magical mathematical betting strategies with even poor little sods like me. God bless them! covfefe

1 0

Re: [db-wg] Cleaning up SixXS inet6nums & 400.000++ junk inet6nums from 2a07:7ec0::/29 in the RIPE database
by Ronald F. Guilmette 20 Jun '17

20 Jun '17

In message <mailman.1675.1497881039.4885.db-wg(a)ripe.net>, Jeroen Massar <jeroen(a)massar.ch> wrote: >Thus the big question: why does the RIPE NCC allow that junk to exist >there? (Noting that it was shown last year that that "organisation" >inserted bogus stuff too... and it has not been resolved) That is indeed the Big Question. What is the answer? I am seriously asking. I also am aware of at least one very large clump of IPv4-related "pollution" within the RIPE data base... about which I will say more soon (although as far as I can tell, nobody on -any- of the RIPE mailing lists gives a damn about such things)... and I also wonder why no one seems to care about all of the blatantly bogus pollution in the RIPE data base. I can only guess that the answer to that probably has a lot to do with money, one way or another. covfefe

1 0

Cleaning up SixXS inet6nums & 400.000++ junk inet6nums from 2a07:7ec0::/29 in the RIPE database
by Jeroen Massar 19 Jun '17

19 Jun '17

TLDR: - SixXS inet6nums will be cleansed out from RIPE DB - Somebody has 400k junk inet6nums (40% of total) in there... Hola, In regards to https://www.sixxs.net/sunset/, a few hours ago I let our little robot do one last chore: remove all SixXS inet6num's from the RIPEdb as those prefixes are now unused and if any abuse claims where outstanding (we didn't receive any over the last multiple years actually) then those folks had enough time to whois them... Normally, that robot was responsible for ensuring that all tunnels & subnets where properly registered in the database and also removed when they where not used (marked deleted) by that user for two weeks. I now instructed it to consider all prefixes (tunnels and subnets) as deleted and then let it batch out the changes (the RIPE mailserver does not like very large mails it seems...). It is already taking a few hours, but it seems that the mails that where sent in a period of 9 minutes, are being processed slowly, as responses of the updates are coming in. I am looking forward to the graph updating: https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates to see how much impact it had, as it seems that it is very slow... # Some stats Some stats, the robot takes: ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz $ cat ripe.db.inet6num |grep "^inet6num:" | wc -l 1000583 (that number is way too high, see below for why) 13 years ago in 2004 I wrote: https://www.ripe.net/ripe/mail/archives/db-wg/2004-May/002728.html "Thus SixXS takes care of 53.98% of the inet6num's" when we had 2898 prefixes ;) This time the robot found 70581 prefixes to clean (quite a few have been wiped already in the last months btw, thus that was not the max number, just the ones still left ;) Tomorrow all these SixXS prefixes should be gone. According to that number, SixXS would be 7% of the prefixes, that is rather quite a different number, thus I wondered, why is that. # Why are there now 1 million inet6nums? Junk! Thus lets look at the prefixes with more than 10k inet6nums registered: $ cat ripe.db.inet6num.clean | grep "^inet6num:" | awk '{print $2}' | cut -f1,2 -d: | sort -n |uniq -c | sort -n ... 10575 2001:6f8 <---- Easynet, mostly SixXS prefixes 13675 2001:4dd0 <---- Netcologne, mostly SixXS 14038 2001:41f0 <---- Ziggo, wow! now to actually enable users... 33982 2a02:1630 <---- AS30848 "TWT Spa" in .it nice! 37372 2a00:2381 <---- British Telecom nice! 61500 2a07:7ec4 <---- vv junk registrations 61501 2a07:7ec2 64575 2a07:7ec1 64575 2a07:7ec5 64577 2a07:7ec0 65600 2a07:7ec3 65600 2a07:7ec6 65600 2a07:7ec7 <---- ^^ junk registrations 210219 2a01:4f8 <---- Hetzner (makes sense to me...) So apparently, somebody who is not a LIR and who was last year caught with inserting bogus entries: https://www.ripe.net/ripe/mail/archives/db-wg//2016-May/005264.html currently has !!!!~400k!!!! inet6nums in there, that is ~40% of the total!!!! I picked a random few, most of them do not appear to actually be routed. If you look at the contents, you also notice that the details are bogus. Thus the big question: why does the RIPE NCC allow that junk to exist there? (Noting that it was shown last year that that "organisation" inserted bogus stuff too... and it has not been resolved) On top of that those 400k++ inet6nums all show bogus geo location (and are generally useless as they do not contain info at all), lets look at what registers that: inet6num: 2a07:7ec0::/29 netname: NL-OSP-20160517 country: GB ... address: Spuistraat 249-II address: 1012VP Amsterdam ... org-type: OTHER ... Really, a Dutch address, claiming a British country, while the prefix clearly show "NL" as prefix. Website at http://www.onlineserviceproviderbv.nl/ is empty, hosted on throw-away Digital Ocean, not on "own" infrastructure (the prefixes they have..). Checking RIS: https://stat.ripe.net/2a07%3A7ec0%3A%3A%2F29#tabId=routing Next to storing junk in RIPEDB, apparently also wasting a lot of routing space, as they all end up in a land of randomness. As that office address is close by RIPE NCC, can somebody maybe visit them and try to educate these folks (if anybody is there), to become quite a bit better netizen.... though, I bet you'll find people more home at: aut-num: AS202792 as-name: CLOUDSRV ... org-name: CloudSRV Limited org-type: LIR address: Unit 24 Oakleigh Court, Church Hill Road address: EN4 8UX address: East Barnet address: UNITED KINGDOM who are announcing a /31 of that space... I guess that after all these years it is still a very good idea to apply: https://www.space.net/~gert/RIPE/ipv6-filters.html Greets, Jeroen

1 0

Launching My Resources in the RIPE Database
by Alex Band 08 Jun '17

08 Jun '17

Dear colleagues, We are pleased to announce My Resources, a new service in the RIPE Database that allows resource holders and members who sponsor resources to get a comprehensive overview of all IPv4, IPv6 and ASN resources they hold or sponsor at a glance. Resource holders can also manage their resources with an easy-to-use inline editor. For more information, please see the news announcement: https://www.ripe.net/manage-ips-and-asns/db/announcements/launching-my-reso… Kind regards, Alex Band Product Manager RIPE NCC

1 0

AS34991 -- hijacked
by Ronald F. Guilmette 06 Jun '17

06 Jun '17

Is there any chance that any of you might be persuaded to have a word or two with either or both of the upstreams for AS34991, specifically with respect to the fact that that whole and entire AS has quite obviously been hijacked, and that it is currently being used and abused to announce a total of 20 completely and transparently bogus routes into various bits of IPv4 space that are allocated to various parties within the nation of Columbia, including but not limited to the National University thereof? I have already attempted to make contact with both upstreams in this case with no success and no reply so far, perhaps because I am not a european, or perhaps because I myself am not a network operator, or perhaps because I do not speak (or write) bulgarian. Below is a listing of the currently hijacked routes. Please note that the hijacker in this case quite obviously planned this all, quite carefully, and in advance of the actual hijackings, and he tried (and succeded!) to effectively legitimize all of these bogus route announcement via the simple and easy ruse of also pre-creating a set of matching, and equally bogus route objects within the RIPE data base. (As I learned the last time a case like this came up, the RIPE community, in its infinite wisdom, had made it so easy to create such route objects in the data base, with no authority or authorization whatsoever, that any baboon with a keyboard and a pulse may easily do so.) Of course, as the more observant among you may note, the domain name used for the contact email address for AS34991 has recently been re-registered, presumably after having lapsed. This indicates rather clearly, I think, that it is not merely the IPv4 blocks listed below that have been and are being hijacked, but also the AS34991 ASN itself. covfefe P.S. For the record, yes, some of the hijacked blocks in this case have already been sub-leased out to snowshoe spammers, and are being actively used for snowshoe spamming as we speak. ===================================================================== 152.204.132.0/24 -- Columbia 152.204.133.0/24 -- Columbia 152.231.25.0/24 -- Columbia 152.231.28.0/24 -- Columbia 168.176.187.0/24 -- Columbia, National University of 168.176.192.0/24 -- Columbia, National University of 168.176.194.0/24 -- Columbia, National University of 168.176.218.0/24 -- Columbia, National University of 168.176.219.0/24 -- Columbia, National University of 179.1.71.0/24 -- Columbia 181.57.40.0/24 -- Columbia 186.113.13.0/24 -- Columbia 186.113.15.0/24 -- Columbia 186.147.230.0/24 -- Columbia 190.90.31.0/24 -- Columbia 190.90.88.0/24 -- Columbia 200.1.65.0/24 -- Columbia 200.14.44.0/24 -- Columbia 200.24.3.0/24 -- Columbia 200.24.5.0/24 -- Columbia

1 0

Re: [db-wg] Whois release 1.89 deployed to the Release Candidate Environment
by Adam Castle 29 May '17

29 May '17

Hello Elvis, Thanks for your comments. The RIPE NCC, with input from the working group chairs, are currently investigating a solution for all of the RIPE community mailing lists, which we hope will have as little negative impact as possible on those users who do not have DMARC enabled. We are hoping to have this solution tested and rolled out on all of our managed lists as soon as we can and we appreciate your patience in the meantime. Many thanks, Adam Castle Web Services RIPE NCC >> *From: *Elvis Daniel Velea <elvis(a)velea.eu <mailto:elvis@velea.eu>> >> *Subject: **Re: [db-wg] Whois release 1.89 deployed to the Release >> Candidate Environment* >> *Date: *24 May 2017 at 18:23:16 GMT+2 >> *To: *Tim Bruijnzeels <tim(a)ripe.net <mailto:tim@ripe.net>> >> *Cc: *db-wg(a)ripe.net <mailto:db-wg@ripe.net> >> >> Hi Tim, >> >> I can not believe that you guys still can not fix the mailing list to >> show the e-mails correctly. >> >> They currently (for the past few months) appear on an iPhone as attached : >> >> >> >> elvis >> >> Excuse the briefness of this mail, it was sent from a mobile device. >> >>> On May 24, 2017, at 06:38, Tim Bruijnzeels via db-wg <db-wg(a)ripe.net >>> <mailto:db-wg@ripe.net>> wrote: >>> >>> <mime-attachment> >

1 0

Re: [db-wg] Whois release 1.89 deployed to the Release Candidate Environment
by Gert Doering 24 May '17

24 May '17

Hi, On Wed, May 24, 2017 at 06:23:34PM +0200, Elvis Daniel Velea via db-wg wrote: > I can not believe that you guys still can not fix the mailing list to show the e-mails correctly. Thank the people that invented DMARC, consciously breaking mailing lists, and declaring that "not our problem". (But the NCC is working on other options) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [db-wg] Whois release 1.89 deployed to the Release Candidate Environment
by Elvis Daniel Velea 24 May '17

24 May '17

Hi Tim, I can not believe that you guys still can not fix the mailing list to show the e-mails correctly. They currently (for the past few months) appear on an iPhone as attached : elvis Excuse the briefness of this mail, it was sent from a mobile device. > On May 24, 2017, at 06:38, Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> wrote: > > <mime-attachment>

1 0

Re: [db-wg] NWI-7: abuse-c implementation request
by Tim Bruijnzeels 24 May '17

24 May '17

Dear working group, We are working on an impact analysis for this NWI and we expect to have a response within two weeks. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC > On 22 May 2017, at 20:56, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation request > Date: 22 May 2017 at 19:59:44 GMT+2 > To: DB-WG <db-wg(a)ripe.net> > > > DB-WG Members, > > Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described. > > This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem statement of NWI-7 as follows: > > 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects > 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects > 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically > 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects. > 5) Clean up data relating to the deprecated attributes. > 6) Update the 'person' keyword to take account of "abuse-c:" > > Thank you all for your work on this proposal! > > Kind regards, > > William > on behalf of DB-WG co-chairs > > >

1 0

Re: [db-wg] Whois release 1.89 deployed to the Release Candidate Environment
by Tim Bruijnzeels 24 May '17

24 May '17

Dear Working Group, We found two minor issues while 1.89 was in the Release Candidate Environment. #1 Abuse contact information was sometimes returned incorrectly for ASNs #2 The “Zonemaster” configuration was incorrect We had a fix ready for the first issue and therefore we deployed release 1.89.1 to production on 22 May as planned. The fix for the second issue was deployed on 23 May. Note that “Zonemaster” is not enabled yet in production. Although this was tested in the Release Candidate environment, and we don’t expect issues, we plan to enable “Zonemaster” in production manually, knowing that we have the option to revert without the need for a new release in case unforeseen issues are still found. We will send an announcement about this change to this working group before we do. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 4 May 2017, at 14:55, Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> wrote: > > > From: Tim Bruijnzeels <tim(a)ripe.net> > Subject: Whois release 1.89 deployed to the Release Candidate Environment > Date: 4 May 2017 at 14:55:51 GMT+2 > To: db-wg(a)ripe.net > > > Dear working group, > > We just deployed release 1.89 to the Release Candidate (RC) environment. If no issues are raised we plan to deploy this version to production on 22 May 2017. > > This release contains a number of small improvements: > > - Include information on who changed an object in update responses if SSO or PGPKEY is used for authentication > - Replaced dnscheck with Zonemaster for improved domain object (and nameserver) validation > - Fixed NRTM client bugs #279 and #294 > > The complete list of other minor issues solved by this release can be found here: > https://github.com/RIPE-NCC/whois/blob/master/changes.txt > > Kind regards > > Tim Bruijnzeels > Assistant Manager Software Engineering > RIPE NCC Database Group > > >

1 0

NWI-7: abuse-c implementation request
by William Sylvester 22 May '17

22 May '17

DB-WG Members, Support was shown for the proposal NWI-7 and no objections were raised after this round of discussion. At this time, the chairs request that the RIPE NCC schedule implementation of NWI-7 as described. This request is to add the "abuse-c:" attribute directly to the INET(6)NUM and AUT-NUM resource objects. The db-wg therefore ask the RIPE NCC to prepare an impact analysis, followed by an implementation plan and timeline for this request and the other issues raised in the problem statement of NWI-7 as follows: 1) Add the "abuse-c:" attribute to the INETNUM, INET6NUM and AUT-NUM objects 2) Adjust the query logic to take account of 'local' "abuse-c:" attributes in preference to those referenced in ORGANISATION objects 3) Allow both local and indirect references (via ORGANISATION objects) to "abuse-c:" attributes to operate hierarchically 4) Deprecate "abuse-mailbox:" attribute from PERSON, ORGANISATION, MNTNER and IRT objects. 5) Clean up data relating to the deprecated attributes. 6) Update the 'person' keyword to take account of "abuse-c:" Thank you all for your work on this proposal! Kind regards, William on behalf of DB-WG co-chairs

1 0

First RIPE NCC webinar for law enforcement
by Richard Leaning 17 May '17

17 May '17

Hi all, Some of you are aware that the RIPE NCC has been actively engaging with law enforcement across Europe to help them gain a better understanding of RIPE NCC tools and services that might be of use in cybercrime investigations - including the RIPE Database. After the discussion that took place during the Database Working Group session at RIPE 74 last week (https://ripe74.ripe.net/programme/meeting-plan/db-wg/<https://ripe74.ripe.net/programme/meeting-plan/db-wg/), I thought some of you might be interested in learning about a new initiative by the RIPE NCC, in collaboration with Europol and CEPOL (the European Union Agency for Law Enforcement Training), to offer a series of six webinars tailored specifically to police, law enforcement and judiciary working in the area of cybercrime. The first of these took place on 15 May, with more than 400 cybercrime agents participating from across Europe: https://www.ripe.net/publications/news/ripe-ncc-webinars-for-law-enforcement We’ll publish a more detailed article on RIPE Labs when the webinar series concludes next month. Kind regards, Richard Leaning External Relations RIPE NCC

1 0

DB accuracy
by denis walker 11 May '17

11 May '17

Hi I can't connect to the chat at the meeting but I would like to say the definition of the country attribute has come up many times over the years and never been sorted out...a good example of what I was talking about. cheersdenis co-chair DB-WG

1 0

Whois release 1.89 deployed to the Release Candidate Environment
by Tim Bruijnzeels 04 May '17

04 May '17

Dear working group, We just deployed release 1.89 to the Release Candidate (RC) environment. If no issues are raised we plan to deploy this version to production on 22 May 2017. This release contains a number of small improvements: - Include information on who changed an object in update responses if SSO or PGPKEY is used for authentication - Replaced dnscheck with Zonemaster for improved domain object (and nameserver) validation - Fixed NRTM client bugs #279 and #294 The complete list of other minor issues solved by this release can be found here: https://github.com/RIPE-NCC/whois/blob/master/changes.txt Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0