- db-wg - mailman.ripe.net

RE: Thoughts about authentication schemes
by Wilfried Woeber, UniVie/ACOnet 17 May '00

17 May '00

Dear Michael, Thank you very much for the suggestion and the write-up on what the use of the proposed mechanisms c/would be. First of all, cc:ing the WG list is to distribute your comments, as they are very appropriate and useful for the on-going discussions on improving security in the registry operations. Secondly I'd like to (briefly) address a couple of comments: The WG has already been chartered to work on a more up-to-date document as to which security mechanisms should be recommended. The common understanding is that anything weaker than digital signatures should be strongly dicouraged, exactly for the reasons you were giving. Still has to find it's way into a document. All the other mechanism should be phased out in due time - at least for any objectof "value". The other aspect, as to *which* particular mechanism or product should be used, is up for discussion and for consensus amongst the users of the RIPE DataBase. Initially, the recommendation from the TaskFore on DB Security was to go for PGP as the *first* mechanism to implement. At the same time we understood that PGP w/sh/could not be the *only* mechanism in the long run. Meanwhile the DB software re-implementation is close to being completed, GNU Privacy Guard has become available, and I'm sure things like S/MIME should be looked at. Actually, this might be a reason to revive the TF-SEC later this year? Please continue to participate in this discussion, and whenever you can, to pop in during one of the DB working group meetings. Regards, Wilfried. ______________________________________________________________________ From: mcb(a)cloanto.com To: "'Wilfried Woeber'" <Woeber(a)CC.UniVie.ac.at> Subject: Thoughts about authentication schemes Date: Fri, 12 May 2000 07:41:44 -0700 Hello, I just had an exchange of ideas with Marek Bukowy of RIPE Database Administration, and he suggested that I submit this to your attention before the RIPE 36 meeting. Basically, I was setting up CLOANTO-MNT, and looking at the authentication options I somehow wondered why there isn't something like a "MAIL-TO". As the recent case of fraud suffered by Network Solutions shows, MAIL-FROM can too easily be circumvented. This week even our company in Italy had to file criminal charges against an entity who forged email headers, using one of our domain names. This was a case of "spamming", but it could just as easily have been an episode of MAIL-FROM fraud. So I looked at CRYPT-PW, and searching for a tool to generate the encrypted password I quickly found out that an 8-character password, as is used by RIPE, can be un-encrypted in a matter of days, if not hours. Now, as documents like ripe-157 express (e.g. "It is very difficult to keep the information confidential and thus the RIPE NCC cannot take this responsibility."), RIPE is concerned about both security and responsibilities, and here we have a case where it is known that two authentication schemes are not secure, and thus somebody might even object that, given today's standards and knowledge, maybe their status of being qualified to serve as "authentication" could be challenged. True, there now is PGP, which IMHO is technically uncompromising for this purpose. In theory it has legal limitations in a few countries, but not any I am aware of in the RIPE area. PGP however can be pretty... complex to set up compared to an email-only authentication scheme. Not that I see PGP as being unreasonably complex, but apparently, if people still prefer MAIL-FROM or CRYPT-PW, they must have their practical reasons for doing so. PGP also expresses a "political" choice in a field where other "official" standards would tend towards S/MIME, X.509, etc. For this reason I would like to go back, with my consideration, to a possibly new, simple, yet more secure authentication method (compared to MAIL-FROM) which does not use any encryption, and which can therefore be quickly used with any email client. As such, maybe it could be one choice more to offer, and in the long term it could maybe become part of a more robust set of minimum standards. The way I thought of "MAIL-TO" is basically like MAIL-FROM, but the server (e.g. you), after receiving a request from one of the authorized "MAIL-TO" addresses, would send back to the same address a "magic number" (or alphanumeric data) to the sender, who would have to reply (quoting this data anywhere in the email body, even possibly with "> " etc. at the beginning of each line), and only after the reply the request would be accepted. This data would have both a unique part (no risk of duplicates) and a pseudo-random one (no practical way to guess it). In this way, "MAIL-TO" would formally verify that the sender has access to the given email address, in such a way as has been adopted in everyday practice for years by companies such as VeriSign and Thawte for the distribution of email and web certificates. It is true that a possible "MAIL-TO" scheme would be open to sniffing, but MAIL-FROM and CRYPT-PW also are, and the data which is transmitted is not sensitive by definition, as RIPE itself says it prefers not to take responsibility for securing sensitive data, and the data usually ends up in a whois database anyway. Also, "MAIL-TO" would indeed require one more step than "MAIL-FROM". This is in my opinion the small price to pay if one prefers not to use full encryption or digital signing. Yes, I think it would be only one more step, because in my experience, where MAIL-FROM is implemented, two or three steps (not one) are already required, because the second part of the system involves that a preset address receives a notification of the change request. This is not subject to confirmation (as would be in "MAIL-TO"), but it is nevertheless a second step, and it requires attention and readiness for a possible third step ("CANCEL" action) in case an abuse is detected. So on one hand we have one step more (or zero steps more in case of abuse), but on the other hand we get peace of mind. The reply mechanism could even be implemented in an automatic way on the side of the data submitter. Well, this now got a bit more lengthy than I intended it to be, sorry about that! It's just that I felt the need for such an option, and I would not like to see what happened to Network Solutions also happen to you, or to one of the national NICs who adopt your guidelines, especially knowing that forging email headers happens everyday, and that it has already happened in a major case involving a major registration authority. Thanks for caring, and I wish you a nice time in Budapest! Regards, Michael C. Battilana --------------------------------------------------------------------------------

