- db-wg - mailman.ripe.net

mntner creation
by Ulf Kieber 01 Aug '05

01 Aug '05

Hi all, did I miss something or since when does the RIPE DB permit creation of mntner objects by direct mail. Several of our customers have started creating mntners ad libitum and the mntner creation feature on lirportal.ripe.net has become pretty superfluous. -- Ulf Kieber email: ukieber(a)cogentco.com Sr. Network Engineer voice: +49-69-299896-21 C.C.D. Cogent Communications Deutschland GmbH fax : +49-69-299896-40 Optical Internet www : www.cogentco.com Brilliantly Fast. Elegantly Simple. AIM : ulfkieber

2 1

Wierd output of whois/database
by Matthew Smith 25 Jul '05

25 Jul '05

Hi all, if this is the wrong list, then please point me in the right direction. I am first assuming that I have done something wrong. I should have a role 'AHM' with two person objects (MS33051-RIPE and DB). The whois output (below) also gives two further records at the end which I cannot fathom how or why they appear. Comments please Regards Matthew msmith:mlnet%whois -h whois.ripe.net -- -B AHM % This is the RIPE Whois query server #1. % The objects are in RPSL format. % % Note: the default output of the RIPE Whois server % is changed. Your tools may need to be adjusted. See % http://www.ripe.net/db/news/abuse-proposal-20050331.html % for more details. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html % Information related to 'AHM' role: Aexiomus Hostmaster address: Aexiomus Limited address: United Kingdom phone: +44-906-7530143 fax-no: +44-906-7530143 e-mail: hostmaster(a)aexiomus.net e-mail: hostmaster(a)aexiomus.net.uk admin-c: DB tech-c: DB tech-c: MS33051-RIPE nic-hdl: AHM mnt-by: AEXIOMUS-MNT mnt-by: MLNET-MNT notify: hostmaster(a)aexiomus.net.uk source: RIPE changed: hostmaster(a)aexiomus.net.uk 20050504 person: Denesh Bhabuta address: PO Box 2023 address: Wickford address: SS12 9RX address: United Kingdom phone: +44-906-7530143 e-mail: denesh(a)cyberstrider.net e-mail: denesh(a)aexiomus.net.uk e-mail: denesh(a)bhabuta.co.uk e-mail: denesh(a)dbcl.net nic-hdl: DB mnt-by: AEXIOMUS-MNT changed: hostmaster(a)cyberstrider.net 20000821 changed: hostmaster(a)cyberstrider.net 20020208 changed: denesh(a)aexiomus.net.uk 20020515 changed: denesh(a)aexiomus.net.uk 20030630 source: RIPE person: Matthew Smith address: ML Associates, 11 Grove Lane, Great Kimble address: Aylesbury, Bucks, HP17 9TR, UK phone: +44-20-7871-0604 e-mail: hostmaster(a)aexiomus.net e-mail: matthew(a)aexiomus.net e-mail: m(a)mlnet.co.uk e-mail: hostmaster(a)mlnet.net remarks: skype: monthemove nic-hdl: MS33051-RIPE mnt-by: AEXIOMUS-MNT mnt-by: MLNET-MNT source: RIPE changed: m(a)mlnet.net 20050429 changed: m(a)mlnet.net 20050526 % Information related to 'DB' person: SAIDUR AHM RAHMAN address: RAHMAN SAIDUR AHM address: VIA BARTOLOMEO CRISTOFORI 11 address: 00100 ROMA address: Italy phone: +39655302089 fax-no: +39655302089 nic-hdl: SAR32-RIPE changed: order.manager2(a)telecomitalia.it 20041022 source: RIPE % Information related to 'SAR33-RIPE' person: SAIDUR AHM RAHMAN address: RAHMAN SAIDUR AHM address: VIA BARTOLOMEO CRISTOFORI 11 address: 00100 ROMA address: Italy phone: +39655302089 fax-no: +39655302089 nic-hdl: SAR33-RIPE changed: order.manager2(a)telecomitalia.it 20041022 source: RIPE

3 3

