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

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

16 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

RIPE NCC Training Courses April-June 2012 - IL, BE, IS, PL, RU, FI, NL, DE, ES, HR
by Training Mailbox 08 Oct '12

08 Oct '12

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Tel Aviv, Brussels, Reykjavik, Belfast, Gdansk, Yekaterinburg, Helsinki, Amsterdam, Munich, Seville and Croatia. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - IPv6 for LIRs Training Course - Routing Registry Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 4

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

Plain text passwords in email updates
by Denis Walker 22 Feb '12

22 Feb '12

Dear Colleagues, The RIPE NCC recently announced completion of an action point from the RIPE Database Working Group to hide the password hashes in MNTNER objects from public view. As a follow up to that, we agreed to contact all maintainers and advise them to update their passwords. This was also completed last week. At RIPE 64 we will provide some statistics on the outcome of that advice. The next issue that was raised in the Database Working group session at RIPE 63 was the use of plain text passwords in emails to update data in the RIPE Database. The RIPE NCC would like to invite members of the community to put forward and discuss ideas on resolving this matter. Note that there are now many ways to update objects in the RIPE Database. As well as the traditional email service, there is also Webupdates for single or small numbers of objects to be updated. For scripting of automated updates, there are Syncupdates and the RESTful API. Some ideas that have been suggested during discussions in the past are to disallow the use of passwords in email updates and also the option to drop email updates completely. There may also be other options. As usual, the RIPE NCC will follow any discussions and provide technical input where necessary. Regards, Denis Walker Business Analyst RIPE NCC Database Group

3 4

help
by Caraliu.Samuel 16 Feb '12

16 Feb '12

2012/2/15 <db-wg-request(a)ripe.net> > Send db-wg mailing list submissions to > db-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to > db-wg-request(a)ripe.net > > You can reach the person managing the list at > db-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Suggestion for a way to retrieve filtered objects > (Anders Mundt Due) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 14 Feb 2012 18:10:33 +0100 > From: "Anders Mundt Due" <anders.mundt.due(a)uni-c.dk> > Subject: [db-wg] Suggestion for a way to retrieve filtered objects > To: "Database WG" <db-wg(a)ripe.net> > Message-ID: > <80D52320F10F9143AF3670B571348EEA01F497BB(a)LGBEXCHANGE01.unic.local> > Content-Type: text/plain; charset="UTF-8" > > Hi there, > > We just had a problem with the RFC3068-MNT object, from what I can see, if > you have an object with at least one > auth: MD5 ... > > Only people that have one of the passwords can see the object in the > webupdater and get the full object to manipulate the object. > > So now, instead of having a chance to get rid of shared > passwords/passphrases, everybody needs to have one, because of the way > objects are filtered. > > Only idea I've had so far, would be that there should be a way to request > an object in a way where I can authenticate with my PGPKEY, for instance > using email and not a webbrowser, so I'd sign a mail requesting an object, > with a key that would be listed as authentication in the object I request, > and that would return the unfiltered object to me. > > Of course, the other solution is to just get hold of all the people with > an auth: MD5 line and make them take it out, that way you can get the full > object without authenticating on the webupdater. > > I'm not sure if my thought here is useable, good or practical. But it > someone can come up with a brilliant way to make shared objects of this > kind smoothly, I suspect the people implementing the database will be eager > to hear about it, and at the very least the people behind RFC3068-MNT will > be gratefull. > > /Anders > Forskningsnettet dk.denet > > End of db-wg Digest, Vol 6, Issue 2 > *********************************** >

1 0