1 0

Problems RIPE Whois Service.
by RIPE Database Administration 17 May '00

17 May '00

Dear Colleagues, (Apologies if you receive this message more than once). Earlier this evening, the main RIPE Database server crashed. Your updates are not being processed at this time, but they are being queued; there is no need to send them again. Queries are being processed by a backup server; thus, the response time may be longer than usual. We are aware of the inconvience that this causes you and we are working to restore the service as quickly as possible. We shall keep you informed. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ------------- RIPE NCC

1 0

ANNOUNCEMENT: Beta 0.1 of asused-public released
by John Crain 15 May '00

15 May '00

Dear Colleagues, We, the RIPE NCC, are pleased to announced the release of the beta version of asused-public. This is a tool to summarise address space that is registered in the RIPE database. For a given list of allocations the software prints various information concerning the allocations and the assignments they contain. the software "asused-public" is based on one the NCC's internal tools. It has been revised for public release in a form that does not make use of any customer confidential information. The software which uses several perl modules, these are included, is stored in the following file: ftp://ftp.ripe.net/tools/asused-public.0.1.tar.gz We are keen to receive your feedback on the beta release. Please address your comments and/or suggestions to our Software Manager, Maldwyn Morris <Maldwyn.Morris(a)ripe.net> Yours, John LeRoy Crain Head of Internal Services RIPE NCC

2 1

domreg tools
by Randy Bush 15 May '00

15 May '00