Signature expiration check proposal
by Katie Petrusha 25 Jul '05

25 Jul '05

Dear Colleagues, This is a proposal about changes to how the whois database software checks PGP and X.509 signatures on incoming updates. Currently the software checks that the PGP signature is valid by using Gnu Privacy Guard (GnuPG). It verifies X.509 signatures with an OpenSSL (Secure Sockets Layer) tool. We propose to change the software, so that it also checks the signature creation date. If the signature is older than one week, it will be rejected and the update will fail. This is to prevent replay attacks on database objects. We became aware of this potential threat when we designed the DNSSEC provisioning system. -- Katie Petrusha RIPE NCC

2 1

Proposed changes for object ordering
by antointhe 20 Jul '05

20 Jul '05

An ordinary user writes: This is just great! No wonder they disposed of 'Mr Post Office' (hint). Look guys, I've got ppl scanning me all over and I can't even find out who it is. I have little time for the anticipated learning curve and I don't know if some fanatic wants to turn my machine into a bot or its just windows doing its thing. I have a feeling sensible folks like yourselves have anticipated situations like this and have tools around to help. The only query engine output is duplicated at my firewall. Is it possible that some of you have interests elsewhere? Not advisable in these days of insurgency... Best Regards antointhe

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training Services 19 Jul '05

19 Jul '05

Dear Colleagues The RIPE NCC Training Services Department invites you to register for one of our upcoming Routing Registry Training Courses: Date: Friday 19 August 2005 Time: 0900 - 1700 Location: Amsterdam, the Netherlands AND: Date: Friday 21 October 2005 Time: 0900 - 1700 Location: Sofia, Bulgaria AND: Date: Friday 28 October 2005 Time: 0900 - 1700 Location: Oslo, Norway AND: Date: Friday 4 November 2005 Time: 0900 - 1700 Location: Edinburgh, United Kingdom AND: Date: Friday 25 November 2005 Time: 0900 - 1700 Location: Munich, Germany The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/rr/ How to register: --------------------- You can register up to two people from your LIR for each course. (If there are places left nearer the time of the course, you can register more people). To register for this course, you can either use the LIR Portal at: https://lirportal.ripe.net/lirportal/training/course-list.html Or the online registration form on our website: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions, send an e-mail to <training(a)ripe.net>. Kind regards Rumy Kanis Training Services Manager RIPE NCC

1 0

New Attribute in DOMAIN Object
by Olaf M. Kolkman 18 Jul '05

18 Jul '05

Dear Colleagues, You may have seen our recently announced plans to deploy DNSSEC on the reverse tree. You can read more about this at: http://www.ripe.net/ripe/maillists/archives/db-wg/2005/msg00156.html This plan contains a proposal for the new "ds-rdata:" attribute. This attribute is used to perform the public key exchange that is needed to obtain a secured delegation. It is used in addition to the delegation information stored in the "nserver:" attribute. You can find more details in the Draft Registry Procedure at: http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html Kind regards, -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC

1 0

Changes for abuse
by dfoley 15 Jul '05

15 Jul '05

This document is very confusing. The section : "(3) Adding 'abuse output' Option " describes the changes to the result returned for "$ whois 10.0.0.10". However the result displayed is actually the result before the change. This is followed by a description of the result of "$ whois -b 10.0.0.10". The result includes "e-mail:" attributes but no "abuse-mailbox:" attribute. So which request do I use to obtain the "abuse-mailbox:" attibute? . In your examples it is only returned with the "$ whois -L 10.0.0.10". And yet I am supposed to use the "$ whois -b 10.0.0.10" to get the abuse contacts. Should I expect to ignore the attributes and treat any email address returned with the "whois -b" request as an abuse contact? I have tried using the "whois -b" and I have yet to get a result without ERROR appearing.

2 1

Status of 'org' attribute
by MarcoH 13 Jul '05

13 Jul '05

