September 2005 - 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

Deprecation of the NONE Authentication Scheme
by Ziya Suzen 07 Nov '05

07 Nov '05

Dear Colleagues, As announced at RIPE 47 the NONE authentication scheme will be deprecated. After 26 April 2004 the RIPE Whois Database will not accept updates using the NONE authentication scheme. If you have objects protected by a MNTNER object which has the NONE authentication scheme, please assign another authentication scheme or create another MNTNER object to protect these objects. If you are a RIPE NCC member you can create new MNTNER objects through the LIR Portal or send your update to <auto-dbm(a)ripe.net>. History and details: -------------------- 1. Motivation The RIPE Database protects data from unauthorised modification through the use of references to maintainer objects. The maintainer objects contain an "auth:" attribute which specifiy how a user is authenticated during updates to the database. One of the allowed authentication schemes is "NONE", which is actually not an authentication at all, but rather specifies that no authentication is necessary. NONE is intended to be used consciously, as a notification facility or as a means to tag objects. In April 2003, a proposal was sent to the Database Working Group by Hank Nussbacher: It has come lately to the attention in the Internet security realm that spammers as well as crackers are hijacking IP address space. One easy way to "steal" IP address space is via those that have auth=NONE on their objects. It is likely that in many cases NONE is used simply because it is easy. Currently approximately 500 maintainers use NONE - about 5% of all maintainers. 2. Plan Normally with a database cleanup effort, an announcement is sent to the appropriate mailing lists, posted to the RIPE web page, and also sent to the specific users affected. A period of time for cleanup is given. Finally, if the users have not fixed the data then it is modified. However, for the NONE deprecation, it is inadvisable to do this as it means announcing what is in effect a security vulnerability. Also, our operational experience with past cleanups shows that most users do not really participate through the phases of the effort. Therefore, the plan for MNTNER objects with the NONE authentication scheme is: o Announcement only to db-wg mailing list. (This announcement) o Remove "auth: NONE" attributes from all MNTNER objects, by changing them to a "remarks:" attribute with a URL explaining the change. o If that is the only authentication scheme, update the mntner objects, adding MD5-PW with a generated password. o E-mail the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "upd-to:" and "mnt-nfy:" attributes of the objects, explaining the change and including the new password if one is added. o Passwords can be requested via an e-mail to <ripe-dbm(a)ripe.net>. The reply with the password will be sent to the same contacts. After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact <ripe-dbm(a)ripe.net> for assistance. 3. RIPE-NCC-NONE-MNT A maintainer with NONE authentication, RIPE-NCC-NONE-MNT, was added to objects without any maintainer when the database was converted from RIPE-181 format to RPSL format in April 2001. There is a remark in these objects which includes the following: remarks: The RIPE NCC will never use this maintainer object to remarks: enforce any sort of control over user's objects. It is possible this could have been interpreted to mean that no restriction would ever be added to the object. One use of the RIPE-NCC-NONE-MNT has been to allow the creation of objects representing routing policy for resources not allocated or assigned by the RIPE NCC. This is done by using "mnt-routes: RIPE-NCC-NONE-MNT" or "mnt-lower: RIPE-NCC-NONE-MNT" as appropriate. A new maintainer object will be created for these cases, with a well- known password, published in the object: mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE upd-to: ripe-dbm-notify(a)ripe.net auth: MD5-PW $1$GUExyzzy$XQtbZHGVqy9GW8BiAckBV1 remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040301 source: RIPE The main use of this maintainer is for INETNUM objects. There are approximately 60000 such objects - about 6% of the inetnums. Updates for objects with RIPE-NCC-NONE-MNT are rare, less than 2% of all updates. For objects using RIPE-NCC-NONE-MNT: o If there are other "mnt-by:" attributes it will be changed to a "remarks:" attribute. o Otherwise, the "mnt-by:" will be changed to RIPE-NCC-LOCKED-MNT, which has a locked password (or PGP key). o A "remarks:" attribute will be added explaining how to generate a maintainer. o An e-mail will be sent to the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "notify:" attributes of the objects, explaining the change and giving a URL which will help to generate a new maintainer or assign another existing maintainer. o At the URL, the object will be automatically updated to have a new maintainer. o After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact ripe-dbm(a)ripe.net for assistance. 4. Other maintainers with "auth: NONE" The RIPE-NCC-PN-NONE-MNT was used to mark PERSON objects not to be deleted in the 2001 person cleanup. It can be removed and the maintainer deleted. The LIM-MNT is used for limericks. It will have a well-known password similar to the RPSL maintainer. It will also be maintained by another maintainer (not itself, as currently). -- Ziya Suzen RIPE NCC

4 5

RIPE NCC Service Interruption
by RIPE NCC Operations 30 Sep '05

30 Sep '05