does anyone have forms and scripts to automate domain registration? what i mean by that is o a form for the registrant to fill out and email (and/or web page) i have appended what i currently use o a script to - extract person, and domain info and create ripe format objects - create nic handles if needed - extract server info and create dns database entry texts o etc. i have the form (appended) and some elisp and scripting to make a dns file entry. but now i want to go the whois path. all help appreciated. randy --- PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY. Send your GN registration to randy(a)psg.com. See attached detailed instructions. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - 0. KE DOMAIN TEMPLATE....: 1.30 99.12.05 1. REGISTRATION TYPE * (N)ew (M)odify (D)elete..: 2. * FULLY-QUALIFIED DOMAIN NAME: 3. ORGANIZATION INFORMATION 3a.* Organization Name.....: 3b.* Address Line 1........: 3b.* Address Line 2........: 3c.* City..................: 3d.* Postal Code...........: 3e.* Country...............: 4. * DESCRIPTION OF ORG/DOMAIN: 5. Date Operational......: 6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN 6a. NIChandle (if known)..: 6b.* Whole Name............: 6c. Organization Name.....: 6d.* Address Line 1........: 6d. Address Line 2........: 6e.* City..................: 6f.* Postal Code...........: 6g.* Country...............: 6h.* Voice Phone...........: 6i.* Electronic Mailbox....: 7. TECHNICAL AND ZONE CONTACT 7a. NIChandle (if known)..: 7b.* Whole Name............: 7c. Organization Name.....: 7d.* Address Line 1........: 7d. Address Line 2........: 7e.* City..................: 7f.* Postal Code...........: 7g.* Country...............: 7h.* Voice Phone...........: 7i.* Electronic Mailbox....: 7j.* Registration Mailbox..: 7k. Fax Number............: FILL OUT QUESTION 8 AND 9 FOR DELEGATIONS ONLY (i.e those organizations running nameservers for a branch of the KE Domain namespace, 8. PRIMARY SERVER: HOSTNAME, NETADDRESS 8j.* Hostname..............: 8k.* IP Address............: 9. SECONDARY SERVER: HOSTNAME, NETADDRESS 9a.* Hostname..............: 9b.* IP Address............: FILL OUT QUESTION 10 FOR DIRECT REGISTRATIONS IP HOSTS (if you answered 8 & 9, do not answer 10, 11, and 12) 10. RESOURCE RECORDS (RRs) FOR IP INTERNET HOSTS 10a.* IP ADDRESS (required).: 10b. HARDWARE .............: 10c. OPERATING SYS ........: 10d.* MX ...................: It is your responsibility to see that an IN-ADDR pointer record is entered in the DNS database. Contact the administrator of the IP network your host is on to have this done. FILL OUT QUESTIONS 11 AND 12 FOR NON-IP HOSTS (such as UUCP) 11. FORWARDING HOST INFORMATION 11a.* Forwarding Host.......: 11b.* Contact Name (req)....: 11c.* Contact Email (req)...: 12. RESOURCE RECORDS (RRs) FOR NON-IP HOSTS (UUCP) 12a. DOMAIN NAME ..........: 12b. HARDWARE .............: 12c. OPERATING SYS ........: 12d.* MX (required).........: < and all sorts of instructions > --- and my elisp/perl hacks produce, for example ; T F Nyammo ; Kenya School of Professional Studies ; P.O.Box 60550 ; Nairobi ; 60550 ; Kenya ; 750255-58 ; ftnyammo(a)swiftkenya.com ; FD1304 ; DNS-admin FutureQuest ; FutureQuest ; PO Box 420820 ; Kissimmee, FL ; 34742-0820 ; United States ; dns-admin(a)FutureQuest.net ; ksps.ac.ke. NS ns1.FutureQuest.net. NS ns1.granitecanyon.com. ;----------------------------------------------------------------------- dig +norec ksps.ac.ke. @ns1.FutureQuest.net. ns dig +norec ksps.ac.ke. @ns1.granitecanyon.com. ns the two dig commands are so i can cut and past to check for properly configured servers. -30-

2 1

ke
by Randy Bush 14 May '00

14 May '00

-----BEGIN PGP SIGNED MESSAGE----- domain: KE descr: Kenya ccTLD admin-c: SJO2 tech-c: RB366 zone-c: RB366 refer: RIPE whois.rg.net mnt-by: MAINT-RGNET changed: randy(a)psg.com 20000513 source: RIPE -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBOR4Yd/vCP42xMxQ5AQEPLwP+L1h/+Ht9e5RphVXn6yqdhs8N//xjXZQU Hic1jbknbVqtpFzmBapy61EX3G1u+viTJmIRODaCK2z0Sik07g4z0At4bmMpt+gD /Nw4cNsPTA+DhbQt3/k06a0LO8MmacOM3ZcvFRsdmncPs+zQ9brrXwWcL6OfzY7s xmUNKBTJuNs= =YKxX -----END PGP SIGNATURE-----

1 1

New beta release of the RIPE Database Reimplementation software
by RIPE Database Administration 12 May '00

12 May '00

Dear All, This mail is to notify you of the further progress in the development of the new implementation of the RIPE Database software. The software has a temporary name of RIP, which stands for "Re-Implementation Project". Today, we have made a new prototype of the source code. There have been many changes since the last prototype: most notably, the update functionality has been integrated to the server. You can download this last prototype at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.3.0beta2.tar.gz You can also test the functionality of this prototype of the RIP whois server in 2 ways: - By querying the host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror in RPSL format of the live RIPE Database. - By using the RIP Test Database. You can send test updates to this database at the address <auto-rip(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. Please note the following things when sending updates to the RIP Test DB: - you will get very simple acknowledgements; - mntner, as-block and aut-num objects cannot be created yet; - no notifications are being sent to the "notify" addresses. We would be very pleased if you could test the new implementation in both ways, and let us know your opinions. Please let us also know of any bugs you can find. Please send your comments to the <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. 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

Top 100 Maintainers List 20000509
by RIPE Database Administration 09 May '00

09 May '00

1 0

Top 100 Maintainers List 20000425
by RIPE Database Administration 25 Apr '00

25 Apr '00

1 0

RE: DB consistancy checking tools
by Matthew Robinson 18 Apr '00

18 Apr '00

Firstly my sincere apologies for not sorting something out earlier. I've spent most of my time either building networks or looking after my son Lewis, born 26/03/2000 (two weeks late), weighing 5450g or 12lbs 4oz (I like to over engineer)! The hospital didn't include any instructions and despite several detailed searches I have been unable to locate either a RIPE document or RFC detailed care of a newborn baby! Are people still interested in the idea of a users forum as described below and should we try to have a BoF in Budapest or do we still need more of an list based discussion? -----Original Message----- From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber@cc.univie.ac.at] Sent: 20 January 2000 14:55 To: matthew(a)planet.net.uk Cc: lir-wg(a)ripe.net; db-wg(a)ripe.net; woeber(a)cc.univie.ac.at Subject: RE: DB consistancy checking tools 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...

1 0

Top 100 Maintainers List 20000412
by RIPE Database Administration 12 Apr '00

12 Apr '00

1 0

no answer from the RIPE NCC mail-distribution-robot...
by Bornhorst, Ludger 06 Apr '00

06 Apr '00

Hello All, since Tuesday, 04.04.2000 I sent three mails to the RIPE NCC hostmaster account 1. Mail for Ticket NCC#2000012331 2. Mail for Ticket NCC#2000036750 3. Mail for a new address request (no Ticketno yet) and nothing happened. Normally I get a response from the RIPE NCC mail-distribution-robot within minutes, or at least hours. Now it is Thursday and the Mails haven't bounced, so I think they must have been received by someone. Maybe there is a failure at the RIPE NCC mail-distribution-robot...? Am I alone with this, or did anyone have the same experience? kind regards +-----------------------------------------------------------------------+ | Ludger Bornhorst Ludger.Bornhorst(a)telekom.de | | Deutsche Telekom AG | | Network Information Center tel +49 441 234 4581 | | Oldenburg, Germany fax +49 441 234 4589 | +-----------------------------------------------------------------------+

2 1

Re: no answer from the RIPE NCC mail-distribution-robot...
by henning.brauer＠bsmail.de 06 Apr '00

06 Apr '00

Hi all, having the same probs. Normally I had answers within minutes, now it's days. There are some hard performance problems at Ripe as far as i were informed what makes our business no easier... Greetings from Germnay Henning Brauer ------------------------------------------------------------ BS Web Services part of Mediadeck Rödingsmarkt 14 20459 Hamburg Germany Fon (040) 37 503 57-0 Fax (040) 37 503 57-5 www.bsws.de info(a)bsmail.de "Bornhorst, Ludger" <Ludger.Bornhorst@t To: db-wg(a)ripe.net elekom.de> cc: "'ripe-dbm(a)ripe.net'" <ripe-dbm(a)ripe.net> Sent by: Subject: no answer from the RIPE NCC mail-distribution-robot... owner-db-wg(a)ripe.ne t 06.04.00 08:56 Hello All, since Tuesday, 04.04.2000 I sent three mails to the RIPE NCC hostmaster account 1. Mail for Ticket NCC#2000012331 2. Mail for Ticket NCC#2000036750 3. Mail for a new address request (no Ticketno yet) and nothing happened. Normally I get a response from the RIPE NCC mail-distribution-robot within minutes, or at least hours. Now it is Thursday and the Mails haven't bounced, so I think they must have been received by someone. Maybe there is a failure at the RIPE NCC mail-distribution-robot...? Am I alone with this, or did anyone have the same experience? kind regards +-----------------------------------------------------------------------+ | Ludger Bornhorst Ludger.Bornhorst(a)telekom.de | | Deutsche Telekom AG | | Network Information Center tel +49 441 234 4581 | | Oldenburg, Germany fax +49 441 234 4589 | +-----------------------------------------------------------------------+

1 0

RIPE Database main server up and running again
by RIPE Database Administration 28 Mar '00

28 Mar '00

Dear All, Thank you for your patience. The RIPE Database main server is now up and running again. The queue of updates is being processed, but please take into account that it will take several hours to clear the queue. Technical details: The failure of one of the memory modules of the server caused a parity error, thus forcing the kernel to panic. The memory module had to be replaced and tested. We are very sorry for the inconvenience caused. If you have any questions or comments, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Daniele Arena ____________________________ RIPE Database Administration.

1 0

Whois service running on a backup server
by RIPE Database Administration 28 Mar '00

28 Mar '00

Dear Colleagues, Unfortunately this morning the main RIPE Whois server experienced a hardware crash. We switched the service to a backup server; thus you may find that the response time for whois queries is longer than usual. The updates are currently not being processed, but they are queued; they will be processed as soon as the main server is up and running again. There is no need to resend your updates. We are currently working to repair the hardware damage on the main server, and we hope to return to the normal situation as soon as possible. Please accept our apologies for this inconvenience. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Daniele Arena ____________________________ RIPE Database Administration. P.S.: Apologies if you receive this mail more than once.

1 0

New DB release 2.3.1
by RIPE Database Administration 21 Mar '00

21 Mar '00

Dear colleagues, We have made available the new release of RIPE Perl database software at our fto site. You can find it at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.3.2.tar.gz Please find attached notes of the new release. Please note that CLIENTADDRESS type of referral can be used in our production server readily. Best regards, RIPE NCC DB Group ----------------- RELEASE NOTES for RIPE Database 2.3.2 This is mainly a bugfix release, without major new features added. There are also a few maintenance and performance-related changes, and an important security fix. SUPPORTED SYSTEMS This release has been tested with perl 5.00502 on BSDI3.1 and perl 5.00404 on Solaris 2.6 systems. Please let us know if you have problems running it on other systems. NEW FEATURES - New type of referral: CLIENTADDRESS o A fourth kind of referral is defined, CLIENTADDRESS (The other three were RIPE, INTERNIC and SIMPLE). o The IP address of the client is sent to the referred whois server, if the referral type is CLIENTADDRESS. o The IP address is 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 checks 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. The list is named AUTHORIZEDFORREFERRAL in the configuration. o Then, the IP address of the client is 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 DENYWHOISACCESS list). MAINTENANCE RELATED CHANGES - Introduced some debugging functionality: WHOISDSTAT - creation of files describing the activity of whoisd query processes. Those are normally deleted if the whoisd exits the normal way. WHOISDSTAT is a base filename for those files. - Introduced some limitation on bad clients: QUERYLOOPLIMIT defines a limit for '-k' connections. If more than so many queries for the same search term are detected, QUERYLOOPTXT is printed and the connection is closed. Mainly meant to protect against ptraceroute parsing broken as-macros. SECURITY FIXES - On February 2, 2000, we got a report for a possible buffer overflow in whoisd. An extremely long and specific query, such as the following: % whois `perl -e '{print "0." x 20000}'`(a)joshua.ripe.net (query example from a Linux host; it does not work, of course, if the client has built-in query size limits) caused the forked server process to crash with a segmentation fault. We immediately introduced a patch on whoisd.pl, truncating the queries to 255 characters immediately after they were being read. BUG FIXES - cross-misc: now the sender of cross-notifications is set to HUMAILBOX. - whoisd.pl: o the text for DENIED connection was mistakenly printed on STDOUT. o The timeout handler would wait infinitely to print a msg about closing the connection. Now an alarm has been set up to stop it, the message can be printed to WHOISDSTAT file if active. PERFORMANCE FIXES - addkey: The overflow file handling has been modified, so that it would use a smaller amount of memory.