[appologies for cross-posting this] Hi all, Maybe I missed out on something, but accoording to various templates in the ripe-databese, the org-attribute is optional. Apparently the hostmaster mailrobot things otherwise and refuses requests with an error because of the org-attribute not being present. I just ran into it on a ASN request, but I recall having problems before with this. Can anybody tell me who is right, the database template or the robot ? In fact, the database reference (http://www.ripe.net/ripe/docs/databaseref-manual.html#1.2.3) doesn't list it all. Grtx, MarcoH

2 2

RE: [db-wg] Trouble inserting inetnum inetnum object.
by Ramarajan, Arvind, ALABS 12 Jul '05

12 Jul '05

Tobias, Yup, that was the problem. ALLOCMNT in rip.config was not pointing to the wrong mntner. Regarding allocating a /25, I had the same problem even allocating 10/8. Thanks to all who responded. Thanx --> Arvind. -----Original Message----- From: Tobias Cremer [mailto:tcremer@de.cw.net] Sent: Tuesday, July 12, 2005 4:12 AM To: Ramarajan, Arvind, ALABS; db-wg(a)ripe.net Subject: Re: [db-wg] Trouble inserting inetnum inetnum object. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Arvind, Daniel Roesen wrote: > On Mon, Jul 11, 2005 at 02:10:52PM -0500, Ramarajan, Arvind, ALABS wrote: >>***Error: ALLOCATED inetnum objects require the RIPE NCC maintainer > > Make this status "ASSIGNED PA". correct - however, if you really want to create a ALLOCATED PA object (which is rather unlikely for a /25 :-) ), you have to use the mntner that is defined in rip.config to be allowed to created allocation objects. Have a look there for the ALLOCMNT section. Regards: Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFC03tfhC6y11CNwvcRAuv4AKCO9mghpONbgXmldjcGYs3N5IA5iwCfTu3i P3rdrbFnUgkHEVx/8JnT0Qs= =2V6/ -----END PGP SIGNATURE-----

2 1

Trouble inserting inetnum inetnum object.
by Ramarajan, Arvind, ALABS 12 Jul '05

12 Jul '05

Hi, I have an internal RIPE DB instance to which 'am not able to add a new inetnum object. Following the e-mail reply I get after submitting a e-mail request: SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 1 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Create FAILED: [inetnum] 10.122.0.0 - 10.122.0.127 ***Info: Syntax check passed inetnum: 10.122.0.0 - 10.122.0.127 netname: SUBNET1-LOOPBACK0 descr: Loopback0 addresses country: US admin-c: AR1-ATTIR tech-c: HK1-ATTIR status: ALLOCATED PA notify: aramarajan(a)att.com mnt-by: MNT-ATTIR mnt-lower: MNT-ATTIR changed: aramarajan(a)att.com source: ATTIR ***Warning: Date '20050711' added to changed: attribute 'aramarajan(a)att.com' ***Error: ALLOCATED inetnum objects require the RIPE NCC maintainer The person (AR1-ATTIR and HK1-ATTIR), role and mntner (MNT-ATTIR) refereffed above have already been loaded using make_db from a flat file similar to sample.db.gz. Any help appreciated. Thanx --> Arvind.

4 3

DNSSEC deployment on the reverse tree.
by Olaf M. Kolkman 06 Jul '05

06 Jul '05

[Apologies for duplicates] Dear Colleagues The RIPE NCC has been involved with the development of the DNSSEC protocol. Now that the protocol has become available, we plan to implement DNSSEC on our domains in the reverse DNS tree. The deployment of DNSSEC is the second and last phase of the Reverse DNS restructuring project. You can find more information about this project at: http://www.ripe.net/rs/reverse/dnssec/index.html To implement DNSSEC, we propose extending the policy for Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region. You can find the proposed policy at: http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html. We welcome your feedback on this poposal before 1 August 2005. Please send your comments to the DNS Working Group Mailing List. We are also introducing two new procedures: "DNSSEC Key Maintenance Procedure" http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html and "Procedure for Requesting DNSSEC Delegations" http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html Your feedback on these drafts is also welcome, again please send this to the DNS Working Group Mailing List. As part of the "Procedure for Requesting DNSSEC Delegations" we plan to add a "ds-rdata:" attribute to DOMAIN objects. Regards Olaf M Kolkman New Projects, RIPE NCC.