[apologies for duplicate mails] Dear Colleagues, >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected disruption to services. Although this may have caused delays to updates to the RIPE Whois Database, these updates have been processed normally. The disruption may have also affected some of these RIPE NCC services: - whois.ripe.net - www.ripe.net - lirportal.ripe.net - ns*.ripe.net - ftp.ripe.net - www.aso.icann.org - www.nro.net - k.root-servers.org (Global node at the AMS-IX) - AS112.ripe.net We apologise for any interruption or delay to services. If you have any questions or concerns regarding this issue, please contact <ops(a)ripe.net>. Regards, RIPE NCC Operations

3 2

whois.ripe.net
by Ulisses 29 Sep '05

29 Sep '05

Hello anybody knows if this is the right place to talk about about the whois.ripe.net server's service? I'm not sure if it is only about the whois package or also the service, if not what is the right place? Thanks in advance Ulisses Debian GNU/Linux: a dream come true ----------------------------------------------------------------------------- "Computers are useless. They can only give answers." Pablo Picasso "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

2 1

Prototype IRIS server deployed at the RIPE NCC
by Peter Banik 28 Sep '05

28 Sep '05

Dear Colleagues, As part of a project to implement the IRIS protocol (also known as CRISP), the RIPE NCC has set up a prototype IRIS server for public testing. We announced this project during the RIPE 49 Meeting in Manchester: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-crisp-upd… We have set up the prototype server as a proxy in front of the RIPE Whois Database. It is based on the FlowerBed server implementation developed by VeriSign Labs: http://iris.verisignlabs.com/blojsom/blog/iris/flowerbed/ The server uses the AREG protocol, you can find more information about this at: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-12.txt We have developed a prototype Perl client that can be used to make queries to AREG servers. This is not a complete client implementation, but we have made it available as we feel it will be useful for those that want to test the service. A web interface for querying the prototype server is available at: http://www.ripe.net/cgi-bin/test-iris/areg-query.pl You can find more details about this project at: http://www.ripe.net/db/iris-pilot/ Regards, Peter Banik RIPE NCC

1 0

Updated syncupdates?
by Peter Schroeder 27 Sep '05

27 Sep '05

Hello, I am a consultant working to develop software that will aid in keeping entries in the RIPE database up-to-date. I've been working to get a local version of the RIPE database running for our testing purposes. We're using the syncupdates interface to make changes in the database but it seems out-of-date because it is using command line switches in dbupdate that are no longer valid. Is there a newer version than 1.0.1? Thanks in advance, Peter Schroeder

4 4

Proposed changes for object ordering
by hairy 19 Sep '05

19 Sep '05

Hi, when will these changes be implemented? Will we know when the change occurs?

2 1

DNSSEC deployment on the reverse tree.
by Henk Uijterwaal 12 Sep '05

12 Sep '05

Dear Colleagues, In June, Olaf Kolkman wrote: >The RIPE NCC has been involved with the development of the DNSSEC >protocol. Now that the protocol has become available, we plan to >implement DNSSEC on our domains in the reverse DNS tree. The >deployment of DNSSEC is the second and last phase of the Reverse DNS >restructuring project. [...] >We welcome your feedback on this poposal before 1 August 2005. Please >send your comments to the DNS Working Group Mailing List. The comment period was extended to 1 September and some comments were posted to the list. These have all been incorporated and the new documents are at: >You can find the proposed policy at: > ><http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html>http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html. > "DNSSEC Key Maintenance Procedure" > ><http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html>http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html > "Procedure for Requesting DNSSEC Delegations" > ><http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html>http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html I'm going to suggest to the chairs of the WG to do a last call on these documents and have them published as RIPE documents. Kind regards, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine)

1 0

RIPE Policy Development Process
by Paul Rendek 01 Sep '05

01 Sep '05

Dear Colleagues We are pleased to announce that Rob Blokzijl, RIPE Chair, has published a new RIPE Document, "Policy Development Process in RIPE", (ripe-350). This document formally describes the policy development process. The updated process is operational from today, 1 September 2005. A new RIPE web page describes all the active policy proposals and their status. Each proposal has a page showing its history, status and all supporting documentation. This page can be found at: http://www.ripe.net/ripe/policies/proposals/index.html A new mailing list <policy-announce(a)ripe.net> has been created for announcing policy proposals and tracking them through the policy development process. This is not a discussion list; discussions will continue to take place on relevant RIPE Working Group lists and at RIPE Meetings. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce List archives are available at: http://www.ripe.net/ripe/maillists/archives/policy-announce/ Kind regards Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

call for items for the DB-WG meeting, RIPE51, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 01 Sep '05

01 Sep '05

The next RIPE meeting ( http://www.ripe.net/ripe/meetings/ripe-51/ ) is coming closer, and I have already collected a couple of suggestions for the DB-WG Meeting [1]. So this is a call for suggestions of items for the draft agenda. As I am going to be off the net for the next 2 weeks, please cc: Nigel Titley in case you want to reply to me individually, or to the list. Thanks, and see you in Amsterdam! Wilfried. [1] . impact of the new PDP ("policy" development process) . secureDNS requirements for the DB . whois functionality/service - follow-up (tbc)

2 2