1 1

Top 100 Maintainers List 20000314
by RIPE Database Administration 14 Mar '00

14 Mar '00

1 0

Charter? Does anybody have a copy
by Nigel Titley 07 Mar '00

07 Mar '00

Gentlefolk, At the last RIPE conference I made the mistake of putting up my hand and offering Wilfried help in putting the paperwork of the DB WG in order. One of the first things I'd like to sort out is the group charter. Does anybody have a copy? It probably needs some work doing on it by now, but if we've got an old one, at least it will be a start. Thanks Nigel -- Tel: +44 171 864 4450 Fax: +44 171 864 4488 Well I'm disenchanted too. We're all disenchanted (James Thurber) (http://www.seanet.com/~thurber/disenchanted.gif)

3 4

RE: DB consistancy checking tools
by Matthew Robinson 07 Mar '00

07 Mar '00

I won't be at RIPE-35 as my first child is due at the same time but I'll definitely knock something together as a draft. If other people are interested then things should go ahead at RIPE-35 otherwise I do have permission from my wife to attend RIPE-36 ;-) Kind regards Matthew -----Original Message----- From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber@cc.univie.ac.at] Sent: 20 January 2000 14:55 To: matthew(a)planet.net.uk Cc: lir-wg(a)ripe.net; db-wg(a)ripe.net; woeber(a)cc.univie.ac.at Subject: RE: DB consistancy checking tools 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.

