- db-wg - mailman.ripe.net

Re: Ripe change to whois
by Frank Faubert 02 Dec '98

02 Dec '98

Hi All, Please forgive the intrusion, I am new to this discussion. Hank>Phone call #4 today. User goes to http://www.checkdomain.com to determine Hank>if ubuy.co.il is valid. www.checkdomain.com says the domain is owned by me Hank>(Internet Society of Israel). Now try it for xxxyyy.co.at or xxxxyyy.co.ie Hank>or any domain for that matter located at whois.ripe.net. This is just one Hank>Internet site that has based its site and code on how RIPE works. There Hank>very well may be others. I am the maintainer of checkdomain.com, and to be honest, I was completely ignorant of these changes to the RIPE DB until Mr. Nussbacher sent an e-mail to me. Hank>Just check http://www.checkdomain.com with some nonexistant domain housed at Hank>RIPE and tell me if something isn't wrong here. -Hank I have since updated checkdomain.com to check the "domain:" field returned from the DB and return the equivalent of a "no match" if it is not the same as the user specified. The new behavior is way too confusing to our users, who are checking to see if a domain name is still available. Joao>If people don't want to be subscribed to these lists but the work going on Joao>there is relevant to them may be it would be a good idea to, at least, make it Joao>a monthly task to overview the archives and look at the presentations given Joao>during RIPE meetings. Otherwise, how can we make sure that we reach all Joao>interested parties without spamming the rest? Have you considered an announcement list? I for one do not have time to constantly monitor the discussions on the DB list, as checkdomain.com is not a source of income for my company, but a completely free service we provide to the internet. However, I would very much like to receive announcements from RIPE to my direct e-mail address at frank(a)sane.com. If you choose to implement this, please add me to the announcement list. Joao>I would like to have the input of the community. While I am sure that the change was needed for some users, I'm sure that you can agree that it is also causing problems for other users. I think that it would be a very good thing if you could offer a method of getting the old behavior from whois queries, as well as a method of getting the new behavior. Now, I don't want to get involved in the debate over which way should be the default, but I think that both methods should be offered. Please let me know what I need to do in order to use the old behavior, so I can remove my quick hack from checkdomain.com and replace it with a supported method. BTW: I also want to thank RIPE for the DB service they provide! Sincerely, Frank Faubert checkdomain.com

1 0

NIC handle writeup
by David Kessens 02 Dec '98

02 Dec '98

