- db-wg - mailman.ripe.net

draft agenda (v4), for DB-WG meeting, RIPE 37, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 12 Sep '00

12 Sep '00

Dear WG list members, fellow chair persons, "meeting"! Attached please find the 4th draft, proposed agenda for the DB-WG Meeting. This draft is the result of our attempts to resolve the WG schedule collisions. The proposal is to rearrange items, to run an extended 1st part (in _parallel_ with Routing), an then to continue with a _joint_ Routing and DB-WG session (after a probably belated coffee-break) to deal with items closely related to both camps. My apologies for this mess, but I guess this is the best thing that we could do - given the constraints that were imposed on us. Still, comments, suggestions and additions are welcome. Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-37, Sept. 2000, Amsterdam, NL 4. Draft Thursday, Sept 14, 2000 starting at 09:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part I: DB-WG Meeting PI-A. Administrative stuff (WW, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed PI-B. Actions Items . PI.C. RIPE DB, operations update (RIPE NCC) 20min PI.D. IRRd: experiences, registration software weaknesses (G.Winters, MERIT) 20min PI.E. Activity Plan proposal(s) for next year (N.N.) . summary . next steps (requirements?) PI.F. Recommendation on the use of auth. methods in the DB (WW) 10min . mechanisms documented on NCC web pages . recommendation from the community . operational impact PI.G. Globally unique handles for person:/role: ? (R. Bush) 10min? . is there a need for globally unique handles? . what could they look like? . how to obtain and use such a handle, and for what? PI.H. IRT-Pointer for DB Objetcs (WW) 10min . consensus to go ahead? . which Objetcs? PI.Y. Input from other WGs - CENTR Tech: . protect vulnerable TLD objects? . remove "bogus" TLD objects? . "best before" on person (& role) objects? PI.Z. AOB: Part II: Joint Session with Routing PII.A. New Database implementation (RIPE NCC) PII.B: RE-Implementation/Migration TF . Test Reports/Feedback . Deployment Plan . Next steps ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 12-SEP-2000 19:56:46 _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

draft agenda (v3), for DB-WG meeting, RIPE 37, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 10 Sep '00

10 Sep '00

Dear WG list members, fellow chair persons, "meeting"! Attached please find the 3rd draft, proposed agenda for the DB-WG Meeting. This draft improves on the numbering, and lists an additional item: - Incident Response Team pointer for DB objects As we still have a few scheduling problems to resolve, please expect some re-arrangment of the sequence of items! As usual, comments, suggestions and additions are welcome. Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-37, Sept. 2000, Amsterdam, NL 1. Draft Thursday, Sept 14, 2000 at 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part I: WG-Meeting PI-A. Administrative stuff (WW, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed PI-B. Actions Items . PI.C. RIPE DB, operations update (RIPE NCC) 20min PI.D. New Database implementation (RIPE NCC) 40min PI.E. IRRd: experiences, registration software weaknesses (G.Winters, MERIT) 20min PI.F. Activity Plan proposal(s) for next year (N.N.) . summary . next steps (requirements?) PI.G. Recommendation on the use of auth. methods in the DB (WW) 10min . mechanisms documented on NCC web pages . recommendation from the community . operational impact PI.H. Globally unique handles for person:/role: ? (R. Bush) 10min? . is there a need for globally unique handles? . what could they look like? . how to obtain and use such a handle, and for what? PI.I. IRT-Pointer for DB Objetcs (WW) 10min . consensus to go ahead? . which Objetcs? PI.Y. Input from other WGs - PI.Z. AOB: Part II: Re-Implementation/Migration TF PII.A: Members, ToR PII.B: Test Reports/Feedback PII.C: Deployment Plan PII.D: Next steps ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 10-SEP-2000 17:28:07 _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

draft agenda (v2), for DB-WG meeting, RIPE 37, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 07 Sep '00

07 Sep '00

Dear WG list members, fellow chair persons, "meeting"! Attached please find the 2nd draft, proposed agenda for the DB-WG Meeting. This draft fixes an omission: - Recommendation on the use of "auth:" methods (editorial fault) and lists an additional item: - globally unique handles for "person:" and/or "role:" As we still have a few scheduling problems to resolve, please expect some re-arrangment of the sequence of items! As usual, comments, suggestions and additions are welcome. Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-37, Sept. 2000, Amsterdam, NL 1. Draft Thursday, Sept 14, 2000 at 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part I: WG-Meeting A. Administrative stuff (WW, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed B. Actions Items . B. RIPE DB, operations update (RIPE NCC) 20min C. New Database implementation (RIPE NCC) 40min D. IRRd: experiences, registration software weaknesses (G.Winters, MERIT) 20min E. Activity Plan proposal(s) for next year (N.N.) . summary . next steps (requirements?) F. Recommendation on the use of auth. methods in the DB (WW) 10min . mechanisms documented on NCC web pages . recommendation from the community . operational impact G. Globally unique handles for person:/role: ? (R. Bush) 10min? . is there a need for globally unique handles? . what could they look like? . how to obtain and use such a handle, and for what? Y. Input from other WGs - Z. AOB: Part II: Re-Implementation/Migration TF A: Members, ToR B: Test Reports/Feedback B: Deployment Plan C: Next steps ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 7-SEP-2000 18:55:48 _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

RIPE whoisd re-implementation: RIP-0.5.0beta1 software snapshot
by RIPE Database Administration 06 Sep '00

06 Sep '00

Dear All, This mail is to notify you that today, we have frozen the source code of the new implementation of the RIPE Database software into a new snapshot. The main new feature of the last snapshot is that the PGP signed messages are now handled by the software, i.e. the PGPKEY authentication scheme is supported. Moreover, more inverse queries have been implemented (-i upd-to and -i mnt-nfy), and several bugs have been fixed. You can download this last snapshot at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.5.0beta1.tar.gz We remind you that you can also test the functionality of this snapshot of the RIP whois server in 2 ways: - By querying the host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database. This mirror is in RPSL format. - By using the RIP Test Database. You can send test updates to this database at the address <auto-rip(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the new implementation in both ways, and let us know your opinions. Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. Regards, Daniele Arena ___________________ RIPE Database Group.

1 0

draft agenda (v1) for DB-WG meeting, RIPE 37, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 06 Sep '00

06 Sep '00

Dear WG list members, fellow chair persons, "meeting", attached please find the 1st draft, proposed agenda for the DB-WG Meeting. A few minor items might get added later this week. While the general outline of the meeting should be quite stable already, please expect some re-scheduling due to the parallel WG streams. This requires us to do some "micro-management" to avoid "over-booking" of individuals. As usual, comments, suggestions and additions are welcome! Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-37, Sept. 2000, Amsterdam, NL 1. Draft Thursday, Sept 14, 2000 at 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part I: WG-Meeting A. Administrative stuff (Wilfried Woeber, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed B. Actions Items . B. RIPE DB, operations update (RIPE NCC) 20min C. New Database implementation (RIPE NCC) 40min D. IRRd: experiences, registration software weaknesses (G.Winters, MERIT) 20min E. Activity Plan proposal(s) for next year (N.N.) . summary . next steps (requirements?) Y. Input from other WGs - Z. AOB: Part II: Re-Implementation/Migration TF A: Members, ToR B: Test Reports/Feedback B: Deployment Plan C: Next steps ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 6-SEP-2000 13:44:48 _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First things first, but not necessarily in that order....

1 0

RIPE 36 DB-WG Minutes (final version)
by Nigel Titley 04 Sep '00

04 Sep '00

Gentlefolk, After receiving comments. Here are the final minutes of the RIPE DB-WG minutes. Share and enjoy. Nigel Minutes for the Database Working Group Meeting RIPE-36, May 2000, Budapest, HU Thursday, May 18, 2000 at 10:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (Wilfried Woeber, chair) . scribe Nigel Titley volunteered to take the minutes . raw scribe notes distributed Wilfried had not had time to process the raw notes from RIPE 35, but these were circulated in lieu of full minutes. . help offered by - Nigel Titley, - Ulf Kieber Wilfried asked the WG if they were happy to accept the help offered by Nigel Titley and Ulf Kieber. Nigel would help with the PR and documentation side of the group, and Ulf will help to co-ordinate the working group. He received approval from WG on this issue. B. RIPE DB, operational update (Andrei Robachevsky, RIPE NCC) Andrei Robachevsky gave an operational update on the state of the RIPE DB. Amongst the many statistics that he presented it was noted the very large number of domain objects, mostly from the .de domain. It was explained that these objects would be shortly devolved to the DE-NIC whois server, and plans were currently being formulated to perform this move with minimum disruption to the RIPE community. C. DB Software Re-Implementation (Joao Damas, RIPE NCC) Joao Damas gave a short presentation on the progress of the DB Software re-implementation project. D. Report on Certification Authority activities (Paul Gampe, APNIC) Paul Gampe gave a very interesting presentation on the use of X509 certificates for authentication when updating the APNIC database. The following points were noted: - Training at the next RIPE meeting might be useful, to provide a view of X509 vis-a-vis PGP. There appears to be a degree of convergence between the two systems. - It was noted that it will be soon possible to sign X509 keys with PGP signatures and vice versa. - The main objection to using X509 is the cost of the commercial licenses. The first phase of the implementation will sort out licenses for users. Much cheaper (free) approaches are on their way. E. Activity Plan for next year! It was noted that input to the RIPE-NCC activity plan was needed before September. Suggestions received from the WG included - Use of X509 signature for authentication (as per APNIC) - Support for other character sets than ASCII. (Joao noted that the new code is 8-bit clean, but that there is problem wit the reproduction of character sets. The best he felt able to do was to track progress by other sources, and to keep the code clean). - Removal of further domain objects from the database. The problem being that existing applications must not be affected. It was suggested that the RIPE-NCC could offer help to other ccTLDs to set up their own whois databases. It was suggested that we ask CENTR to produce a regular report and to try and get domain objects shifted out of the DB. [AP: Wilfried Woeber and Joao Damas] F. Input from other WGs - EIX-WG would like an object in the DB to describe IXs. It was also suggested that a peering contact in the aut-num object could be useful. There was some support for both these proposals and it was suggested that a formal request be made to the WG by email. - Routing WG. No further input had been received from the Routing WG re native multicast. It was felt that this would soon need looking at. The Routing WG needs to add an entry to the RPSL Draft. G. AOB - A suggestion (Joel Rowbottom) was made to use XML for registration templates. Suggestions as to how to do this would be gratefully received. - A suggestion to use a mail-to authentication scheme was received from Michael Battilana (IANA). The idea being that agreement to proceed with a modification would be obtained via a token and confirmation from a know mail mail address. It was agreed that this was not very easy to do as it is stateful and could lead to DOS attacks on the database. - A brief update was given on CERT/IRT-related issues (WW144/Jaques Schuurman). Ut was suggested that a pointer be added to inet-num object to point to the IRT role. Anyone interested in this work to contact the WG.

1 0

Re: ripe-db question
by Christian Storch 04 Sep '00

04 Sep '00

You're right! That number space wasn't registrated at RIPE - you have to look at ARIN: http://www.arin.net/cgi-bin/whois.pl?queryinput=NETBLK-SPRINT-CDF4C7 The AS of omnitel looks like the first upstream provider of Omnitel was SprintLink (USA) and the second is Telianet (Sweden). So the address space 205.244.196.0/24 seems to be registrated by SprintLink at ARIN. Later it becomes an LIR at RIPE and so on... So I think for that you would have to ask all RIR's for your purpose: RIPE, ARIN and APNIC. And you won't get always the right answer for your geographical question I think. Christian ---------- | Von: Andrius Kasparavicius <andrius(a)andrius.org> | An: Christian Storch <storch(a)infra.net> | Cc: 'mediaWays Hostmaster' <hostmaster(a)mediaways.net>; lir-wg(a)ripe.net; db-wg(a)ripe.net | Betreff: RE: ripe-db question | Datum: Samstag, 2. September 2000 14:01 | | On Wed, 30 Aug 2000, Christian Storch wrote: | | > Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. | > - Perhaps that page could solve your question. | | hmm, look at lt.Omnitel: | lt.omnitel (OMNITEL Net) | 19951120 194.176.32/19 ALLOCATED PA | 19971010 195.22.160/19 ALLOCATED PA | 19990913 212.47.96/19 ALLOCATED PA | | querry ripe database for 205.244.196.0/24 or for 205.244.197.0/24 | | route: 205.244.197.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva(a)kaunas.omnitel.net 19970605 | source: RIPE | | route: 205.244.196.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva(a)kaunas.omnitel.net 19970605 | source: RIPE | | | it mean's that in allocation list, is not all ip blocks allocated to | LIR's. Why? | | Andrius

2 1

RE: ripe-db question
by Christian Storch 04 Sep '00

04 Sep '00

Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. - Perhaps that page could solve your question. regards, Christian //========================== // Christian Storch // InfraNet AG // Niederlassung Muenchen // Hansastr. 136 // D-81373 Muenchen // phone: +49 89 743523-55 // fax: +49 89 743523-23 // E-mail: storch(a)infra.NET //========================== -----Original Message----- From: mediaWays Hostmaster [SMTP:hostmaster@mediaways.net] Sent: Wednesday, August 30, 2000 4:24 PM To: lir-wg(a)ripe.net; db-wg(a)ripe.net Subject: ripe-db question Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

2 1

ripe-db question
by mediaWays Hostmaster 04 Sep '00

04 Sep '00

Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

7 8

RE: asused question
by kevin.bates＠bt.com 04 Sep '00

04 Sep '00

Greetings Having a "mnt-by" in an object prevents anyone not in the maintainer group from changing the data for that object (i.e. an inetnum). Having a "mnt-lower" in an object prevents anyone not in the maintainer group from changing the data below that object. So, I believe, without the "mnt-lower" in an inetnum, it is possible for anyone to add additional inetnum objects into the RIPE database, below your inetnum record, and for them to put another maintainer into the addition. You could then end up with false records within your assignment that you would be unable to remove. kevin > -----Original Message----- > From: Jeroen Ruigrok van der Werven [SMTP:jruigrok@via-net-works.nl] > Sent: 03 September 2000 12:23 > To: Abdullah Saad Al-Ashry > Cc: lir-wg(a)ripe.net; db-wg(a)ripe.net > Subject: Re: asused question > > -On [20000902 10:05], Abdullah Saad Al-Ashry (abdullah(a)awalnet.net.sa) > wrote: > >When I use the utility "asused" > ftp://ftp.ripe.net/tools/asused-3.5.tar.gz > >It gives me this warning: > >**************** > >Please check the following WARNINGS: > >212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached > >**************** > > You probably have: > > mnt-by: MNT-BLAH > mnt-lower: MNT-BLAH > > which is ambiguous if memory serves me right. > > Just remove the mnt-lower. > > This is just a guess, since you are paranoia and removed the specifices > of your assignment [for which I really cannot find any justification > actually, the paranoia that is]. > > HTH, > > kind regards, > > -- > Jeroen Ruigrok van der Werven Network- and systemadministrator > <jruigrok(a)via-net-works.nl> VIA Net.Works The Netherlands > BSD: Technical excellence at its best http://www.via-net-works.nl > Come and take a good look deep into these thuggish ruggish eyes. See the > thugstas cry. And I'm askin' the good Lord "Why?" and sigh, He told me we > lived to die...

1 0

asused question
by Abdullah Saad Al-Ashry 04 Sep '00

04 Sep '00

Hi, When I use the utility "asused" ftp://ftp.ripe.net/tools/asused-3.5.tar.gz It gives me this warning: **************** Please check the following WARNINGS: 212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached **************** Could anybody explain this. Regards; ---------------------------------------------------------------------- Abdullah Saad M. Al-Ashry Al Faisaliah Internet Services and Technology Est. (AwalNet) Tel: +966-1-4600111 x 311 Fax: +966-1-4601110

3 2

Is this normal behaviour?
by Marco Davids 01 Sep '00

01 Sep '00

Hello, A routine check on as-macro AS-EURONET on the RIPE-database returned an unexpected result. The same check on the RADB whoisd (whois.raddb.net) however, returned the expected result together with two unexpected ones. Investigation learned us that someone deleted an unprotected as-macro on the RIPE-database. It seems it is fixed now. But what I would like to know is to what extend the several whois databases a synchronised, in other words; how reliable is the information retrieved from it? And... is the as-set object supposed to be unique or not? -- Marco Davids / SARA - Academic Computing Services Amsterdam Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt

3 2

Near Real-Time Mirroring in the RIPE database v3.0
by Andrei Robachevsky 01 Sep '00

01 Sep '00

Dear Colleagues, Please find below the next in the series of documents concerning the new database software (v3.0). Now it is about near real-time mirroring. We will appreciate your comments and suggestions, Best regards, Andrei Robachevsky DB Group Manager RIPE NCC Near Real-Time Mirroring in the RIPE database v3.0 ================================================== 1. Near Real Time Mirroring (NRTM) server listens on a separate port (different from usual whoisd port - 43). 2. The following queries are supported by NRTM server: -q sources List all available sources. The format of the output is: <source>:<NRTM protocol version>:<mirroring>:<first>-<last> Where <source> - is the string that identifies the Database (e.g. RIPE) <NRTM protocol version> identifies the version of mirroring protocol. <mirroring> can take one of the following values: Y/N/X - can mirror/cannot mirror/obscured <first> is the lowest serial number available <last> is the most recent serial number available The following semantics apply: Y:<first>-<last> mirroring allowed, serials from range <first>-<last> available N:<first>-<last> mirroring not allowed for administrative reasons. Ask Database Administration for permission. N:0-<last> mirroring physically not possible (e.g. static snapshot of serial <last>) X:<msg> no mirroring allowed. An explanation is given in <msg>. -g <source>:<NRTM protocol version>:<first>-<last> Where <source> - is the string that identifies the Database (e.g. RIPE) <NRTM protocol version> identifies the version of mirroring protocol (currently 1). <first> is the lowest serial number requested . <last> is the most recent serial number requested or the keyword LAST which tells the server to send all updates upto the most recent serial number available at the time of the query. 3. The following errors may occur when querying NRTM server. %ERROR:1: Syntax error: <input> The format of the query is incorrect. %ERROR:2: Invalid range: Not within <first>-<last> This happens when the requested range or part of it is outside the serial numbers available at the server. <first> is the lowest serial number available <last> is the most recent serial number available. %ERROR:3: You are not authorized to mirror the database For more information one may use -q sources query. %ERROR:4: Unknown source The Database identified by the <source> is not served by the server. Use -q sources for a list of available sources.

1 0

Re: ripe-db question
by Brent_Frere＠ses-astra.com 31 Aug '00

31 Aug '00

We (SES, Societe Europeene des Satellites, operator of Astra satellite system) assign IP addresses to end-customers who are using our Internet access by satellite. The only geographic limit we are sure about them is that they are in the Astra satellite system footprint... Footprint is visible at http://www.ses-astra.com/multimedia/bbi So I think this might slighly change your statistics if you count all them as Luxembourg citizens... Brent Frere, SES (Astra) Chateau de Bezdorf L-6815 Betzdorf Grand-Duchy of Luxembourg General phone: +352-710.725-1 Direct phone: +352-710.725-401 E-mail: bfrere(a)ses-astra.com URL: http://www.ses-astra.com "mediaWays Hostmaster" To: lir-wg(a)ripe.net, db-wg(a)ripe.net <hostmaster@medi cc: aways.net> Subject: ripe-db question Sent by: owner-lir-wg@rip e.net 08/30/00 05:23 PM Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

1 0

RE: ripe-db question
by Stefan.Gasteiger＠Gendorf.de 30 Aug '00

30 Aug '00

You should use MIME content negotiation for this purpose. Have a look at: http://www.apache.org/docs/mod/mod_mime.html#multipleext Stefan Gasteiger SG5599-RIPE I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger(a)gendorf.de > -----Original Message----- > From: mediaWays Hostmaster [mailto:hostmaster@mediaways.net] > Sent: Wednesday, August 30, 2000 4:24 PM > To: lir-wg(a)ripe.net; db-wg(a)ripe.net > Subject: ripe-db question > > > Hi, > > some strange question: > we need a complete list of assigned IP-Addresses > in the european part of ripe region sort by country > for a customer. > Is there any chance to get it per whois/some > application or do we buy some part of whois-db from ripe? > > The background is that a Online-Service needs this part > of information to display the right website (on his top-level > Webserver wich are reached by every online user first) > for every user by his language. > > We are grateful for each assistance. > > Kind regards, > _____________________________ > Stephan Mankopf > Networks/Backbone > +49 5241 80 88729 > stephan.mankopf(a)mediaways.net > > > > >

1 0

Draft Minutes of the DB WG meeting RIPE 36
by Nigel Titley 29 Aug '00

29 Aug '00

Gentlefolk, Here are the draft minutes to the DB WG meeting at RIPE 36, in Budapest. Due to a fit of spring-cleaning, I ended up deleting my notes of the first part of the meeting. Please feel free to fill any gaps and correct any errors. best regards Nigel Draft Minutes for the Database Working Group Meeting RIPE-36, May 2000, Budapest, HU 1. Draft Thursday, May 18, 2000 at 10:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (Wilfried Woeber, chair) . scribe Nigel Titley volunteered to take the minutes . raw scribe notes distributed Wilfried had not had time to process the raw notes from RIPE 35, but these were circulated in lieu of full minutes. . help offered by - Nigel Titley, - Ulf Kieber Wilfried asked the WG if they were happy to accept the help offered by Nigel Titley and Ulf Kieber. Nigel would help with the PR and documentation side of the group, and Ulf will help to co-ordinate the working group. He received approval from WG on this issue. B. RIPE DB, operational update (Andrei Robachevsky, RIPE NCC) Andrei Robachevsky gave an operational update on the state of the RIPE DB. Amongst the many statistics that he presented it was noted the very large number of domain objects, mostly from the .de domain. It was explained that these objects would be shortly devolved to the DE-NIC whois server, and plans were currently being formulated to perform this move with minimum disruption to the RIPE community. C. DB Software Re-Implementation (Joao Damas, RIPE NCC) Joao Damas gave a short presentation on the progress of the DB Software re-implementation project. D. Report on Certification Authority activities (Paul Gampe, APNIC) Paul Gampe gave a very interesting presentation on the use of X509 certificates for authentication when updating the APNIC database. The following points were noted: - Training at the next RIPE meeting might be useful, to provide a view of X509 vis-a-vis PGP. There appears to be a degree of convergence between the two systems. - It was noted that it will be soon possible to sign X509 keys with PGP signatures and vice versa. - The main objection to using X509 is the cost of the commercial licenses. The first phase of the implementation will sort out licenses for users. Much cheaper (free) approaches are on their way. E. Activity Plan for next year! It was noted that input to the RIPE-NCC activity plan was needed before September. Suggestions received from the WG included - Use of X509 signature for authentication (as per APNIC) - Support for other character sets than ASCII. (Joao noted that the new code is 8-bit clean, but that there is problem wit the reproduction of character sets. The best he felt able to do was to track progress by other sources, and to keep the code clean). - Removal of further domain objects from the database. The problem being that existing applications must not be affected. It was suggested that the RIPE-NCC could offer help to other ccTLDs to set up their own whois databases. It was suggested that we ask CENTR to produce a regular report and to try and get domain objects shifted out of the DB. [AP: Wilfried Woeber and Joao Damas] F. Input from other WGs - EIX-WG would like an object in the DB to describe IXs. It was also suggested that a peering contact in the aut-num object could be useful. There was some support for both these proposals and it was suggested that a formal request be made to the WG by email. - Routing WG. No further input had been received from the Routing WG re native multicast. It was felt that this would soon need looking at. The Routing WG needs to add an entry to the RPSL Draft. G. AOB - A suggestion (Joel Rowbottom) was made to use XML for registration templates. Suggestions as to how to do this would be gratefully received. [AP: Joao Damas to produce a presentation for the RIPE 37 meeting] - A suggestion to use a mail-to authentication scheme was received from Michael Battilana (IANA). The idea being that agreement to proceed with a modification would be obtained via a token and confirmation from a know mail mail address. It was agreed that this was not very easy to do as it is stateful and could lead to DOS attacks on the database. - A brief update was given on CERT/IRT-related issues (WW144/Jaques Schuurman). Ut was suggested that a pointer be added to inet-num object to point to the IRT role. Anyone interested in this work to contact the WG.

1 0

Whois queries in the RIPE database v3.0
by Andrei Robachevsky 28 Aug '00

28 Aug '00

Dear Colleagues, Please find below an inventory of the query part of the new database software (v3.0). I tried to highlight the differences from the current RIPE Database implementation, but also to explicitly mention some features of the current software that were not documented before. Most of this document is a summary from a more detailed documentation, which is available from http://www/ripencc/pub-services/db/reimp/queries.ps However, some features, like '-d' or '-q sources' flags, are new and we would like to know your opinion and comments on these. Almost all functionality is already implemented, although some minor parts are missing, mainly because we would like to receive your comments first. We will appreciate your comments and suggestions, Best regards, Andrei Robachevsky DB Group Manager RIPE NCC Whois queries in the RIPE database v3.0 ======================================= 1. New queries -------------- -l <ip range> One level less specific. Does NOT return the exact match but only the smallest of the IP ranges that is bigger than the user supplied range and that fully contains it. -x <ip range> Exact match. Returns the inetnum or route object with the ip range matching exactly the user supplied range. If no matching object is found nothing is returned. -K Requests that only primary keys of the objects are to be returned. The exception is a set object, where the members attribute is also returned. -q sources List all available sources. The format of the output is: <source>:<NRTM protocol version>:<mirroring>:<first>-<last> Where <source> - is the string that identifies the Database (e.g. RIPE) NRTM protocol version identifies the version of mirroring protocol (currently 1). <mirroring> can take one of the following values: Y/N/X - can mirror/cannot mirror/obscured <first> is the lowest serial number available <last> is the most recent serial number available The following semantics apply: Y:<first>-<last> mirroring allowed, serials from range <first>-<last> available N:<first>-<last> mirroring not allowed for administrative reasons. Ask Database Administration for permission. N:0-<last> mirroring physically not possible (e.g. static snapshot of serial <last>) X:<msg> no mirroring allowed. An explanation is given in <msg>. -q version Displays version number of the server software. -d Triggers inclusion of in-addr.arpa and ip6.int domain objects in the result of IP lookup. By default in-addr.arpa and ip6.int domain objects are not included in the output. With -d flag it is possible to have More/less specific lookups for in-addr.arpa and ip6.int domains. Their use is similar to those for IP numbers except that lookups have to be on 8 bit boundaries for IPv4 lookups and 4 bit boundaries for IPv6 lookups. 2. Inverse queries. ------------------ The following inverse queries are supported by v3.0 software: -iac (or -iadmin-c) <nic-handle|name> Returns all objects whose admin-c attribute matches the query argument. -itc (or -itech-c) <nic-handle|name> Returns all objects whose tech-c attribute matches the query argument. -izc (or -izone-c) <nic-handle|name> Returns all objects whose zone-c attribute matches the query argument. -iah (or -iauthor) <nic-handle|name> Returns all objects whose author attribute matches the query argument. -icn (or -icross-nfy) <nic-handle|name> Returns all objects whose cross_nfy attribute matches the query argument. -ipn (or -iperson) <nic-handle|name> Equivalent to -iac,tc,zc,ah,cn (or -iadmin-c,tech-c,zone-c,author,cross-nfy). -iny (or -inotify) <e-mail address> Returns all objects whose notify attribute matches the query argument. -idt (or -iupd-to) <e-mail address> Returns all objects whose upd-to attribute matches the query argument. -imb (or -imnt-by) <maintainer name> Returns all objects whose mnt-by attribute matches the query argument. -iml (or -imnt-lower) <maintainer name> Returns all objects whose mnt-lower attribute matches the query argument. -imr (or -imbrs-by-ref) <maintainer name> Returns all objects whose mbrs-by-ref attribute matches the query argument. -imn (or -imnt-nfy) <e-mail address> Returns all objects whose mnt-nfy attribute matches the query argument. -imu (or -imnt-routes) <maintainer name> Returns all objects whose mnt-routes attribute matches the query argument. -ict (or -icross-mnt) <maintainer name> Returns all objects whose cross-mnt attribute matches the query argument. -ior (or -iorigin) <AS key> Returns all objects whose origin attribute matches the query argument. -ila (or -ilocal-as) <AS key> Returns all objects whose local-as attribute matches the query argument. -imo (or -imember-of) <set name> Returns all objects whose member-of attribute matches the query argument and their claim is validated by mbrs-by-ref attribute of the set. Absence of mbrs-by-ref attribute means that the membership is only defined by the members attribute of the set. -irz (or -irev-srv) <hostname|IP address> Returns all objects whose rev-srv attribute matches the query argument. -ins (or -inserver) <hostname|IP address> Returns all objects whose nserver attribute matches the query argument. -isd (or -isub-dom) <domain name> Returns all objects whose sub-dom attribute matches the query argument. -irb (or -ireferral-by) <maintainer name> Returns all objects whose referral-by attribute matches the query argument. 3. Other differences from v2.x software --------------------------------------- -iro (or -irole) <nic-handle|name> This query is not supported. -k Is accepted without an argument. In this case it just opens a persistent connection to a server. The next -k without argument will close the connection.

1 1

RE: ccTLD data moving from RIPE db
by Wilfried Woeber, UniVie/ACOnet 17 Aug '00

17 Aug '00

[ editorial: I think this should move from lir-wg(a)ripe.net to db-wg(a)ripe.net So, for any follow-up, please use db-wg and remove lir-wg. Thanks. ] Alex, >Then today I got a mail from the .IE domain registry, asking me to remove >entries from the RIPE DB for some .ie domains I have. The RIPE NCC, or the RIPE community never had any authority over the ccTLD name tree in the RIPE-DB. The individual sub-trees were (some still are) managed by the respective TLDs. So, from that point of view, the request in itself is probably valid. > So far so good, >except that the .ie domain registry does not have a functional whois >database to which we can move this data. If I comply, the data will no >longer be accessible from any whois databse. Well, not necessarily so. What "we" (the people and groups involved to migrate the name sub-trees to dedicated registries, maintined by the TLDs) had in mind was to preserve the "single point of entry" for the RIPE region to query domain names. To that end, the DB software was extended to support a referral mechanism. Assuming that this technology is deployed, you could still send your query to whois.ripe.net and the software would try to find a referred-to server which is authoritative for the name-tree. The RIPE server would then forward the request and send the answer back to the client. Quite a few TLD registries, which already have moved away from using the RIPE DataBase have completed that setup. Others are in the process of fixing migration problems. Other, obviously, have decided to _not_ use that option. Sigh. I'm still working with the RIPE NCC's DB group and CENTR to fixing deployment problems related to the referral mechanism. A couple of days ago, a summary page has become available on CENTR's server: http://www.centr.org/technical/ripe-db.html >Is this therefore a valid request? > >Thanks, Best regards Wilfried (DB-WG chair) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The strange thing about common sense is that it is so uncommon. Buddah

1 0

RIPE-181 server to be decommissioned
by gerald＠merit.edu 10 Aug '00

10 Aug '00

As many of you know, Merit began a production RPSL service on 11/1/99. RIPE-181 and RPSL coexisted on our production server until 1/1/00; after that date, RIPE-181 updates were no longer accepted and only queries were available on the special RIPE-181 server. Merit will now complete the final stage of its transition to RPSL by decommissioning its RADB RIPE-181 server on Wednesday, August 23, between 5:00-8:00 A.M. EDT. Query activity has been extremely light on the RIPE-181 server and the remaining users have been notified by private email about the termination of this service. This change will not impact our production RPSL service. Please send your questions and comments to db-admin(a)radb.net. IRRd Team --Gerald Winters

1 0

RIPE whoisd re-implementation: RIP-0.4.0beta1 software snapshot
by RIPE NCC Staff 07 Aug '00

07 Aug '00

Dear All, this mail is to notify you of the further advancements in the development of the new implementation of the RIPE Database software. Today, we have freezed the source code into a new snapshot. There has been a certain amount of changes from the last snapshot. Multiple repository support has been added, a test mode is now available to update the database, MIME messages are now supported by dbupdate, the configuration module has been integrated, and many bugs have been fixed. You can download this last snapshot at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.4.0beta1.tar.gz You can also test the functionality of this snapshot of the RIP whois server in 2 ways: - By querying the host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database. - By using the RIP Test Database. You can send test updates to this database at the address <rip-test(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. This database is running in test mode, so you can create any type of objects there, even maintainers. We would be very pleased if you could test the new implementation in both ways, and let us know your opinions. Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. Regards, Filippo Portera ____________________________ RIPE Database Administration.

2 1

PGPKEY Reminder
by gerald＠merit.edu 26 Jul '00

26 Jul '00

On 7/30/00 between 5 AM - 8 AM EDT Merit will convert from 'PGP-FROM' to 'PGPKEY' authentication as described in RFC 2726. All maintainer object 'PGP-FROM' instances will be converted to a 'PGPKEY' instance and a 'key-cert' object will be created for each unique 'PGPKEY' instance. After the conversion all public keys used for signing DB submissions will be visible in the registry as 'key-cert' objects. Registering public keys allows users to verify a maintainer's identity and to submit, update and maintain their own public keys like any other DB object. Normal PGP signing of DB submissions will continue to work exactly as before the conversion. The conversion should be seamless to our DB user community and no action is required. Merit has sent email to all users who will be affected by the conversion. The new 'PGPKEY' scheme makes it easier for users to integrate PGP signing into their DB update process. It is our wish that into the future all registry users will PGP sign their DB submissions. Please see www.radb.net/docs/keyfaq.html for additional information on the conversion process and tutorial information regarding the use of 'PGPKEY' authentication. Please consult RFC 2726 for the authoritative specification. IRRd team --Gerald Winters

1 0

***Announcement: Merit to convert to 'PGPKEY' authentication (RFC 2726)
by gerald＠merit.edu 17 Jul '00

17 Jul '00

On 7/30/00 between 5 AM - 8 AM EDT Merit will convert from 'PGP-FROM' to 'PGPKEY' authentication as described in RFC 2726. All maintainer object 'PGP-FROM' instances will be converted to a 'PGPKEY' instance and a 'key-cert' object will be created for each unique 'PGPKEY' instance. After the conversion all public keys used for signing DB submissions will be visible in the registry as 'key-cert' objects. Registering public keys allows users to verify a maintainer's identity and to submit, update and maintain their own public keys like any other DB object. Normal PGP signing of DB submissions will continue to work exactly as before the conversion. The conversion should be seamless to our DB user community and no action is required. Merit will send email to all users who will be affected by the conversion. The notice will give users a chance to remove their PGP references if (for whatever reason) they do not wish to take part in the new PGP authentication scheme. The new 'PGPKEY' scheme makes it easier for users to integrate PGP signing into their DB update process. It is our wish that into the future all registry users will PGP sign their DB submissions. Please see www.radb.net/docs/keyfaq.html for additional information on the conversion process and tutorial information regarding the use of 'PGPKEY' authentication. Please consult RFC 2726 for the authoritative specification. IRRd team --Gerald Winters

1 0

New object
by Stephen Burley 11 Jul '00

11 Jul '00

Hi I have a quick question has any ever thought of creating a company object, which is much the same as a person object but it means that any range of IP's assigned to a company will easily be traced. Making it easier to find the total amount IP space assigned to a company/org , which frankly at the moment is impossable. Regards -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life Stephenb(a)uk.uu.net if you're stupid and willing to wait" ------------------------------------------------------------------------

4 6

Duplicate mails
by NCC local-ir list Moderator 07 Jul '00

07 Jul '00

Dear subscribers, Please notice that we are experiencing some strange mail behaviour at the moment. The previous mail from Mr Henning Brauer seems to have been re-sent to the lists in error. We are not sure of the cause yet. Before replying to what may seem like an old thread, please check the sent date. We will endeavour to prevent any more of these mails leaking through. Regards, John Crain Head of Internal Services

1 0

RE: a few matters about security and consistency
by adrian.pauling＠bt.com 06 Jul '00

06 Jul '00

Dear All, Issue 1 is of interest to anyone involved with RIPE database. It must be in the RIPE communities interest to keep data as up to date and accurate as possible. Auditing is a resource hungry task and a pain in the asynchronous port, but is necessary to maintain and improve the quality of the data within the database. Is it acceptable for RIPE database to periodically, say once a year, to contact via e-mail each person and role object? The objective would be to ensure the person / role object are up to date. If there was no response, perhaps within a 4 week period, any associated maintainer object could be used to identify other people who could up date the records. If there is no maintainer, then a RIPE Hostmaster maintainer or notify attribute could be added to the record - and mark the record as out of date as appropriate . This would be a small overhead to everyone who is on the RIPE database that would ensure and improve the integrity of data within the database, for a piece of work on the database. From below, there is a possibility of up to 10 % of records on the database being inaccurate. That can not be an acceptable situation. Issue 2 is beyond the direct scope of the LIR-WG. However, I recollect that at RIPE 35 there was a suggestion of adding a new database record to the RIPE database, to clearly identify those networks which had a CERT team - has any progress been made? Regards, Adrian F Pauling :-)NEL2C Internet Protocol Manager acd Information Systems Engineering Technical Architecture AFP1-RIPE / AFP-ARIN / AFP25-InterNIC * adrian.pauling(a)bt.com * +44 19 2685 1992 / +44 78 0290 4877 British Telecommunications plc Registered Office 81 Newgate Street London EC1A 7AJ Registered in England no 1800000 > -----Original Message----- > From: Mark Lastdrager [SMTP:mark@pine.nl] > Sent: 05 July 2000 21:53 > To: lir-wg(a)ripe.net > Cc: cert(a)pine.nl > Subject: a few matters about security and consistency > > Hi, > > There are two matters I want to discuss, which are related from my point > of view. > > Yesterday, ons of our hosts was attacked (Denial of Service). The attacker > was using the DNS DOS described in > http://www.ciac.org/ciac/bulletins/j-063.shtml (AUSCERT AL-1999.004) for > this. > > The used attack in short: Small DNS queries are sent from the attacker > to each of the DNS servers. These queries contain the spoofed IP address > of the target. The DNS servers respond to the small query with a large > response. These responses are routed to the target, causing link > congestion and possible denial of Internet connectivity. > > This morning, we took our tcpdump logs of the attacks, and built a script > which queried the Ripe database for the admins of the abused > ('man-in-the-middle') networks. We got almost 900 unique email adresses > out of this, to whom we sent a clear email describing what happened and > asking for any logs or other usable information to find out who the > attacker is. We we astonished how many people reacted with usefull > information, we are still investigating right now. > > It pointed out we were not the only one attacked, it now looks like the > attacker (or attackers ofcourse) is abusing most of the 194.x network to > amplify the DNS requests pointing at a lot of Dutch hosts and even some > in the USA. > > Ok, that was the scary part ;-) If you operate 1 or more DNS servers, > please read the AUSCERT document and apply the workarounds they mention > there (only allow your nameserver(s) to answer to queries from trusted > hosts and/or zones you are authoritive for). If will really help from > people abusing your network and filling up your pipe(s). > > Matter 1: > > What scared me was the great amount of bounced mail we got back from the > 900 mails we sent. I think at least 10% did not exist. Besides that we got > a lot of replies like 'hey don't bother me, I don't work there > anymore'. Why doesn't RIPE test periodically if email adresses still work? > > > Matter 2: > > Like I said, we got a lot of useful replies and they all more or less > contained the same information. People had full, non-working internet > links for days because of the attacks and were very happy that we pointed > them to the 'Auscert workaround' because now they've closed their DNS'es > the traffic (and business!) goes back to normal. Because of the info we > got, we are -while I write this- trying to trace back to the origin of the > spoofed packets. > > I think it would be very helpful if there was a mailinglist where European > operators could discuss this kind of incidents, like the USA people do at > the Securityfocus mailinglist > (http://www.securityfocus.com/templates/archive.pike?list=75). I think the > introduction at http://www.securityfocus.com/forums/incidents/intro.html > would describe the use of such a list very well. Incidents like this DOS > which affect a lot of European networks could be stopped much quicker, and > if you can contact your fellow operators you don't have to waste expensive > time trying to track down those stupid scriptkids (believe me.. it takes a > lot of time ;-)). Ofcourse things like virii, talk about used exploits > etc. are on-topic and interesting too. > > Like I said: time is money, so we set up the list > euro-incidents(a)security.nl already. Anybody can subscribe at > http://www.security.nl/mailman/listinfo/euro-incidents. > > Thanks for your time, > > Mark Lastdrager > Pine Internet > > -- > email: mark(a)lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 > http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 > PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl > Today's excuse: We only support a 28000 bps connection. > > > > >

1 0