6 6

Re: DB consistancy checking tools
by mediaWays Hostmaster 06 Mar '00

06 Mar '00

Hi, we do whois -h whois.ripe.net -r -m <our Allocation/16> | grep inetnum | sed "s/inetnum: //" | sed "s/ - /./" > <some file> for our Allocations once a month and analyse this with awk script #!/usr/bin/sh nawk -F. 'BEGIN{summe=0} NF==8 { for(i=1; i<=NF; i++) byte[i]=$i; if(byte[3]!=byte[7]) { size=(byte[7]-byte[3])*256; if(byte[4]>byte[8]) size-=byte[8]-byte[4]; else size+=byte[8]+byte[4]; size++; } else { size=byte[8]-byte[4]+1; } summe+=size; printf("%s: %d IPs\n", $0, size); } END{printf("Summe %ld\n", summe);}' < <some file> so we could calculate the #IPs, check overlappings, check our own IP-DB against it ... and so on. We hope that this querys do not bother the RIPE-DB ;-) Kind Regards, _____________________________ Stephan Mankopf +49 5241 80 88729 stephan.mankopf(a)mediaways.net

1 0

Attn. NRTM clients: Missing serial files(2)
by RIPE Database Manager 01 Mar '00

01 Mar '00

Dear Colleagues, The message that was sent to you concerning the missing serial files contains an unfortunate misprint: the number of missing serial files is 605, not 30605 as was reported. The missing range is 8929802-8930406. Again, sorry for trouble and inconvenience. If you have any further questions, please do not hesitate to contact <ripe-dbm(a)ripe.net> Regards, Andrei Robachevsky ____________________________ RIPE Database Administration.