Hi, We discussed in depth the issue of NIC handles during the db-wg session of the Stockholm RIPE meeting. I promised to write a draft with a proposal. It's enclosed below for your review, David K. --- Internet Engineering Task Force David Kessens Draft ISI Expires March 1999 <draft-kessens-registryobject-identifiers.txt> Registry Object Identifiers Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract NIC handles have existed for a long time while they were never properly defined. At the same time, many registries started with their own interpretation of a definition that didn't exist. This document attempts to describe a definition that mostly backwards compatible with the definitions that most registries currently use. Introduction For a long time, a need existed for a unique identifier to identify personal data in the regional registries. The NIC handle has been invented to address this issue. However, the concept of NIC handles has never been documented in any place and as a result, several registries use different definitions. This draft is an attempt to write up a definition that is compatible with the current definitions that most registries use and that allows other, possibly new registries, to design their own identifiers that Kessens [Page 1] Draft RIDE References August 1997 are guaranteed to be unique. In addition, this document generalizes the concept to allow registries to use these unique identifiers for other classes (like host objects) then the personal data classes. Concepts The identifier consists of two parts: - internal registry identifier The identifier is unique within the registry, but doesn't need to be unique on a global scale. This gives the registry maximum freedom to design their own identifiers for local use. In the past, one of the most difficult problems was the entropy in the the NIC handle name space. - global registry identifier This identifier makes the internal registry identifier unique on a global scale. A registry can be queried using the internal identifier or with a combination of internal and global identifier. The registry will add it's own identifier when the internal identifier is omitted. Definition InternalIdentifier[@GlobalIdentifier] The global identifier is the same as a domain which is in use by the registry. The internal identifier is an RPSL word [1]. Identifiers are not case sensitive. Discussion No central authority was ever present to allocate global identifiers. This caused name collisions. However, it's undesirable to have such an authority. Therefore, it is needed to get an identifier from some other already defined namespace. The domain name system provides us such an identifier with minimal cost. A convention for internal identifiers for use in conjunction with Kessens [Page 2] Draft RIDE References August 1997 personal data exists: InitialsOfPerson# It is recommended but not required to follow this convention. The '@' sign is choosen since it cannot be part of the internal identifier. In the past '-' was used which is causing ambiguities. It is not required that every registry is actually using the convention. A registry can mirror another registries data that doesn't participate in the scheme and assign a global identifier using a domain that is used by the other registry. Example example: KH1(a)ARIN.NET KH1 is local identifier ARIN.NET is global registry identifier (last part of domain name can possibly be omitted) Security considerations The model describes a dataformat which doesn't have security problems in itself. It doesn't make the system more or less secure. Acknowledgments The ideas presented in this document are a composition of ideas and thoughts of the author and many other people that have developed over the years. In particular, the people that were present at the RIPE database working group, IETF ride BOFs and their respective mail lists have had quite some influence on the final outcome of this draft. References [1] Cengiz Alaettinoglu e.a., RPSL, rfc2280.txt Author's Address: David Kessens, ISI Kessens [Page 3] Draft RIDE References August 1997 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 USA davidk(a)ISI.EDU Kessens [Page 4]

4 6

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

Réf. : From Address Forged
by GALL Thierry TPC-SRD 04 Nov '98

04 Nov '98

Actually, the address was "forged" but only partially by Trevor, and Hostmaster was in copy of the mail, More over it was an attempt to repair the original error and to avoid the work necessary to rebuild all the links that have destroyed. Please apologize again for all these perturbations. Thierry GALL

1 0

Re: Events of Tuesday, 27 October 1998.
by Havard.Eidnes＠runit.sintef.no 03 Nov '98

03 Nov '98

Dimitrios Kaloger wrote: > Dear Madam,/Sir > > Mistakes are not improbable, however I can not condone your > inadequate backup procedures. Its totally out of imagination that > you may have rouinned the RIPE database. You have to keep yourself > more dedicated to your work. This cannot stand as is. It is important to understand that the data in the RIPE database is maintained by the users of the database, and not by the RIPE NCC itself. As was already said by the RIPE database administrator: > We would like to stress that the RIPE NCC operates the RIPE Database, > however the responsibility for managing user data lies with the users. I suspect that the problem is that a backup cannot easily be used to restore the current "desired" state (minus the unfortunate update). The reason is that old NIC handles may have been recycled, i.e. reassigned to another object, and that object can subsequently have been referenced by an explicit use of that recycled NIC handle in an update. Sure, the subsequent updates could perhaps be doctored to remedy this, but that is perhaps not easily or quickly done, and would also mean "intervention in the data maintenance" by the RIPE NCC. I would thus tend to turn the argument above on its head and say that we collectively, the maintainers of the data in the RIPE database, have made inadequate use of the already available methods for protecting the data we maintain there from unauthorized updates or removals. Regards, - Håvard

4 4

Events of Tuesday, 27 October 1998.
by RIPE Database Administration 02 Nov '98

02 Nov '98

