- db-wg - mailman.ripe.net

Re: Ripe change to whois
by Hank Nussbacher 01 Dec '98

01 Dec '98

At 01:01 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: Yes, that may be all correct - from a techno standpoint. What I am stressing is the human engineering aspect. Up till now, thousands of hits are sent to the whois.ripe.net every month to determine whether a domain exists or not. Users have been doing this for years. Suddenly, the output is different and they do not realize it. I highly doubt that the human engineering aspect was discussed or analyzed to any extent in the DB WG. -Hank >Dear all, > >The implementation of the referral mechanism is a new feature of the latest >release of the RIPE DB software. > >The design of this feature was specified some time ago by Carol Orange and >Wilfried Woeber (please see http://www.ripe.net/meetings/ripe/ripe-27/pres/rout >e/referral/) and discussed in the RIPE db-wg mailing list (please see >http://www.ripe.net/mail-archives/db-wg/19970501-19970601/threads.html) > >According to this proposal the algorithm to be implemented is > >(extracted from the proposal): >*********** >Algorithm >--------- >If the following query is submitted to the RIPE database: > > whois [flags] xxx.yyy.zz > >the algorithm will work as follows: > >------- >NAME="xxx.yyy.zz" > >until (NAME = "") { > If object with domain = NAME found, > If object contains referral (see "Referral" below) > forward query (see "Forward" below) > Else > return object > Else > Strip(NAME) (xxx.yyy.zz -> yyy.zz, etc) >} > > >NOTES >----- >1. We move up the tree here, and return the next level answer >if present. If the query requests "tuintje.cwi.nl" (Piet, do you >mind?), they currently get "No entries found ...". In the new >mechanism, they would get: > >domain: cwi.nl >. >. >. >mnt-by: NL-DOMREG >changed: hostmaster(a)domain-registry.nl 19950227 >source: RIPE > >Moreover, if the object for cwi.nl contains a referral, the query >would be passed on to the specified server as explained below. > >2. The algorithm will be set off by any query which causes a search in >the domain object index. This means any query with "-T domain", or >any general query (no -T flag) with something that "looks like a >domain". >************* > >Currently and due to s small desynchronization within the RIPE NCC DB group >and the fact that the proposal was not clear about a particular point the >referred query is for the truncated object in the RIPE DB containing the refer >attribute. We want to modify this so that the query to the authoritative >server is for the user's initial query and not the result of the truncating >algorithm. This change will take place either today or tomorrow and a note >will be sent to the db-wg. > >As a side note I would like to stress that the RIPE Database is NOT the source >of authoritative data for domain objects (although we are happy to provide a >repository for TLD administrators). >This is UNLIKE the internic whose business is to sell names. > >The RIPE NCC is therefore acting according to users directives that were >discussed and agreed on an open way. > >We are happy to hear any comments about this or any other issues regarding the >DB software and will keep working to suggest and provide users with >functionality that will help them the most. > >Please send any comments to the RIPE mailing lists. > >Best regards, >Joao Damas >RIPE DB Group manager >RIPE NCC > > > NCC local-ir list Moderator <lir-mod(a)ripe.net> writes: > * > * I feel this is more appropriate to be discussed on the db-wg. > * > * Mirjam Kuehne > * RIPE NCC > * > * ------- Forwarded Message > * > * Date: Thu, 26 Nov 1998 19:21:13 +0200 > * To: <local-ir(a)ripe.net> > * From: Hank Nussbacher <hank(a)ibm.net.il> > * Subject: Ripe change to whois > * > * I may have missed it, but a serious *bad* change has occured to the whois > * interface. Previously, if I did a check on abcdef.co.il and abcdef did not > * exist, whois would return an error message. Now, whois returns the domain > * and role records for the next upper level domain - i.e. co.il or .il. Other > * examples: zzzz.ac.uk, zzzz.ac.at. > * > * How did I find out about this? I received 3 phone calls already in the past > * 24 hours from users in Israel stating that I personally am registered as > * owner of hundreds of domains. They state that being on the board of the > * ISOC-IL which oversees the registration, I have violated the rules (limit of > * 10 domains per person - other countries have similar restrictions). I have > * tried explaining to them that I am not the owner of these domains. If it > * was 1 user, I would assume they didn't read the entry correctly. But the > * fact that 3 totally different people have called me to ask whether I would > * sell certain domain names to them, I can only conclude that the RIPE change > * is not that successful. > * People have been used to getting an error message from RIPE, similar to the > * "No match" one gets from Internic. When they now get a valid response, they > * don't bother to check that the response is not for the domain they > * requested. There is no error message or error code. > * > * This needs to be rectified (and changes discussed in the future - ignore if > * it has been mentioned). > * > * - -Hank Nussbacher > * ISOC-IL board member > * > * > * > * > * ------- End of Forwarded Message > * > * > * > > >

4 7

Re: Ripe change to whois
by Hank Nussbacher 30 Nov '98

30 Nov '98

At 02:17 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: Phone call #4 today. User goes to http://www.checkdomain.com to determine if ubuy.co.il is valid. www.checkdomain.com says the domain is owned by me (Internet Society of Israel). Now try it for xxxyyy.co.at or xxxxyyy.co.ie or any domain for that matter located at whois.ripe.net. This is just one Internet site that has based its site and code on how RIPE works. There very well may be others. -Hank >Dear Hank, > >May be (or may be not) the "human engineering aspects" were discussed enough >but, please, >if things like this affect your work so much, get into the db-wg mailing list >and give your input. > >The TLD wg was also involved in this and they were actually very much looking >forward to have this mechanism in place. > >If you still feel that "This needs to be rectified" you can discuss this with >the community, although it would have been better to discuss all this when the >design was proposed instead of going around the loop again (which, of course, >we'll do if users want to). > >I'll wait and listen. > >Regards, >Joao > > Hank Nussbacher <hank(a)ibm.net.il> writes: > * At 01:01 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: > * > * Yes, that may be all correct - from a techno standpoint. What I am > * stressing is the human engineering aspect. Up till now, thousands of hits > * are sent to the whois.ripe.net every month to determine whether a domain > * exists or not. Users have been doing this for years. Suddenly, the output > * is different and they do not realize it. I highly doubt that the human > * engineering aspect was discussed or analyzed to any extent in the DB WG. -H > * ank > * > >

1 0

Ripe change to whois
by NCC local-ir list Moderator 30 Nov '98

30 Nov '98

I feel this is more appropriate to be discussed on the db-wg. Mirjam Kuehne RIPE NCC ------- Forwarded Message Date: 26 Nov 1998 17:21:38 -0000 Received: (qmail 23377 invoked by uid 0); 26 Nov 1998 17:21:35 -0000 Received: from ncc.ripe.net (193.0.1.99) by postman.ripe.net with SMTP; 26 Nov 1998 17:21:35 -0000 Received: from postman.ripe.net by ncc.ripe.net with SMTP id AA27381 (5.65a/RIPE-NCC); Thu, 26 Nov 1998 18:21:34 +0100 Received: (qmail 23374 invoked by uid 0); 26 Nov 1998 17:21:30 -0000 Received: from biff.ibm.net.il (192.115.72.164) by postman.ripe.net with SMTP; 26 Nov 1998 17:21:30 -0000 Received: from docking.interall.co.il (dial1.tlv.ibm.net.il [192.116.177.129]) by biff.ibm.net.il (8.8.8/8.8.2) with SMTP id TAA31544 for <local-ir(a)ripe.net>; Thu, 26 Nov 1998 19:21:26 +0200 Message-Id: <2.2.32.19981126172113.006820b4(a)max.ibm.net.il> X-Sender: hank(a)max.ibm.net.il X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Nov 1998 19:21:13 +0200 To: <local-ir(a)ripe.net> From: Hank Nussbacher <hank(a)ibm.net.il> Subject: Ripe change to whois I may have missed it, but a serious *bad* change has occured to the whois interface. Previously, if I did a check on abcdef.co.il and abcdef did not exist, whois would return an error message. Now, whois returns the domain and role records for the next upper level domain - i.e. co.il or .il. Other examples: zzzz.ac.uk, zzzz.ac.at. How did I find out about this? I received 3 phone calls already in the past 24 hours from users in Israel stating that I personally am registered as owner of hundreds of domains. They state that being on the board of the ISOC-IL which oversees the registration, I have violated the rules (limit of 10 domains per person - other countries have similar restrictions). I have tried explaining to them that I am not the owner of these domains. If it was 1 user, I would assume they didn't read the entry correctly. But the fact that 3 totally different people have called me to ask whether I would sell certain domain names to them, I can only conclude that the RIPE change is not that successful. People have been used to getting an error message from RIPE, similar to the "No match" one gets from Internic. When they now get a valid response, they don't bother to check that the response is not for the domain they requested. There is no error message or error code. This needs to be rectified (and changes discussed in the future - ignore if it has been mentioned). - -Hank Nussbacher ISOC-IL board member ------- End of Forwarded Message

3 3

Re: Ripe change to whois
by Hank Nussbacher 30 Nov '98

30 Nov '98

At 02:17 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: I admit that I have not taken part in the DB WG, since I trust the work done there, and all changes that have been done over the past years have been fine and in their place. This change too, from a technical aspect - is good. I would not have spotted the "human engineering" aspects either even if I was on the list and contributing. Sometimes, one can admit their mistakes and say we need to reevaluate the results. I have received another 3 calls today (we only register 500 domains per month on average in .il) from users wanting to buy .il domains from me. No one else is seeing this problem??? -Hank >Dear Hank, > >May be (or may be not) the "human engineering aspects" were discussed enough >but, please, >if things like this affect your work so much, get into the db-wg mailing list >and give your input. > >The TLD wg was also involved in this and they were actually very much looking >forward to have this mechanism in place. > >If you still feel that "This needs to be rectified" you can discuss this with >the community, although it would have been better to discuss all this when the >design was proposed instead of going around the loop again (which, of course, >we'll do if users want to). > >I'll wait and listen. > >Regards, >Joao > > Hank Nussbacher <hank(a)ibm.net.il> writes: > * At 01:01 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: > * > * Yes, that may be all correct - from a techno standpoint. What I am > * stressing is the human engineering aspect. Up till now, thousands of hits > * are sent to the whois.ripe.net every month to determine whether a domain > * exists or not. Users have been doing this for years. Suddenly, the output > * is different and they do not realize it. I highly doubt that the human > * engineering aspect was discussed or analyzed to any extent in the DB WG. -H > * ank > * > >

1 0

Performance of auto-dbm, Thu, 27 Nov 1998
by RIPE Database Administration 26 Nov '98

26 Nov '98

Dear Colleagues, We had some performance problems this morning and we had to temporarily stop updates in order to restore performance to its usual level. Updates were restarted as soon as we had finished working on this problem and the queue of updates was quickly processed. We appreciate your patience and we assure you that your updates were not lost. During this time, they were stored; there is no need to send them again. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee _______________________ RIPE NCC Database Group

1 0

Re: New RIPE database software release
by RIPE Database Administration 26 Nov '98

26 Nov '98

Hi, Basil V. Dolmatov, "Basil V. Dolmatov" <dol(a)east.ru> writes: [..... part of original message deleted .....] * * Request for person creation not answered for at least two hours... * [..... remainder of original message deleted .....] We are having some problems this morning and are working hard to fix them. We appreciate your patience and we shall keep you informed. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee _______________________ RIPE NCC Database Group

1 0

RIPE Database incident of 27th October
by Joao Luis Silva Damas 16 Nov '98

16 Nov '98

Dear all, the RIPE NCC Database group has been reviewing the events regarding the RIPE Database incident of 27 October. We have produced a report that can be found at http://www.ripe.net/db/incident.html All data sent to the database, related to this incident, is accessible through this URL. If you have any questions regarding this incident or otherwise related to the RIPE Database we will be glad to answer them. Best regards, Joao Damas RIPE DB Group RIPE NCC

1 0

Re: From Address Forged
by Michael van Elst 11 Nov '98

11 Nov '98

On Thu, Nov 05, 1998 at 06:01:23PM +0100, Siegfried Langenbach wrote: > On 5 Nov 98, at 17:45, Daniel Karrenberg wrote: > > > > > Wilhelm and other colleagues, > > > > it appears that the header forging did only occur in an effort to > > correct mistakes made earlier. Repeat: the updates that caused the > > problems originally were not done using forged headers. This does not > > mean header forging was not very bad judgement, but at least it occurred > > only in an effort to correct earlier mistakes. The RIPE NCC will work > > with Transpac on a post-mortem analysis. More news as it develops. > > Hmm, > if it was needed to forge a header to correct a mistake, > how then the mistake could be done without forging the header? > > siegfried I get tired discussing this. Yes, the original 'mistake' didn't involve forged headers. Yes, old records have been deleted this way. No, these records were not protected by their maintainers (auth: NONE). Yes, the handles were reallocated to other records. Yes, some of these new records were protected by their maintainers. Yes, these new records were deleted using forged mail headers. No, the old records were not restored because the restoring update was sent too early (usually in the same mail which inherently fails). Yes, the yet-again free handles have been reallocated to even more new records again. Yes, deleting the new records caused more inconsistencies and more data loss. No, deleting the new records didn't correct the original 'mistake' at all. Yes, deleting the new records produced more errors outside the RIPE-DB realm (for example, registrations of domains that reference the new-but-then-deleted person records in the RIPE-DB failed). Yes, deleting the new records sabotaged other people's attempt to recover from original 'mistake'. We have thus switched from MAIL-FROM to CRYPT-PW authorization. If I see any unauthorized update in the future, the responsible person gets shot. -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster(a)xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]

2 2

RE: From Address Forged
by Winfried Haug 05 Nov '98

05 Nov '98

First of all, please dont quote complete mails for just 2 lines from you.. > Hmm, > if it was needed to forge a header to correct a mistake, > how then the mistake could be done without forging the header? > if you have attended at this topic you should have noticed that most handles had no protection (just a notify) but were not mounted. So there was no problem to delete these records... Thats it.. Winfried

1 0

Re: From Address Forged
by Daniel Karrenberg 05 Nov '98

05 Nov '98

Wilhelm and other colleagues, it appears that the header forging did only occur in an effort to correct mistakes made earlier. Repeat: the updates that caused the problems originally were not done using forged headers. This does not mean header forging was not very bad judgement, but at least it occurred only in an effort to correct earlier mistakes. The RIPE NCC will work with Transpac on a post-mortem analysis. More news as it develops. Daniel

1 0