1 0

Attn. NRTM clients: Missing serial files
by RIPE Database Manager 29 Feb '00

29 Feb '00

Dear Colleagues, Due to a filesystem problem, 30605 serial files were not written. The missing range is 8929802-8930406. Unfortunately to continue near real-time mirroring of the RIPE database, you will need to resync with the RIPE database. The new snapshot of the database will be available tonight (at 1 a.m. CET, 1 March). This problem does not affect the queries and the RIPE databse consistency. Sorry for trouble and inconvenience. If you have any further questions, please do not hesitate to contact <ripe-dbm(a)ripe.net> Regards, Andrei Robachevsky ____________________________ RIPE Database Administration.

1 0

inetnum conversion
by Engin Gunduz 28 Feb '00

28 Feb '00

Dear colleagues, RIPE NCC will be converting the legacy inetnum objects which are in old classful notation into classless range notation. We provide the list of inetnum objects to be converted during this process at: http://www.ripe.net/ripencc/pub-services/db/in_conversion/ There are 16404 such inetnums in the RIPE whois database, so we have divided them in four parts, but the list is available also as a big single file. The list contains the classful notation, new classless notation and the netname of the inetnums. The conversion is planned to take place on 26-27 February. You can check the list for your inetnum objects. If you detect a problem, please contact <ripe-dbm(a)ripe.net>. Also, please send your comments about the conversion to the list, Regards, Engin Gunduz RIPE NCC Database Group -----------------------

