- db-wg - mailman.ripe.net

Next step in the RIPE database reimplementation project
by RIPE Database Administration 21 Feb '00

21 Feb '00

Dear all, This is to notify you of the further steps in the development of the new RIPE Database. Today we have put online the next version of the reimplemented whois server. It is running on the machine reimp.ripe.net on port 43. This server is running as a near real-time mirror client, mirroring the current RIPE database. Please have a look and let us know if you find anything wrong. The results of the queries are supposed to match the results of the queries from our production server. Please note that the access control mechanism may prevent you from obtaining excessive contact information. Please contact <ripe-dbm(a)ripe.net> if the limit turns out to be too small for your tests. Please send your comments and bug reports to <db-beta(a)ripe.net> mailing list. To subscribe to this list send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. The source code is also being released. It can be found at our ftp site: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.2.0beta2.tar.gz The instructions for installing the software and loading the database can be found in the file INSTALL in the main directory. Best regards, Daniele Arena ____________________________ RIPE Database Administration.

1 0

RIPE Database usage
by Wolf-Guido Lutz 18 Feb '00

18 Feb '00

Hello List, forgive me if this is a question that doesn't belong here, but maybe someone can point me in the right direction. I have started maintaining my own nameserver a few months ago and the company that does the second level domain connections for me doesn't seem to be able to help me with this: how can I change the information in the maintainer object of my own RIPE record? In fact, I would like to create my own maintainer object. Is there any documentation maybe on who/how to change that information in the RIPE database? TIA Wolf-Guido Lutz

3 2

Top 100 Maintainers List 20000217
by RIPE Database Administration 17 Feb '00

17 Feb '00

1 0

1. Draft, proposed agenda DB-WG meeting RIPE-35, Thu.,Feb.24 2000
by Wilfried Woeber, UniVie/ACOnet 15 Feb '00

15 Feb '00

