- db-wg - mailman.ripe.net

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

Top 100 Maintainers List 19991108
by RIPE Database Administration 08 Nov '99

08 Nov '99

1 0

Reminder: RPSL Transition
by Gerald Andrew Winters 29 Oct '99

29 Oct '99

A final reminder for users of the RADB database service: at 12:00:00 a.m. EDT on November 1, 1999, the whois.radb.net and auto-dbm(a)radb.net services will default to the Routing Policy Specification Language (RPSL) database. This means that whois queries to whois.radb.net after November 1 will return RPSL objects. RIPE-181 queries will still be possible after November 1 via whois queries to whois-ripe181.radb.net and email submissions to auto-ripe181(a)radb.net. In addition, between 11/1/99 and 1/1/00, RIPE-181 submissions will be auto-converted and folded into the RPSL database. Users need to be aware of this, as corresponding RPSL entries will be overwritten with the auto-converted RIPE-181 objects. You will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net. During the changeover, the whois.radb.net DNS entry will be changed to point to the production RPSL database. Because of DNS latency, there will be a period of time when all resolvers have not received the new DNS entry IP address. During this transition period, some users may want to manually configure the IP address used by their query tools. The IP addresses of the machines will be: whois.radb.net 198.108.0.18 (RPSL queries) whois-ripe181.radb.net 198.108.0.11 (RIPE-181 queries) For further information about the transition to RPSL, see: http://www.radb.net/announce.html Comments or questions about the transition are welcome; please send email to db-admin(a)radb.net. --Gerald Winters Merit IRRd Team

1 0

RPSL Transition
by Gerald Andrew Winters 26 Oct '99

26 Oct '99

A reminder for users of the RADB database service: at 12:00:00 a.m. EDT on November 1, 1999, the whois.radb.net and auto-dbm(a)radb.net services will default to the Routing Policy Specification Language (RPSL) database. This means that whois queries to whois.radb.net after November 1 will return RPSL objects. RIPE-181 queries will still be possible after November 1 via whois queries to whois-ripe181.radb.net. However, you will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net. RIPE-181 submissions made between 11/1/1999 and 1/1/2000 will be visible on whois.radb.net as RIPE-181 objects converted to RPSL. The objects will be converted every five minutes from the whois-ripe181.radb.net database. Availability of the database in both syntax languages will ease the transition to RPSL by allowing users to view RIPE-181 objects converted to RPSL. fter January 1, 2000, RIPE-181 object submissions will no longer be accepted. Here is the full transition schedule: DATE CHANGE ---- ------ 9/1/1999 RADB begins production RPSL service and enters the final stage of RPSL transition. RPSL queries are available from whois-rpsl.radb.net and submissions may be sent to auto-rpsl(a)radb.net. RIPE-181 and RPSL databases operate in parallel. whois.radb.net and auto-dbm(a)radb.net default to RIPE-181. 11/1/1999 Default whois.radb.net and auto-dbm(a)radb.net addresses change to RPSL database. RIPE-181 queries still possible via whois-ripe181.radb.net and RIPE-181 submissions still possible via email to auto-ripe181(a)radb.net. auto-ripe181(a)radb.net submissions will be auto-converted to RPSL and mirrored to the RPSL database every 5 minutes. Therefore, auto-converted RIPE-181 submissions will be visible on whois.radb.net and corresponding RPSL entries may be overwritten. 1/1/2000 RIPE-181 queries and submissions are no longer accepted and the RADB RPSL transition is complete. RADB users can query RPSL objects by issuing the following query: whois -h whois-rpsl.radb.net Objects may be submitted by sending mail to: auto-rpsl(a)radb.net Users may also use the Web-based GUI interface at: http://www.radb.net/irrj.html RPSL RFCs and Internet-Drafts are available through: http://www.ietf.org/html.charters/rps-charter.html Comments or questions about the transition are welcome; please send email to db-admin(a)radb.net. --Gerald Winters Merit IRRd Team

1 0

Top 100 Maintainers.
by RIPE Database Administration 21 Oct '99

21 Oct '99

1 0

New DB release 2.3.1
by RIPE Database Administration 14 Oct '99

14 Oct '99

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.1.tar.gz Please find attached notes of the new release. Best regards, RIPE NCC DB Group ----------------- RELEASE NOTES for RIPE Database 2.3.1 This is a bugfix release with no new functionality added. There are some operational changes which should be transparent to the end user but ease the database maintenance and (dramatically) improve performance. SUPPORTED SYSTEMS ================= This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. CHANGES ======= Incorporated MAXLISTLENGTH and MAXSTRINGCOMPONENTS variables into the configuration file. They define the internal buffer sizes for reindexing; MAXLISTLENGTH defines the max length of the list of index entries, MAXSTRINGCOMPONENTS (name preserved for historical reasons) determines the number of entries for classless indices. Whoisd: added a 3 seconds delay before denied connections are dropped. In the inet6num objects, quads are zero padded to improve readability. Comparison of objects set to ignore the differences in number of whitespaces. BUG FIXES ========= Maintainer checks for dbupdate -T (test database) were not correct. Fixed setpriority parameters for whoisd {-L|-M|-m}. If invoked with wrong uid, dbupdate would fail silently. Now prints a message and exits 75. A range in class A ending with ?.?.?.0 would be changed to ?.255.255.255. Also fixed /32 ranges (beginning=end). PERFORMANCE FIXES ================= Turning splits and joins into a regexp substitution in key handling code decreased the CPU usage. Nic-handle generation algorithm takes 30-40 steps now instead of up to a few thousand.