1 2

Re: RIPE DB service restored
by Janos Zsako 23 Feb '00

23 Feb '00

> From owner-lir-wg(a)ripe.net Wed Feb 23 13:47:01 2000 > From: Nils Jeppe <nils(a)work.de> Dear Nils, > Yes, one question; why haven't you announced taking down the DB? I find > this unacceptable, some of us have to work with it you know? We have > customers which need new Person objects, new Domains, etc. etc. Now, I > understand perfectly if there are emergency maintainances or whatever, but > don't just switch it off for an entire day without at least letting us > know! How much effort would it have been if you had written a seven line > email explaining that you have to take the DB down, and why? > > It's not like you're some kind of Internet Dictatorship or IP God which > can do as it pleases; the RIPE NCC takes care of this stuff on the behalf > of the LIRs and is financed by the LIRs, so this heavy-handed approach is > really not something I appreciate. I guess the RIPE community in general does not appreciate YOUR approach (at least I do not). :(( Please find below the mail the RIPE NCC sent out BEFORE they turned updates off. I guess you have not been at the RIPE meetings and did not follow the work the RIPE NCC has been doing in the last many years. Otherwise I do not think you would make a remark like the above. Best regards, Janos > > > Best wishes, > Nils Jeppe > > > On Tue, 22 Feb 2000, RIPE Database Administration wrote: > > > > > Dear Colleagues, > > > > We wish to announce that the whois and update service > > of the RIPE Database has returned to normal. Currently, the > > queue of updates is being processed. We expect this queue to > > be cleared later this evening. > > > > Thank you for being patient. You will find that the service > > level of the RIPE Database has been improved. If you > > have questions, please contact <ripe-dbm(a)ripe.net>. > > > > If you have any questions, please don't hesitate > > to contact <ripe-dbm(a)ripe.net>. > > > > Regards, > > > > Daniele Arena > > ____________________________ > > RIPE Database Administration. > > > > ----- Begin Included Message -----

4 3

RIPE DB service restored
by RIPE Database Administration 22 Feb '00

22 Feb '00

Dear Colleagues, We wish to announce that the whois and update service of the RIPE Database has returned to normal. Currently, the queue of updates is being processed. We expect this queue to be cleared later this evening. Thank you for being patient. You will find that the service level of the RIPE Database has been improved. If you have questions, please contact <ripe-dbm(a)ripe.net>. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Daniele Arena ____________________________ RIPE Database Administration.

2 1

Updates to the RIPE whois database stopped
by RIPE Database Administration 21 Feb '00

21 Feb '00

Dear All, Due to a crash of our whois server which we experienced last Saturday we are stopping the updates tonight and we are going to reindex the data. There is no need to resend your updates. The updates will be queued and they will be resumed tomorrow. We are also going to upgrade the main server so that it can cope better with the ever growing load. The whois query service will be switched to our backup server, therefore the response time will be slower than usual. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Marek Bukowy ____________________________ RIPE Database Administration.

1 0