2 1

Proposed changes for object ordering
by Imro San 05 Jul '05

05 Jul '05

When will the new proposal be available and how? Licensed Sygate User

1 0

RIPE51: EOF Stream/Plenary presentations from the DB-WG Camp
by Wilfried Woeber, UniVie/ACOnet 01 Jul '05

01 Jul '05

Dear DB-WG subscribers! We expect the next RIPE Meeting (RIPE51 @ AMS) to be structured very much like RIPE50 (aka the "new format" :-) At the end of August 05, the Chair of RIPE and the meeting planners, together with the WG chairs, would like to review (the better part of) the EOF/Plenary Stream contributions. In order to avoid being paralized by many people being out of office during summer, I'd like to distribute this call for presentations for the Plenary from the DB-WG environment. If you intend to offer a presentation, or would like to see a particular presentation at RIPE51, please spaek up now - either to me directly or to the WG list. This is just an early warning, please expect a formal call for contributions. Thanks, and have a nice summer and relaxing vaction period! Wilfried.

1 0

mnt-routes bugs
by Daniel Roesen 29 Jun '05

29 Jun '05

Hi, instead of spending developer time on poem/limerick objects, could we please get all the mnt-routes and other authorization bugs fixed, like: http://www.ripe.net/bugzilla/show_bug.cgi?id=118 http://www.ripe.net/bugzilla/show_bug.cgi?id=136 http://www.ripe.net/bugzilla/show_bug.cgi?id=137 and today I might have found a possible bug that is similar to 118, but IPv6: ***Warning: The parent [route6] 2001:5000::/21AS1273 has invalid prefix ranges in "mnt-routes:" attribute(s): 2001:5001:103::/48 The object has: route6: 2001:5000::/21 ... mnt-routes: CLUE-MNT {2001:5001:103::/48} I'm trying to create route6 2001:5001:103::/48. Is the mnt-routes syntax used wrong? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

2 1

whois lookup limits
by Hank Nussbacher 28 Jun '05

28 Jun '05

What are the current limits on whois lookups and how does one get a specific IP changed? I have someone getting "ERROR:202: access control limit reached for x.x.x.x" Thanks, Hank

2 2

Re: The Cidr Report
by Hank Nussbacher 22 Jun '05

22 Jun '05