3 2

Top 100 Maintainers List 19991004
by RIPE Database Administration 04 Oct '99

04 Oct '99

1 0

object definitions
by Chris Ottrey 04 Oct '99

04 Oct '99

Hello, Work here at the NCC on the Re-Implementation Project (RIP), is well under way. We have been looking closely at the existing definitions of objects incorporating them into our new design. We thought that now might be a good time for getting ideas on any changes in the object definitions that the wg would like to see. Eg. - "mandatory" mnt_by field in domain - "mandatory" mnt_by field in inetnum - "mandatroy" mnt_by field in person (instead of the current - "optional".) (Eg. to provide some sort of indication of how much protection users have against someone else deleting all their domains. Some users may not even realize that it is possible.) Existing object definitions can be found at: http://www.ripe.net/db/reimp/design/er/er_whois.html Chris. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= A ,-._|\ Chris Ottrey \_ / Oz \ At work in Amsterdam, \_,--._/ ottrey(a)ripe.net +31 20 535 4444 -=-=-=-=-=-v-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2 1

Top 100 maintainers list
by RIPE Database Administration 22 Sep '99

22 Sep '99

1 0

Maintainer report...
by Paul Rolland 21 Sep '99

21 Sep '99

Hello, Just one thing I'd like to point out : it seems that the database used to create the maintainer report is not sync with the 'live' db... I've been doing some deletion on Sunday, and got the Ack on monday Morning. Looking at the report generated this morning, refreshing, updating the pages again and again, I can still find the same 'mistakes' which are not in the live db (the update has really been processed). Am i missing something ? Regards, Paul Paul Rolland, rol(a)oleane.net France Telecom Oleane/Direction Technique/Directeur France Telecom Oleane/Technical Direction/Director -- Please no MIME, I don't read it - Pas de MIME, je ne le lis pas Please no HTML, I'm not a navigator - Pas d'HTML, je ne suis pas un navigateur "Some people dreams of success... while others wake up and work hard at it"

2 2

We think it may be interesting...
by Joao Luis Silva Damas 20 Sep '99

20 Sep '99

Hi, we have just made available some more operational information online for your convenience. Please see http://www.ripe.net/db/mrtg/whois.html Hope you find it useful. It uses the great mrtg tool. Best regards, Joao Damas RIPE DB Group manager RIPE NCC

2 1

report on nic handle reuse in the RIPE DB
by Joao Luis Silva Damas 17 Sep '99

17 Sep '99

Dear all, for your reading pleasure :-) This issue came up during the last RIPE meeting. Best regards, Joao Damas RIPE DB Group Manager RIPE NCC

4 3

RE: object definitions
by Wilfried Woeber, UniVie/ACOnet 16 Sep '99

16 Sep '99

>Subject: object definitions > >Hello, Hi Chris! [ nice to meet you! ] >Work here at the NCC on the Re-Implementation Project (RIP), >is well under way. Cute acronym, but don't get near Routing with that one :-) >We have been looking closely at the existing definitions of objects >incorporating them into our new design. > >We thought that now might be a good time for getting ideas on any >changes in the object definitions that the wg would like to see. > >Eg. > - "mandatory" mnt_by field in domain From a DB-WG's point of view, change requests for this one should be coming from the users of the Domain-Registry. I'd feel much more at ease if the request to change things would come from / at least be endorsed by the relevant WG (TLD-WG, probably?) > - "mandatory" mnt_by field in inetnum Likewise, just s/Domain-Registry/IP-Registry/ (LIR-WG?) > - "mandatory" mnt_by field in person This is probably something DB-WG can't push away to somewhere else :-) >(instead of the current - "optional".) > >(Eg. to provide some sort of indication of how much protection > users have against someone else deleting all their domains. Some > users may not even realize that it is possible.) In case we want to work on the awareness (first, even before deploying the new SW?), we could think about putting some sort of "(weakest/used) protection indicator" into the ack-messages? Something anlong the lines of: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following objects were processed. New OK: [inetnum] 193.170.2.0 - 193.170.2.255 protection: NONE Modified: [person] Spider Tarantula Woman (SPT1-RIPE) protection: ACONET-LIR-MNT, PGPKEY-DBC579D4 New OK: [domain] crack.ac.at protection: MAIL-FROM .*(a)cc\.univie\.ac\.at ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Maybe this is not a bad idea, anyway? >Existing object definitions can be found at: >http://www.ripe.net/db/reimp/design/er/er_whois.html > > >Chris. > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > A ,-._|\ Chris Ottrey > \_ / Oz \ At work in Amsterdam, > \_,--._/ ottrey(a)ripe.net +31 20 535 4444 >-=-=-=-=-=-v-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Thanks for bringing this up, and could the other WG chairs please indicate their preference for where to deal with that? TIA, Wilfried. PS: Chris, I hope your question indicates that the NCC is already very far down the road with implemenetation and testing, rather than fixing that very early on for whatever reason? I hope the new SW design still allows for modifying these things by way of some site config facility? -------------------------------------------------------------------------- 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 __________________________________________________________________________

1 0