Dear Colleagues, On Tuesday, 27 October 1998, a user of the RIPE Network Management Database accidentally deleted many [person] objects. The objects affected were either not maintained by a 'mntner' object or were maintained by a 'mntner' object with an authentication mechanism of NONE. The RIPE NCC has investigated this and learned that it was a genuine mistake by this user. When a person object is deleted, its nic-handle is available for re-use immediately. Therefore, you may find that a nic-handle now points to a different person or role object. We recommend that you check the consistency of your data i.e. see if the nic-handles in the admin-c, tech-c, and zone-c lines of your objects refer to the correct person or role objects. We understand that an attempt was made to re-create the deleted objects by the individual who originally deleted them. Please search for your person objects using both the name and the nic-handle. It is possible that your object has been re-created, but with a different nic-handle. If so, you must update your inetnum, route, mntner, etc. objects that refer to the previous nic-handles in the admin-c, tech-c, and zone-c lines. You should replace the old nic-handles with the new ones. To check whether a certain nic-handle is referenced anywhere, you can use the inverse look-up flag. For example, you can do: "whois -i admin-c,tech-c,zone-c <nic-handle>" to see if that nic-handle is referenced anywhere as admin-c, tech-c, or zone-c (e.g. as in domain objects). If one or more of your person and/or role objects have not been re-created, we suggest that you first try to re-create them using the original nic-handle. This way, you do not have to change any of the references that use this nic-handle. If the nic-handle has been re-used, you should try to create the person or role object with the AUTO-1 keyword. In this case, however, you will have to change the inetnum, domain, or other objects that reference this nic-handle to point to the new one. (Use the the "-i" flag mentioned above to find which objects reference the old nic-handle). The RIPE NCC shall, as a part of its service to the RIPE community, support users to restore their data to a consistent state. We estimate that this should take about one working day. Please note that it is the users responsibility to restore their own data. We would like to stress that the RIPE NCC operates the RIPE Database, however the responsibility for managing user data lies with the users. Mechanisms to protect data against unauthorised or unintentional modification exist for several years now. The RIPE NCC has always emphasized the importance of authentication mechanisms and has been recently working to introduce even stronger procedures. We encourage users to deploy these authentication mechanisms. Please read ripe-157, section 2.3 on how this works. If you have any problems with the RIPE Database, please send an email to <ripe-dbm(a)ripe.net>. Regards, The RIPE NCC Database Group.

3 2

RE: Database performance - an update.
by Mike Norris 30 Oct '98

30 Oct '98

> I shall begin by saying that I wrote the two messages to > the local-ir, lir-wg and db-wg yesterday. I wrote them > for, and on behalf of, the RIPE NCC Database Group. I > realise that many of you are unhappy that these messages > had no personal signature. The responsibility for this > oversight is mine. In all previous postings to these lists, > I have signed my name. I shall continue to do this. Ambrose, you may not have put your name at the end of the mail, but we knew it was you anyway - your style is inimitable and your sense of humour unique. Keep up the good work and watch out for ghosts this weekend. Cheers. Mike Norris

1 0

Database performance - an update.
by RIPE Database Administration 30 Oct '98

30 Oct '98

Dear Colleagues, I shall begin by saying that I wrote the two messages to the local-ir, lir-wg and db-wg yesterday. I wrote them for, and on behalf of, the RIPE NCC Database Group. I realise that many of you are unhappy that these messages had no personal signature. The responsibility for this oversight is mine. In all previous postings to these lists, I have signed my name. I shall continue to do this. You already know what happened on Tuesday, 27 October, last. Yesterday morning, we had no option but to do preventative maintenance of the database; this was not related to the activity of any user last Tuesday. However, nearly all updates were stopped until around 1630 MET. Unfortunately, there was a higher than usual number of updates sent to the database yesterday. These two facts had one result: a very long delay before your updates were processed. At this time there is still a long queue of unprocessed updates, but updates are being processed again. Obviously, a faster, more powerful machine would process updates quicker than the current machine. On Tuesday, the problem was that it was possible to delete objects referenced somewhere in the database before deleting all references to that object. Imposing such a constraint (referential integrity check) has been already been considered. Tuesday's incident was not a security problem - anyone with the correct authorization can still make a mistake. At the previous RIPE meeting in Edinburgh, we announced new software, including a referential integrity check, and new hardware, a Sun E450 machine. We intended to deploy both of these at the end of October or early November. We had bad luck that several unrelated problems occurred this week, just before the planned deployment of the new code and the new machine. Now, a status report. All your updates have been queued - there is no need to re-send them. We estimate that the situation should be back to normal tomorrow, if not sooner. We still plan to introduce the new software and hardware next week. We thank you all for your support in the past and we assure you of our continuing efforts to support you in your work. Your sincerely, Ambrose Magee -------------------------------------------------- for, and on behalf of, the RIPE NCC Database Group.