Dear DB-WG! Attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting during RIPE35, Amsterdam. As always, comments and proposals for additional topics are welcome. There might be last-minute changes, so stay tuned (this time we've been less successful in finding an optimal solution for the scheduling maze)! Regards, and see you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-35, February 2000, Amsterdam, NL 1. Draft Note: for any updates between now and just before the WG meeting, watch the DB WG Mailing List, please! Slot #1, Thursday, Feb. 24th, 09:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (Wilfried Woeber, chair) B. RIPE DB, operational update (NCC: AMRM, 20min.) C. A short review on the maintainer mechanism - are there any security concerns? D. (tentatively) Is there an interest to register CERT/IRT-related info? - brainstorming/proposals Slot #2, Thursday, Feb. 24th, 11:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E. Status of the reimplementation project (NCC: JLSD, 20min.) F. Transition to ripe db v3.0 and transition TF (JLSD & WW, 15min G. Do we need/want a DB WG review/re-structuring? - future topics of interest (workplan/charter?) - I/O with other WGs - logistics Y. Input from other WGs - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 15-FEB-2000 17:23:23 -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Common sense requires a common language... __________________________________________________________________________

1 0

Whoisd buffer overrun
by RIPE Database Administration 03 Feb '00

03 Feb '00

Dear colleagues, It was brought to our attention last night that the perl whoisd server the RIPE NCC is currently running is vulnerable to a buffer overflow attack. We have taken action immediately and fixed this problem on our production servers. We have also checked for traces of people taking advantage of the vulnerability and concluded that this was not the case. The whois service was not affected. Should you be running a copy of our software, please apply the patch attached below to bin/whoisd. It truncates the query to 255 characters. If you have any questions or comments, please contact <ripe-dbm(a)ripe.net>. We would like to thank Geert Jan de Groot and Steve Bellovin for bringing this to our attention. Kind Regards, Mirjam Kuehne Head External Services RIPE NCC -------------------- 1. save the following text as /tmp/whoisdpatch ----------cut here------------------------------ *** whoisd.trunc Wed Feb 2 22:28:34 2000 --- whoisd Wed Feb 2 22:29:46 2000 *************** *** 1679,1694 **** $query=join(" ", @ARGV); } else { - my($trunclen); - alarm $KEEPOPEN if (!$commandline); $query=<$input>; - - # truncate to 255 chars - $trunclen = length($query); - $trunclen = 255 if $trunclen > 255; - substr( $query, $trunclen ) = ""; - } # &dpr("query: -$query- errorcode: -$!-\n"); --- 1679,1686 ---- ----------cut here-------------------------------- 2. execute in the directory where your whoisd lives: $ patch < /tmp/whoisdpatch

3 2

Top 100 Maintainers List 20000203
by RIPE Database Administration 03 Feb '00

03 Feb '00

1 0

Fault vs. feature in the 'mnt-by' mechanism
by Carsten Schiefner 28 Jan '00

28 Jan '00

Folks, I would like to draw your attention to a fact that might be intended as a feature but what I consider more or less as a fault: I can't find any good reason that it is possible to protect objects which are previously unprotected or protected with an own mnt object also with other strong ("password") mnt objects without knowing the password of this maintainer. So it is possible for almost everyone to enter a bunch of bogus objects in the RIPE database without protection and then - as a 2nd step - to update all these objects, now including our company's mnt objects - thus we will become "responsible" for these bogus objects in a way, but we won't get aware of it. This may not be so significant for person objects, but is definitely much more serious regarding AS or route objects - so a redesign of this protection mechanism should be discussed at least. Please see http://www.ripe.net/cgi-bin/whois?sg4456-ripe as an example. Best regards, Carsten Schiefner -- Carsten Schiefner mailto:carsten.schiefner@tcpip-gmbh.de TCP/IP GmbH, Berlin (Germany) http://www.tcpip-gmbh.de Phone: +49.30.443366-0 Fax: +49.30.443366-15 Mobile: +49.172.5425797 TCP/IP GmbH runs the Contrib.Net backbone http://www.contrib.net ======================================================================

2 1

New tool announcement from Merit/IRRd: IRRj
by Jonathan Poland 22 Jan '00

22 Jan '00

Merit's IRRd team is pleased to announce the 1.0 Beta version of IRRj, a Java interface to the Internet Routing Registry. IRRj replaces the traditional e-mail submission process for database objects, and offers the following features: - Speed: IRRj opens a TCP socket connection to IRRd and provides fast, immediate feedback on the success or failure of your object submission. - Authentication: supports CRYPT-PW, PGP-FROM, and NONE authentication schemes transparently. - IRRd query support: offers full querying capabilities to retrieve objects for editing and resubmission. - Custom editing features: automatically appends delete fields to all objects, imports object templates. - Split window interface: IRRj includes a submission window and an IRRd feedback window. IRRj can be invoked from the Web or as a standalone application. System requirements are Sun's JDK (free from java.sun.com), Netscape 4.5+ or Java Plugin 1.2.2 (Internet Explorer or Netscape on Win32). IRRj runs on any Java capable machine, including Windows, Solaris, and most flavors of Unix. IRRj object submission will work with the RADB and any other IRR database that supports the IRRd synchronous object submission protocol. See http://www.irrd.net for more information about the freely available IRRd software. IRRj is freeware and can be downloaded and/or invoked from the web at: http://www.merit.edu/ipma/javairr/irr.html Please contact the IRRd team (irrd-support(a)merit.edu) with comments, feedback, suggestions, or questions. Jon Poland IRRd Team

1 0

RE: DB consistancy checking tools
by Wilfried Woeber, UniVie/ACOnet 20 Jan '00

20 Jan '00

Matthew, I think this is an interesting proposal: >I have been wondering recently whether a separate group should be set up for >the sole purpose of creating tools/advise/methods/hints 'n' tips for LIR's >to keep on top of their entries and make management easier. A sort of RIPE >users working group not concerned with designing objects for the database >but how to put existing objects in it, remove them, manage them, etc. > >My 2c > >Matthew To start things moving, could you come up with a coarse draft of ideas and short-term goals to take up? On the more formal side, one of the possible solutions to accomodate that activity might be to create a TaskForce to work on well-defined items during RIPE35 (do you intend to particpate?). This TF might be supported by both LIR and DB, or sponsored by whichever group is seen to be appropriate... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________

1 0

None
by RIPE Database Administration 20 Jan '00

20 Jan '00

Dear All, Following a request from the Chair, here is the status of the works on the new implementation of the RIPE database. Currently we are testing the query part of the database. It has been made publicly available at http://www.ripe.net/ripencc/pub-services/db/reimp/ on December 31, 1999 and a message has been sent to the db-beta mailing list. The database contains about 2.5 million objects corresponding to all the objects as of June 17th. You should also be able to query it directly at reimp.ripe.net, port 43. Please have a look and let us know if you spot something terribly wrong. We would like to detect as many differences as possible with respect to the old database. We know that some types of queries returned wrong information in the old incarnation, notably the more/less specific route/inetnum queries. This changed now with the introduction of radix trees. There may be some bugs though, so everybody is encouraged to try the server and compare the output. The source code has also been released. It can be found at our ftp site: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.1.0beta1.tar.gz All comments are welcome. We are now actively working on making the server a near-real-time mirror client of our main (old) server, so that the data in both is nearly identical at all times. We are confident this will be available in the next days, maybe weeks. The part which needs most work is the update part. We are also working on that quite hard now. Our goal is to present the community with a working beta version including updates, around the time of the coming RIPE meeting at the end of February 1900^H^H^H^H2000. If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Marek Bukowy ____________________________ RIPE Database Administration.

1 0

RE: DB consistancy checking tools
by Wilfried Woeber, UniVie/ACOnet 20 Jan '00

20 Jan '00

With reference to: >From: stephenb(a)uk.uu.net >Date: Tue, 11 Jan 2000 11:49:34 +0000 (GMT) >Subject: DB consistancy checking tools >To: lir-wg(a)ripe.net > >Hi > After making a number of NEWBLOCK requests and recieving the > information back of the errors in the DB for the previous block, > i would like to make the suggestion to the RIPE NCC the we are > allowed accuess to this most useful tool. This way we could do > the consitancy checks and get our house in order before making > the NEWBLOCK request, lessening the load on RIPE and speeding > up the allocation of more CIDR. > >If there is enough interest can we add this as a point of discussion at >the LIR working group, or should it be in the DB group. > >BTW i do like the new web site. > >Regards, >-- >---------------------------------- >E-Mail: stephenb(a)uk.uu.net >Phone: +44 (0)1223 581051 I've got one tech Q and one org Q: Tech: Would you want to propose a "public release" of the tool (e.g. to be able to deploy it in a local environment), or would it be useful / sufficient to be able to trigger the tool (for a given address range) and to have access to the result? I'm aware of the fact that there might be access and/or security related issues requiring a solution, but we might be able to solve that as soon as we know what to look for.... Org.: Where is this to go? LIR or DB? Preferences? ( In general I prefer a path where the goals and application requirements emerge from an "application WG" and the implementation is then passed on to the DB-WG. ) Wilfried.

1 0

RE: DB consistancy checking tools
by Matthew Robinson 20 Jan '00

20 Jan '00

I have been wondering recently whether a separate group should be set up for the sole purpose of creating tools/advise/methods/hints 'n' tips for LIR's to keep on top of their entries and make management easier. A sort of RIPE users working group not concerned with designing objects for the database but how to put existing objects in it, remove them, manage them, etc. My 2c Matthew -----Original Message----- From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber@cc.univie.ac.at] Sent: 20 January 2000 13:07 To: stephenb(a)uk.uu.net Cc: lir-wg(a)ripe.net; woeber(a)cc.univie.ac.at; db-wg(a)ripe.net Subject: RE: DB consistancy checking tools

1 0

Top 100 Maintainers List 20000119
by RIPE Database Administration 19 Jan '00

19 Jan '00

1 0

Top 100 Maintainers List 20000103
by RIPE Database Administration 04 Jan '00

04 Jan '00

1 0

Problems with the RIPE Database.
by RIPE Database Administration 29 Dec '99

29 Dec '99

Dear Colleagues, This morning, the primary server for the RIPE Database had a serious hardware failure. Since that time, no updates of the RIPE Database have been possible. Queries are possible, but using the backup service. We are currently restoring the data. We must do this from backup tapes; thus, we do not expect to resume normal service until sometime between 2000 and 2200 GMT tonight. If you have sent updates, there is no need to send them again; they are being queued on another machine. We realise that this situation may cause you some inconvenience, but we are making every effort to fix it as quickly as possible. We are also investigating the subtle hardware failure that caused the original problem. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee _______________________ RIPE NCC Database Group

1 0

Problems with the RIPE Database.
by RIPE Database Administration 29 Dec '99

29 Dec '99

Dear Colleagues, This morning, the primary server for the RIPE Database had a serious hardware failure. Since that time, no updates of the RIPE Database have been possible. Queries are possible, but using the backup service. We are currently restoring the data. We must do this from backup tapes; thus, we do not expect to resume normal service until sometime between 2000 and 2200 GMT tonight. If you have sent updates, there is no need to send them again; they are being queued on another machine. We realise that this situation may cause you some inconvenience, but we are making every effort to fix it as quickly as possible. We are also investigating the subtle hardware failure that caused the original problem. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee _______________________ RIPE NCC Database Group

1 0

Top 100 Maintainers List 19991221
by RIPE Database Administration 21 Dec '99

21 Dec '99

1 0

Report: whois DB problems
by Joao Luis Silva Damas 14 Dec '99

14 Dec '99

Dear all, as you may be aware yesterday afternoon there was a power outage at about 14:30 in the machine room which hosts our servers at the AMS-IX. As a result of this, when power was recovered, we found that the main filesystem where the RIPE DB is located was corrupted beyond hope. Whois query service was promptly moved to a backup mirror machine located elsewhere. This machine has an up to date copy of the RIPE DB and is able to serve queries, although at a slower pace than the main server. Updates where queued until a full restore was completed and general sanity checking performed to ensure a complete restore of all pieces was in place, at about 1:00 am on Dec 14th 1999. Unfortunately, earlier today, the main server has unexplainably stopped operations and required a reboot, resulting in a service outage of about 15 minutes (time for the DNS to propagate data about the backup server). We are extremely sorry for all the inconvenience and are carrying a thorough analysis if the events in order to shorten outages should this kind if events happen again. Best regards, Joao Damas ===================================================== | Joao Luis Silva Damas http://www.ripe.net | | RIPE DB Group Manager email: joao(a)ripe.net | | RIPE NCC | | Amsterdam | =====================================================

1 0

Top 100 Maintainers List 19991208
by RIPE Database Administration 08 Dec '99

08 Dec '99

1 0

Top 100 Maintainers List 19991123
by RIPE Database Administration 23 Nov '99

23 Nov '99

1 0

Re: abusive changes of person handles (protect your maintainer!)
by Wilfried Woeber, UniVie/ACOnet 19 Nov '99

19 Nov '99

Hi Joao! >There are two issues here: >- The use of very weak protection methods (NONE and MAIL-FROM) (see *). wrt the "see *": I think they do have a point in principle. In reality (for many individuals, I suppose :-) it's still more staright-forward to fake a mail-from header than reverse-engineer a crypted password string in itself. However, given the fact that many operatinal environments these days require mail to be shipped multi-hop, the risk of disclosing the (clear text) password is greater than we might want to believe... >Would the community see this change in behaviour as a good thing? Definitely! Wilfried.

2 1

Delay in processing updates
by RIPE Database Administration 19 Nov '99

19 Nov '99

Dear Colleagues, We have currenly a larger update queue than usual. We expect that updates in the queue will be processed in 4-5 hours. If you have not yet received an acknowledgement to your updates, there is no need to send them again. All updates received by auto-dbm(a)ripe.net have been queued. We are sorry about the inconvenience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Re: abusive changes of person handles (protect your maintainer!)
by Joao Luis Silva Damas 19 Nov '99

19 Nov '99

Hi, maintainer abuse as described in Petra Zeidler's mail is something that is becoming increasingly frequent. There are two issues here: - The use of very weak protection methods (NONE and MAIL-FROM) (see *). Some people like these because all they are looking for is a notification mechanism, not a protection mechanism. The use of weak protection methods makes it easy for someone, intentionally or by accident, to override the maintainer protection. - The initial attachment of a maintainer to an object without one. In the current database, dating from more quiet days in the internet, anyone can attach any maintainer to an object that does not have a mnt-by field because that maintainer's authentication is not checked when the object does not have a mnt-by attribute. In the new database, currently in development, we are already thinking about doing the corresponding check before adding the maintainer (requiring proper authentication to add it, hopefully from the maintainer's owner). Would the community see this change in behaviour as a good thing? Best regards, Joao * Some people think otherwise. (eg see http://www.providerfrage.de/mnt.htm) ===================================================== | Joao Luis Silva Damas http://www.ripe.net | | RIPE DB Group Manager email: joao(a)ripe.net | | RIPE NCC | | Amsterdam | =====================================================

1 0

Re: A new type of referral
by Marcel Schneider 16 Nov '99

16 Nov '99

On Monday, 15 Nov 1999, Engin Gunduz writes: Dear Engin Gunduz We appreciate your efforts and consider your proposal a good idea. Looking forward to get it implemented asap. The CLIENTADDRESS will enable us to limit time and number of queries from referral servers by using a wrapper we wrote around our WHOIS that has configurable access mechanisms based on IP addresses. The background for all this is mainly privacy: people are currently using all means to get access to addresses of Internet users (mostly for spamming purposes). One means is querying RIPE's Josh because such queries could not be limited until now by the authoritative WHOIS server due to lack of detailed information (we would have had to limit the entire Josh). We also encourage other registries to configure their WHOIS servers to allow referral queries by RIPE and let their own WHOIS server answer authoritatively. Marcel > We will be implementing a new type of referral, to be used > to forward the querying client's IP address to the referred > whois server along with the query. Until now, there was no > way to let the referred whois server know the IP address > of the actual whois client, rendering the usage of an ACL > impossible without blocking all referred queries, on the side > of the referred whois server. > Briefly, > o A fourth kind of referral will be defined, CLIENTADDRESS (The other > three were RIPE, INTERNIC and SIMPLE). > o The IP address of the client will be sent to the referred whois > server, if the referral type is CLIENTADDRESS. > o The IP address will be sent using the -V flag. The version and the IP > address will be separated by a comma (eg, -Vripe2.3.1,193.140.45.45). > o No other flag will be forwarded to the referred whois server. > o When the server gets such a request, it will check the IP number of > the server which does the referral against a list of authorized whois > servers. If it is not in the list, it will be rejected. > o Then, the IP address of the client will be extracted from the -V flag > string and it will be regarded as if it is the IP address of a directly > querying whois client (ie, it is checked against the list of > DENYWHOISACESS list). > Please let us know about your ideas and comments regarding this issue, > Regards, > Engin Gunduz > RIPE NCC > DB Group

1 0

A new type of referral
by Engin Gunduz 15 Nov '99

15 Nov '99

Dear colleagues, We will be implementing a new type of referral, to be used to forward the querying client's IP address to the referred whois server along with the query. Until now, there was no way to let the referred whois server know the IP address of the actual whois client, rendering the usage of an ACL impossible without blocking all referred queries, on the side of the referred whois server. Briefly, o A fourth kind of referral will be defined, CLIENTADDRESS (The other three were RIPE, INTERNIC and SIMPLE). o The IP address of the client will be sent to the referred whois server, if the referral type is CLIENTADDRESS. o The IP address will be sent using the -V flag. The version and the IP address will be separated by a comma (eg, -Vripe2.3.1,193.140.45.45). o No other flag will be forwarded to the referred whois server. o When the server gets such a request, it will check the IP number of the server which does the referral against a list of authorized whois servers. If it is not in the list, it will be rejected. o Then, the IP address of the client will be extracted from the -V flag string and it will be regarded as if it is the IP address of a directly querying whois client (ie, it is checked against the list of DENYWHOISACESS list). Please let us know about your ideas and comments regarding this issue, Regards, Engin Gunduz RIPE NCC DB Group

1 0