November 1999 - 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

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