1 0

Objects affected by events of 27/10/1998.
by RIPE Database Administration 30 Oct '98

30 Oct '98

Dear Colleagues, We keep detailed logfiles of all updates to the RIPE Database. We processed these files to produce lists of all objects affected by the incidents earlier this week. We have decided to make these files public, to support you when ensuring that your data is consistent. These files contain only the name and nic-handle of affected person objects. These files may be obtained by anonymous ftp from: ftp://ftp.ripe.net/ripe/dbase/981027-incident.Delete ftp://ftp.ripe.net/ripe/dbase/981027-incident.New ftp://ftp.ripe.net/ripe/dbase/981027-incident.Update There are also gzip'ed versions available, using the same filenames, with the .gz extension. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ----------------------- RIPE NCC Database Group

1 0

Big delays with <auto-dbm>.
by RIPE Database Administration 29 Oct '98

29 Oct '98

Dear Colleagues, Last night, there was a higher than usual number of messages to <auto-dbm(a)ripe.net>. Thus, there were some delays in processing these messages. This morning, we carried out some unrelated preventative maintenance and this has led to more delays. Your messages are being stored and will be processed as soon as possible. BTW, this maintenance was not linked to the recent actions of any user of the RIPE Database :-) If you have any questions, please contact <ripe-dbm>. It is either Murphy's Law, or Hallowe'en, or the Great Pumpkin, or whatever, that this happened this week. We thank you for your patience. Regards, --------------------------- The RIPE NCC Database Group.

1 0

RE: Default behaviour for referred domain queries
by Mike Norris 06 Oct '98

06 Oct '98

In coincidence with your input, the db-wg also found that whenever the server shows data from a remote server instead of the local data in response to a query, the response should be preceded by a notice clearly informing the user that the information being displayed is coming from another server that contains the authoritative data. Right. It was also noted that the original proposal did not provide a way to look at the "local" object if it contained a refer attribute. In order to avoid potential confusion from a mode of operation where two objects are displayed, it would be better to provide a whois flag (-R was agreed) that would disable the referral and show the local object. Bear in mind that there could be multiple referrals involved i.e. the process is recursive. Suppose the query is for a third-level domain, that the second-level domain is referred from the RIPE DB to a TLD registry server, and that the target domain is referred onward from the TLD server to an ISP's whois server. Now what will the -R flag deliver - the local object in the RIPE DB? That'll give you the coordinates of the TLD server, which you again query with -R to get the ISP 'local' object. Regards. Mike

1 0

Default behaviour for referred domain queries
by Niall O'Reilly 05 Oct '98

05 Oct '98

I'ld like to give input as requested on this topic. For the TLD people who may have missed the DB session, here is first a brief description of how the referral feature works. I don't know the details at this stage. When a request is received by the "central" server for a domain object marked (locally) for referral, the query is referred to the authoritative server and the data from the authoritative server is returned to the client. If the domain object requested is not found on the "central" server, the specified domain name is truncated (successively, if necessary ?) until a higher-level domain is found to be marked for referral, and the query is then referred to the authoritative server for that (higher-level) domain. The following suggestions seem to be almost agreed, but need to be written down. By default, the response returned to the client for a referred query should include the following elements: Alert that referral has been used Response from authoritative server I expect that the authoritative response will include a copyright and/or AUP banner from the authoritative server, but this is the responsibility of the authoritative registry, and not of the registry providing the referring server. I expect that a 'verbose mode' will provide a response including the following elements: Response from referring server as if no referral was used, including referring registry's standard (C)/AUP banner Alert that referral is spin effect for the domain in question Response from authoritative server Whichever of the modes described above is used, it should be possible to specify whether recursive lookup and display of related person/role (and in future, nameserver) objects is to be done. IHTH, Niall

