- db-wg - mailman.ripe.net

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