On Wed, 22 Jun 2005, Geoff Huston wrote: One potential problem: ERX data. I am looking at all the Israeli entries for example, from 192.114.x.x-192.118.x.x You will find it in RIPE whois, but you won't find it in the RIPE stats file since the block was ERXed as were probably many others. Not sure how you can handle that. Regards, Hank > cleared up BUT changed in one important respect: > > If an entry isin the RIPE whois database but NOT in the RIPE stats file I'm > marking it as potentially bogus. I would like to see the RIPE stats file be > an accurate picture of RIPE managed address space, and the database is > completely unreliable :-( > > Geoff > > > > At 01:08 AM 18/06/2005, Hank Nussbacher wrote: > > >I was hoping the report would be cleaned up by now but it hasn't so sorry > >for the multiple list post. The Bogon section is IMHO, broken. > > > >Taking just the 1st line as an example: > >Prefix Origin AS AS Description Unallocated block > >3.0.0.0/8 AS80 GE-CRD - General Electric Company 0.0.0.0 - 3.0.0.0 > > > >3.0.0.0/8 is allocated, as is AS80. I suspect the algorithm, which > >determines the unallocated block of 0.0.0.0 - 3.0.0.0 to be somewhat > >broken. > > > >There are thousands of lines like that. > > > >The bogus AS section also appears to be broken. > > > >-Hank > > > > +++++++++++++++++++++++++++++++++++++++++++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. >

3 3

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 22 Jun '05

22 Jun '05

> Sorry, limerick, that you had to die. > And sorry haiku, that you never had the chance to be an object for > yourself. > > I wrote a haiku and a limerick about that topic. Maybe they might help > others who feel just as melancholy as me: > > POEM-HAIKU-OBJECT > POEM-LIMERICK-OBJECT Perhaps I could suggest a minute's silence on the mailing list as a mark of respect. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

irt object useless
by Andre Koopal 21 Jun '05

21 Jun '05

Last week we updated all our allocations with an IRT object. However, this ended out to be quite useless as the IRT object isn't shown in a default query, which 99% of joe-user will do, they don't know to specify -c. Another problem I noticed is that the irt-nfy isn't suppressed if you do specify -c. So I want to propose to show the IRT object in a default query and to also hide the irt-nfy attribute in that default query. Regards, Andre Koopal MCI

5 13

Whois changes
by Erics 20 Jun '05

20 Jun '05

Hi, i noticed that whois gives the full details at the moment. Is this a temporary feature or did you switch back to the old output ? regards Eric Schmidt

3 2

Implementation of POEM object
by Arife Vural 20 Jun '05

20 Jun '05

Dear Colleagues, [Apologies for duplicates] Following discussions in the Database Working Group, we have made changes to the whois server software. These are the proposed changes: - Add a new object POETIC-FORM that will contain the supported poem types. - Add a new object POEM that will hold the poem itself. - Add a new attribute "form:" that shows the type of poem. There is more information about this below. You can find more details about the discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00246.html We expect to put a new whois server on line with new object support on 3 May 2005 at 16:00 CET. - Add a new POETIC-FORM object: The POETIC-FORM object contains information about the poem type. This is an example of a LIMERICK object: poetic-form: FORM-LIMERICK descr: Poem type for Limerick admin-c: AMR68-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20050429 source: RIPE These objects will be maintained by RIPE DBM. You can send new POETIC-FORM objects to <auto-dbm(a)ripe.net>. - Add a new POEM object: A POEM object is similar to the LIMERICK object. Unlike the LIMERICK object, it will have a "form:" attribute that contains information about the poem type. This is an example of a simple POEM object: poem: POEM-NT13-1 descr: RIPE24 dinner text: At a RIPE Meeting, held in Berlin, text: The meal was unusual, the din text: Of the two serenades text: Whose repertoire made us text: All smile and want to join in form: FORM-LIMERICK admin-c: LIM1-RIPE author: NT13 mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE Add a new "form:' attribute: The "form:" attribute indicates the type of poem. - Changes to the default whois query interface: There will be no changes to the whois query interface. - Data transition All existing LIMERICK objects will will be converted to POEM objects. LIMERICK objects will appear in the database for a while, but we will eventually delete them. Here is an example of a LIMERICK object: limerick: LIM-NT13-3 text: The document RIPE-104 text: Goes on longer than ever before text: If you want an address text: And your network's a mess text: Then Daniel will get very sore admin-c: LIM1-RIPE author: NT13 remarks: Great limerick, but the draft document RIPE-104++ remarks: is now called RIPE-136... mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE Here is how it will appear with new object types: poem: POEM-NT13-3 text: The document RIPE-104 text: Goes on longer than ever before text: If you want an address text: And your network's a mess text: Then Daniel will get very sore form: FORM-LIMERICK admin-c: LIM1-RIPE author: NT13 remarks: Great limerick, but the draft document RIPE-104++ remarks: is now called RIPE-136... mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE - Object templates Here is the template for the POEM object: poem: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] form: [mandatory] [single] [inverse key] text: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] author: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] POETIC-FORM object template is: poetic-form: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Regards, Arife Vural RIPE NCC, SED

2 2

Draft minutes of DB-WG meeting RIPE 49 V2.0
by Kanner 13 Jun '05

13 Jun '05

pierosciacero(a)hotmail.com

1 0

Whois Database currently off-line
by Shane Kerr 08 Jun '05

08 Jun '05

Dear Colleagues, The Whois Database is currently not answering queries, or answering them sporadically. We are aware of the outage, and are currently working on restoring service. Apologies for the inconvenience, Shane Kerr Software Engineering Manager RIPE NCC

1 1

Rückruf: Whois changes
by Erics 08 Jun '05

08 Jun '05

Schmidt, Eric möchte die Nachricht "Whois changes" zurückrufen.

1 0

Changes for abuse
by Shane Kerr 07 Jun '05

07 Jun '05

Dear Colleagues, The RIPE NCC has implemented the proposed changes to the Whois server software. We will put the new software into production on Wednesday, 2005-04-27. ***************************************************************** These changes alter the default output of the Whois server. If you need the old output, you can get it by using the "-B" and "-G" flags, like this: whois -B -G 193.0.1.17 ***************************************************************** The current implementation is different from the original proposal in this way: - INETNUM and INET6NUM object types will *not* have the "abuse-mailbox:" attribute added. The reason for not adding the "abuse-mailbox:" attribute to the INETNUM and INET6NUM object types is that there was no consensus to add these. Some people supported it and some people did not. It is easier to add attributes than to delete them. Anyone in favour of adding this attribute can attempt to create consensus within the Database Working Group. We have also implemented the proposal to change the order of objects in query results. A revised proposal is attached. As well as the above change: - It explicitly states that "trouble:" will be deprecated. - Some templates and examples were not correct, and have been fixed. -- Shane Kerr Software Manager RIPE NCC The changes we propose are: o To hide attributes that contain e-mail addresses in the default output of queries. We will also provide an option to disable this feature, o To add a new "abuse-mailbox:" attribute to PERSON, ROLE, IRT, MNTNER, and ORGANISATION objects, o To provide an option to display only key attributes and abuse contacts, o To change the IRT object template so that the "signature:" and "encryption:" attributes are no longer mandatory, o To change the behaviour of the '-c' switch in whois queries. We will announce the changes on our website. We will also contact any third-party software developers who rely on the RIPE Database for abuse contact information. You can read the minutes from the Database Working Group discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00469.html (1) Adding the "abuse-mailbox:" Attribute We will add a new attribute to the following object types: PERSON ROLE IRT ORGANISATION MNTNER This optional attribute will contain at least one e-mail address. It will tell users where to send abuse complaints or queries. (The proposed templates for the above objects are at the end of this document.) The description of the new attribute will be the same in all objects: abuse-mailbox: Specifies the e-mail address to which abuse complaints should be sent. An e-mail address as defined in RFC 2822. There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:". The "trouble:" attribute will be deprecated. As an example, see the following: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info(a)example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE trouble: Please contact trouble: abuse(a)example.com trouble: for abuse reports, not info(a)example.com nic-hdl: TESTROLE1-RIPE changed: info(a)example.com 20050101 source: RIPE We will replace this with: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info(a)example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE remarks: "trouble:" converted on 2005mmdd remarks: Please contact abuse-mailbox: abuse(a)example.com remarks: for abuse reports nic-hdl: TESTROLE1-RIPE changed: info(a)example.com 20050101 source: RIPE (2) Hiding Attributes That Contain E-Mail Addresses Finding the right e-mail address for abuse reports can be confusing. There is currently no easy way to find this information in the RIPE Database. Users often send mail to every e-mail address they see in a query result. To avoid this, we will hide all attributes that contain e-mail addresses from the default output of a whois query for an address. When a user looks up an address, the results may include the following objects: INETNUM INET6NUM ROUTE ROUTE6 ORGANISATION PERSON ROLE By default, MNTNER objects are not shown, but they are often also queried to get contact information. For each of the object types, the following attributes contain e-mail addresses: INETNUM: notify, changed INET6NUM: notify, changed ROUTE: notify, changed ROUTE6: notify, changed ORGANISATION: e-mail, notify, changed PERSON: e-mail, notify, changed ROLE: e-mail, trouble, notify, changed For each address range returned, if there is at least one "abuse-mailbox:" attribute in any of the returned objects, the attributes mentioned above will be removed from the output. If there is no "abuse-mailbox:" attribute, only "notify:" and "changed:" attributes will be filtered out. If an attribute of an object is changed, a comment will be added, to avoid confusion. Users can turn off this suppression. To make this possible, we will implement a '-B' flag. As an example: $ whois 10.0.0.10 Might currently give the following result: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm(a)ripe.net 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm(a)ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm(a)ripe.net 20050101 source: RIPE After the change, the result will be: % Note: this output has been filtered. inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE status: ALLOCATED PI mnt-by: I-MNT source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 nic-hdl: ME1-RIPE mnt-by: I-MNT source: RIPE To see the unmodified result, users should type in: $ whois -B 10.0.0.10 (3) Adding 'abuse output' Option To help authors of tools or users who are only interested in the abuse contacts for IP addresses, we will implement a brief output mode. If a user types '-b' when querying the RIPE Database, they will only see the key attributes of address ranges and the "abuse-mailbox:" attribute. This switch will also imply '-c', which requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It will only work with address space related queries. Here is an example: $ whois 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE status: ALLOCATED PI mnt-by: I-MNT mnt-irt: IRT-I changed: ripe-dbm(a)ripe.net 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm(a)ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm(a)ripe.net 20050101 abuse-mailbox: ripe-dbm-person(a)ripe.net source: RIPE So: $ whois -b 10.0.0.0 Will return: % Note: this output has been filtered. % Only primary keys and abuse contact will be visible. inetnum: 10.0.0.0 - 10.0.0.255 e-mail: ripe-dbm(a)ripe.net e-mail: ripe-dbm-person(a)ripe.net This output will not generate valid objects, and there will be no object separators. If two ranges are returned after making a query, an object separator will be inserted between groupings. Therefore, the output will look like this: inetnum: 10.0.0.0 - 10.0.0.255 e-mail: ripe-dbm(a)ripe.net e-mail: ripe-dbm-person(a)ripe.net (*) inetnum: 10.0.1.0 - 10.0.0.255 e-mail: ripe-dbm-person-2(a)ripe.net (*) Attributes marked by (*) are taken from the person object retrieved by a recursive lookup. (4) Modifications on the IRT Object We will change the template for the IRT object will be changed. You will no longer need a KEY-CERT object to create an IRT object. Currently, the template for the IRT object is: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] "signature:" and "encryption:" attributes need existing key-cert objects. The Anti-spam Working Group asked us to make these objects optional. You can read an archive of this discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00452.html The template for irt objects will be: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] encryption: [optional] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Therefore, the object below would be valid: irt: irt-someorg-zz address: address for the irt phone: +11 22 3344556 fax-no: +11 22 3344556 e-mail: contact(a)example.com admin-c: CONTACT1-RIPE tech-c: CONTACT1-RIPE auth: CRYPT-PW XXXXXXXXXXXXX mnt-by: mnt-someorg changed: someone(a)example.com 20050101 source: RIPE We will automate this process, so that help from the RIPE Database Management will no longer be necessary create IRT objects. (5) Changing the behaviour of '-c' option in whois queries Currently, the -c option requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It does not return any related IRT objects. This will change, so that -c will treat IRT objects as contacts and do recursive lookups on related IRT objects. Here is an example: $ whois -c 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info(a)example.com 20050101 source: RIPE person: TEST1-RIPE . . After the change, the result will be: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info(a)example.com 20050101 source: RIPE person: TEST1-RIPE . . irt: IRT-TEST . . (6) Modified Templates inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [inverse key] ** org: [optional] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] abuse-mailbox: [optional] [multiple] [inverse key] ** org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [inverse key] ** signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [lookup key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [inverse key] ** org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] ** upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Rows that are marked with '**' are additions to the templates.

14 18

How to create a new mntner object in a local RIPE DB installation?
by Ramarajan, Arvind, ALABS 02 Jun '05

02 Jun '05

Hi, I have a local RIPE DB installed successfully. Have also created person and role objects, however not able create mntner objects using e-mail submissions. Keep getting reply saying it should be created manually. No luck going through the documentation. Can someone please point to the right info if I have missed or let me know what manual steps need to be taken. TIA --> Arvind. Arvind Ramarajan AT&T Tier IV - Technology Insertion 732-420-2243

2 1