2 2

Re: NIC handle writeup
by Wilfried Woeber, UniVie/ACOnet 02 Oct '98

02 Oct '98

[ Apologies for prematurely pressing send. It's Friday afternoon :-( ] => "%" still has mail-related connotations though, although far less so than => "@". => => How about ":"? JA39:APNIC.NET doesn't look like an e-mail address or a DNS => name. It does however look slightly remotely like a URL ;) = = ":" not only has URL significance, its also used w/ IPv6 in the = address. IMHO a poor choice. I don't think that we're going to find any character which isn't badly overloaded already... => Or have I misunderstood the point you were making? = = I think so. Back up a bit and take the 10,000m view. Yup: why do we need a special character at all? Grab a handle, which simply must not contain the "." character, and extend that with the DNS-part as proposed. Done. And it is known to work (DNS SOA record) My good old WW144 would then simply become WW144.INTERNIC.NET. = There are three classes of Internet intangibles that = can be delegated, ASN's, Prefixes, Port numbers. (there = are others, but these will do for this purpose) = = The recipiants of these delegations can be people (admin-c/tech-c), = hosts (HST), organized groups (mntner & role accounts) While this is probably off-topic, I suppose you are mixing organisations and contact information here... = I could make the case that the mntner:, admin-c:, tech-c:, = mnt-by:, nic-hdl:, and the HST (C8-HST) are all, in a very = real sense, NIC HANDLEs. They specify a relationship between = Internet resources and those who are authorized to manage the = delegation relationship. I have to disagree. - We do have mechanisms to describe the privilege(s) for maintaining objects. - And we do have mechanism to get in touch with persons (or helpdesks or NOCs) for operational purposes. = Here, I expect that the handle: = = WM110 = WM110-NSI = WM110-ARIN = = all reflect me, first under the SRI-NIC, then Internic/NSI, then = ARIN. I would hope the design of NIC-handles would allow migration = of data between registries as well as allow for a deeply nested = registration heirarchy. What we've learned from past (failed) attempts: - don't try to mix the issue generating globally unique identifiers with - the issue of data exchange between registries As soon as we've sorted out the first one, we can try to work on the second one. Having the first one done is not going to interfere with solving the other issue, I suppose :-) Wilfried. -------------------------------------------------------------------------- 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

Re: NIC handle writeup
by Wilfried Woeber, UniVie/ACOnet 02 Oct '98

02 Oct '98

