January 2012 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Forward DOMAIN Object Cleanup and Syntax Changes
by Denis Walker 08 Mar '12

08 Mar '12

[Apologies for duplicate emails] Dear colleagues, At RIPE 57, the RIPE NCC was asked to remove all forward domain data from the RIPE Database. The last two ccTLD operators' data was removed today, 31 January 2011. The RIPE NCC can now confirm the completion of action point AP57.2 from the RIPE Database Working Group. At RIPE 62, the RIPE NCC was asked to look at the attributes in DOMAIN objects. With the removal of any hierarchy in reverse delegations and the removal of forward domain data, we no longer see any use case for the "mnt-lower:" attribute. Other attributes that it has been suggested were used only for forward domains are: - "refer:" - "sub-dom:" - "dom-net:" The statistics listed at the bottom of this email show how many of these attributes have been added to ENUM and reverse delegation DOMAIN objects. It has also been suggested that the "nserver:" optional attribute could be made a "required" attribute in reverse delegation DOMAIN objects. It could remain optional in ENUM DOMAIN objects or it could be disallowed. The RIPE NCC asked the community in July 2011 if anyone saw any justification for the use of these attributes in ENUM or reverse delegation DOMAIN objects. We did not receive any feedback on this. If there is no justification, the syntax of the DOMAIN object can be adjusted to deprecate these attributes. Then all current DOMAIN objects in the RIPE Database can be "cleaned" to remove this data. Business rules can be added to make the "nserver:" attribute required or disallowed in different types of DOMAIN objects, if this is considered useful. To keep the discussion focused, please send any comments or feedback to the DNS Working Group mailing list. Regards, Denis Walker Business Analyst RIPE NCC Database Group Statistics (as at July 2011) ---------- Number of each attribute used in reverse delegations or ENUMs and the number of unique maintainers who manage these objects. "refer:" = 6 unique maintainers = 1 "sub-dom:" = 271 unique maintainers = 23 "dom-net:" = 2,219 unique maintainers = 140 "mnt-lower:" = 46,485 unique maintainers = 4,208

9 11

cmd line asused and webasused
by Nina Hjorth Bargisen 18 Jan '12

18 Jan '12

Hi all Last year I learned - by asking around - that the asused tool commandline script was no longer supported by RIPE - that was after not being able to find it on the usual ftp site. We have since managed to get by with an old copy but now it seems that this is no longer able to get output from the RIPE db and hence all our adress usage and other homemade scripts are now broken. I assume that this step has been taken after some discussion that I myself have been too lazy to follow in this working group, but as I cant manage to find any reference of it in a brief search in the archives and my mailbox that holds mails from a few years, I hope someone in the group can enlighten me about why this step was taken. I have tried to use the webtool, but as it spams *every* person in the LIR contact list with several mails and all the output is jammed together in one long list, I am not really too happy about rewriting all my scripts to some how use the webtool to give me the nessercary output. So - Is there *ANY* chance of somehow get support of a similar tool to the old asused used, that one can install and run from our own box and with the support of the same options as before or does all tools now focus on small LIRs with very and hence very easily manually managed addressspace? /Nina TDC dk.teledanmark

7 11

Re: [db-wg] cmd line asused and webasused
by Alex Band 18 Jan '12

18 Jan '12