From: MX%"bmanning(a)ISI.EDU" 25-SEP-1998 20:56:00.16 To: MX%"jabley(a)clear.co.nz" CC: MX%"db-wg(a)ripe.net" Subj: Re: NIC handle writeup From: bmanning(a)ISI.EDU Subject: Re: NIC handle writeup To: jabley(a)clear.co.nz (Joe Abley) Date: Fri, 25 Sep 1998 11:50:08 -0700 (PDT) CC: db-wg(a)ripe.net > "%" still has mail-related connotations though, although far less so than > "@". > > How about ":"? JA39:APNIC.NET doesn't look like an e-mail address or a DNS > name. It does however look slightly remotely like a URL ;) ":" not only has URL significance, its also used w/ IPv6 in the address. IMHO a poor choice. > > > The only thing that > > > really matters is if we can find the data and that it improves the > > > current situation. > > > > Thats two things. While desirable, the thing that I thought > > NIC handles did was to identify an entity that was responsible > > for some delegated level of responsibility. > > > > This could be a host, person, role, or organization that > > accepted the responsibility over some delegated Internet > > resources (numbers & lables). > > In ripe-181 the habit seems to have been to put contact fields (tech-c, > admin-c) in every record where contact was appropriate, so contact details > via NIC handles are immediately available. In other words, the drill down > path of (for example) inetnum -> netname -> admin-c/tech-c isn't necessary > since there are direct relationships inetnum -> admin-c and inetnum -> tech-c. > > Has this changed significantly in RPSL, so that it is now important to have > netname-type fields which have registry-internal and registry-external > representation? > > Or have I misunderstood the point you were making? I think so. Back up a bit and take the 10,000m view. There are three classes of Internet intangibles that can be delegated, ASN's, Prefixes, Port numbers. (there are others, but these will do for this purpose) The recipiants of these delegations can be people (admin-c/tech-c), hosts (HST), organized groups (mntner & role accounts) I could make the case that the mntner:, admin-c:, tech-c:, mnt-by:, nic-hdl:, and the HST (C8-HST) are all, in a very real sense, NIC HANDLEs. They specify a relationship between Internet resources and those who are authorized to manage the delegation relationship. > > So each of these things would > > have an unambigious lable that could be tied to an assignment > > of responsibility. Those lables should be consistant, regardless > > of where they are listed. They should also have some token that > > indicates the listing origin and may include a method for > > determining the level of trust on the listing. Here, I expect that the handle: WM110 WM110-NSI WM110-ARIN all reflect me, first under the SRI-NIC, then Internic/NSI, then ARIN. I would hope the design of NIC-handles would allow migration of data between registries as well as allow for a deeply nested registration heirarchy. --bill -------------------------------------------------------------------------------- Return-Path: <owner-db-wg(a)ripe.net> Received: from ns2.univie.ac.at by access.cc.univie.ac.at (MX V4.1 VAX) with SMTP; Fri, 25 Sep 1998 20:55:55 MET-DST Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by ns2.univie.ac.at (8.8.8/8.8.8) with SMTP id UAA56164 for <woeber(a)cc.univie.ac.at>; Fri, 25 Sep 1998 20:55:54 +0200 Received: (qmail 918 invoked by alias); 25 Sep 1998 18:55:23 -0000 Delivered-To: lists-db-wg-out(a)lists.ripe.net Received: (qmail 916 invoked by uid 66); 25 Sep 1998 18:55:23 -0000 Posted-Date: Fri, 25 Sep 1998 11:50:08 -0700 (PDT) Message-ID: <199809251850.AA08047(a)zed.isi.edu> In-Reply-To: <19980925102909.B15327(a)clear.co.nz> from "Joe Abley" at Sep 25, 98 10:29:09 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-db-wg(a)ripe.net Precedence: bulk

1 0

Re: NIC handle writeup
by Havard.Eidnes＠runit.sintef.no 25 Sep '98

25 Sep '98

> I think that there will be problems with "@" as the > seperator. It's too much like a viable email address. I > applaude the use of the domain name on the right and a > domain specific unique handle on the left, the concern is > the seperator. Howabout something like "%"? I fully agree. Another option could be ":". Then there is the already established practice of using "-" (as in RIPE's case), I don't see what's so terribly wrong with that. Making NIC handles into something which could be mistaken for an e-mail address just leads to confusion. (No, I don't think it's such a great idea to provide automatic mail forwarding service by the registry.) I also don't think it's such a great idea to use domain names to identify the origin of the data; I think a separate name space should be used instead, e.g. one which could provide more permancence. (As Bill mentioned, what do you do when a registry closes down and its corresponding domain name is subsequently removed?) - Håvard

3 2

Slides from RPS Authorization and Replication Talks
by Cengiz Alaettinoglu 24 Sep '98

24 Sep '98

Hi, As some of you already requested, my slides, both on authorization and IRR distribution, are available at: http://www.isi.edu/~cengiz/talks/ RPSL tutorial slides are available at: http://www.isi.edu/ra/rps/training/ Regards. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute http://www.isi.edu/~cengiz University of Southern California

1 0