Hi Nigel, I can assure you that the action the board gave, what Axel understood and what we are developing is perfectly aligned. "Merely provisioning an API into the webasused tool" is not what I said and definitely not what we're creating. Our goal is to cater to all needs that the membership has with regards to address space information and management. Some just want a simple web based interface that they can check without needing to download and run a local tool. Some have a need to integrate address space information into their local (IPAM) toolsets and workflows. But what all users have in common is the desire to have a more comprehensive information set than is currently available, such as an overview of the invalid assignments, as Nina pointed out. This is why we're taking an approach of using Registry data instead of the RIPE Database. To summarise, again, we will provide functionality for both web-based and stand-alone use. In the mean time, we will do everything we can to make sure the current asused functionality is not disrupted. Kind regards, Alex On 17 Jan 2012, at 17:53, Nigel Titley wrote: > Nick, Alex et al > > At the Board meeting on the 8th December the board gave Axel an action "to reinstate/redevelop the stand-alone version of the RIPE NCC ASused tool" > > I doubt that this action would be satisfied merely by the provision of an API into the webasused tool. > > Alex, you may like to check this with Axel. It is possible that it was misunderstood by him, but it is very clearly minuted. > > And I'd agree with Nick that lack of platform portability is one of the few brickbats that cannot be aimed at perl. > > Nigel > > -----Original Message----- > From: db-wg-bounces(a)ripe.net [mailto:db-wg-bounces@ripe.net] On Behalf Of Nick Hilliard > Sent: 17 January 2012 16:22 > To: Alex Band > Cc: db-wg(a)ripe.net > Subject: Re: [db-wg] cmd line asused and webasused > > Hi Alex, > > On 17/01/2012 14:25, Alex Band wrote: >> Thanks for bringing up asused. It is a tool that was written and >> maintained by the RIPE NCC many years ago and later handed to the open >> source community, where it can be found in packages such as Debian: >> http://packages.qa.debian.org/a/asused.html >> >> This, along with the fact that is was written in a very platform >> specific manner, is the reason why the tool is no longer actively >> developed and supported by the RIPE NCC. On the other hand, we have >> always kept the existence of asused in mind, which means that we would >> never intentionally change anything to our (whois) configuration that >> would break asused. I want to assure you that we'll try to fix any >> issue that you may have on a best effort basis. > > Problem is, we don't yet have a replacement command-line tool for dealing with quick-n-easy LIR resource usage summarisation. This has meant that the people who depended on this tool were left hanging for the last 8 years, because the code slowly rotted as interfaces subtly changed over time. This is not a criticism of changing the DB interface or anything, btw - progress needs to happen. > > In terms of being platform specific, it was limited to any platform which could run perl - perhaps with minor modifications. There are lots of complaints that people make about perl, (some legitimate) but platform portability is not one of them. > > OTOH, webasused can be very slow. E.g. I submitted a request for a LIR at > 15:28 GMT today, and got a reply at 15:39. This makes it unusable for a typical workflow process (e.g. run asused, check output against internal records, submit a couple of updates, run asused again, check again, repeat until satisfied). > > The web version is also unauthenticated which means that it's open to third parties submitting requests for arbitrary LIRs. And it doesn't support ipv6, which means that it's still difficult to do resource reconciliation for v6 assignments. > > I'll admit that not everyone likes command line tools, but for those of us who continue to us asused, it's a real pity that it wasn't maintained and further developed to support ipv6. > > Nick > >

2 1

MD5 Password Security Update Deployed
by Denis Walker 12 Jan '12

12 Jan '12

Dear colleagues, [Apologies for duplicate emails.] The RIPE NCC is pleased to announce that the implementation of the MD5 password security change has now been fully deployed. This was discussed recently on the RIPE Database Working Group mailing list. The RIPE NCC was asked to implement the technical change as outlined in this RIPE Labs article: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database This deployment has an impact only when you modify a MNTNER object that contains an MD5 password. This can only be done using Webupdates. You must be one of the password holders to make changes. Operations on all other object types are unchanged. The RIPE NCC will now: - Send emails to contact addresses in all MNTNER objects containing MD5 passwords recommending a password change and suggesting that a strong password be used - Perform a small MNTNER clean-up by preparing a list of unreferenced MNTNER objects and deleting those that are still unreferenced one month later. If you have not followed this discussion, we recommend that you read the RIPE Labs article to ensure that you understand the new process for maintaining MNTNER objects in the RIPE Database. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Security of MD5 hashes in the RIPE Database
by Denis Walker 10 Jan '12

10 Jan '12

Dear Colleagues, The RIPE NCC Database Group is pleased to announce that the implementation of the MD5 password security change is now ready for deployment. This was discussed recently on the DB WG mailing list. The Database Group was asked to implement the technical change as outlined in this RIPE Labs article: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database The Database Group will now: - Fully deploy these changes on Thursday 12 January 2012 - Send emails to contact addresses in all MNTNER objects containing MD5 passwords recommending a password change and suggesting that a strong password be used - Perform a small MNTNER clean-up by preparing a list of unreferenced MNTNER objects and deleting those that are still unreferenced one month later. If you have not followed this discussion, we recommend that you read the RIPE Labs article to ensure that you understand the new process for maintaining MNTNER objects in the RIPE Database. A new version of Webupdates has already been deployed that asks for a password before allowing a MNTNER object with a password to be updated. But querying MNTNER objects from the RIPE Database will not change until Thursday. The full new software has been deployed on the TEST Database. So it is no longer possible to query a full MNTNER object that contains a password authentication token from the TEST Database, except by entering the password in Webupdates. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

DB email robot response and Precedence header
by Daniel Roesen 04 Jan '12

04 Jan '12

Hi, robot responses (like SUCCESS) do get sent with header From ripe-dbm(a)ripe.net, and no "Precedence: bulk" headers. So any response to those (e.g. out-of-office) will open a ticket with the ripe-dbm@ folks needlessly. For example, see NCC#2011125073. Would it make sense, to - use From: unread(a)ripe.net (like with the notification mails) and/or - add the "Precedence: bulk" header to avoid autoresponders kicking in? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

2 1