____________________________________________________ RIPE NCC Database Documentation A. M. R. Magee RIPE NCC Document: ripe-153 Date: 28th January, 1997. Version: 1.3 ABSTRACT This document is an introduction to the use of the RIPE Network Management Database (the "RIPE Database"). It con- tains details of how to query the database and how to create, change and delete information. It also contains instructions on authoriz- ing and authenticating changes to database objects. Items marked with an "*" character are still in production. Questions and comments about this document should be sent to . ____________________________________________________ ripe-153.txt Page 1 ripe-153 A. M. R. Magee ____________________________________________________ Acknowledgements The author wishes to acknowledge the cooperation given by the following staff at the RIPE NCC: D. Karrenberg, C. Orange, M. Kuhne, P. Caslav, C. Fletcher, E. McGuinness, R. Wilhelm and E. Willems. Copyright Declaration on the RIPE Database "Copyright (c)1992/1993/1994/1995/1996/1997 by Daniel Karrenberg and TERENA Restricted rights. Except for agreed Internet operational purposes, no part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without prior permission of the RIPE NCC on behalf of the copyright holders. Any use of this material to target advertising or similar activities are explicitly forbidden and will be prosecuted. The RIPE NCC requests to be notified of any such activities or suspicions thereof". It should be stressed that this copyright is asserted to prevent the abuse and undue exploitation of the RIPE Network Management Database. Outline of this document Software Requirements 1. Background to the RIPE Network Management Database; * Description of the objects in the database * Management of the objects 2. Using the Database * Querying the database * Creating, Updating and Deleting Objects * Authorization and authentication of changes ____________________________________________________ ripe-153.txt Page 2 ripe-153 A. M. R. Magee ____________________________________________________ * Hierarchical object protection* * Mirroring* 3. Use of the software to run a private database* Appendix * Attributes* * Objects* * TEST Database* * Glossary* * Mailing Lists * A brief history of RIPE, the NCC and the Database.* Software Requirements To access the RIPE Network Management Database, you will need one of several TCP/IP based tools, namely : * `whois' client, RIPE `whois' client * WWW, http://www.ripe.net/db/ * WAIS * Telnet * E-mail The database software uses a `whois' (RFC954) server with some special RIPE specific extensions. There- fore, a 'whois' client is generally the preferred tool for database look-ups, in particular, the RIPE version. The source code of the RIPE 'whois' client program, which runs on UNIX, can be obtained from : ftp://ftp.ripe.net/tools/ripe-whois-tools-VER- SION.tar.gz Changes to the RIPE Database can only be made by e- mail. They can not be made using the web-site. ____________________________________________________ ripe-153.txt Page 3 ripe-153 A. M. R. Magee ____________________________________________________ The RIPE database has its own interface software. A public version of this software is available at ftp://ftp.ripe.net/ripe/dbase/software This software may be used by anyone to either set up a mirror of the RIPE database or to make a private database. This software is covered by the copyright below: Copyright (c) 1997 The TERENA Association All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS; IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSE- QUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ____________________________________________________ ripe-153.txt Page 4 ripe-153 A. M. R. Magee ____________________________________________________ 1.1 The RIPE Network Management Database Purpose of the RIPE Database: One of the activities of RIPE is to maintain a database of European IP networks, DNS domains, their contact persons and IP routing policies (i.e. the RIPE Routing Registry). This data is maintained by RIPE NCC along with various other kinds of net- work management information. This database is known as the RIPE Network Management Database or more usually, the "RIPE Database". The information in the database is available to the public for agreed Internet operational purposes. This supports NIC's/NOC's all over Europe and beyond to perform their respective tasks. For example, if a user in network A cannot reach a machine in network B, then the network manager of network A could find out the technical contact per- son of network B and ask them to locate and solve the problem. The RIPE database is not a "telephone directory" or "white pages" service for European Internet users. 1.2 Description and Management of the Database Objects The RIPE Network Management Database (often called the "RIPE Database") contains records of o allocations and assignments of IP address space (the IP address registry); o domain names (the domain registry); o routing policy information (the routing reg- istry); o contact information (details of people who are responsible for the operation of networks or routers, and those who are responsible for maintaining information in the RIPE Database). Note: the information in the domain registry has no effect on operations; it is there as a convenient reference. ____________________________________________________ ripe-153.txt Page 5 ripe-153 A. M. R. Magee ____________________________________________________ Records in the RIPE Database are known as "objects". Each object describes a single entity in internet operations. This implies that information about that entity should only be contained in the corre- sponding database object and should not be repeated in other objects. The phrase "RIPE Database" is often used to refer to the interface software, rather than the information that is stored in the database. In ambiguous situa- tions, it will made clear what is being discussed at any time. Objects are composed of pairs of attributes and val- ues e.g. the "person" object is composed of the following attributes: person address phone fax-no e-mail nic-hdl remarks notify mnt-by changed source Each of these attributes has a value, e.g. person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 970114 source: RIPE Similarly, the domain object, which represents a ____________________________________________________ ripe-153.txt Page 6 ripe-153 A. M. R. Magee ____________________________________________________ range of IP addresses, has the following attributes: domain descr admin-c tech-c zone-c nserver sub-dom dom-net remarks notify mnt-by mnt-lower changed source An example of a domain object is: domain: over.ripe.net descr: Network for ripe-dbm use. descr: RIPE Network Coordination Centre descr: Kruislaan 409 descr: NL-1098 SJ Amsterdam descr: The Netherlands admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE zone-c: AMRM1-RIPE mnt-by: AMRM1-RIPE-MNT changed: ripe-dbm@ripe.net 970115 source: RIPE It may be seen that some attributes may appear more than once. Such an attribute is called "multiple". If an attribute can only appear once, it is called "single". Some attributes must be in the object; these attributes are "mandatory"; otherwise they are "optional". Some attributes are no longer used; they are known as "obsolete". The RIPE Network Management Database is not a rela- tional database (cf. SQL/ORACLE, MS Access, MS Excel). However, there is some cross-referencing of the records; e.g. if you do a look-up of a domain ____________________________________________________ ripe-153.txt Page 7 ripe-153 A. M. R. Magee ____________________________________________________ object, you will also get the details of the admin- istrative contact person (the "admin-c") and the technical contact person (the "tech-c"). [These extra look-ups may be switched off, if preferred]. The objects and their description. The types of objects stored in the RIPE database are summarized in the following table: Rg = the registry involved Object = the name of the object in RIPE Database Describes = the entity in internet operations References = indicates the relation between the objects; IP = IP address allocation and assignment Registry; D = Domain Registry R = Routing Registry All = all three registries ____________________________________________________ ripe-153.txt Page 8 ripe-153 A. M. R. Magee ____________________________________________________ +----------------------------------------------------------------------------+ | Objects in the RIPE Database | +----+------------+--------------------------------+-------------------------+ |Rg | Object | Describes | References | +----+------------+--------------------------------+-------------------------+ |All | mntner | maintainer object | person, role, mailboxes | |All | person | contact persons | mntner | |All | role | role (e.g.help desk) | person, mntner | |IP | inetnum | IP address space | person, role, mntner | |IP | inet6num | IP version address space | person, role, mntner | |D | domain | DNS domain | person, role, mntner | |R | aut-num | autonomous system (AS) | person, role, mntner | | | | (aut-num,community) | | |R | as-macro | a group of autonomous systems | person, role, | | | | mntner, aut-num | | |R | community | a community of routes that | person, role, | | | | cannot be represented by an | mntner | | | | AS or a group of AS's | | |R | route | a route being announced | aut-num, community, | | | | | mntner | | | | | | |R | dom-prefix | CLNS address space and routing | person, role, mntner | |R | inet-rtr | router name | person, role, mntner | | | limerick | poetry | person, role, mntner | +----+------------+--------------------------------+-------------------------+ The first column indicates whether the object is part of the address registry (IP), the routing reg- istry (R), the domain registry (D) or all three. The last column indicates the types of objects ref- erenced in an object of this type. It can be seen that almost all objects reference contact persons. The policies and procedures of address space assign- ment indicated in ripe-140 should be followed when an address space assignment is being entered. Simi- larly, whenever a routing policy is being entered into the routing registry, the policies of ripe-181 should be followed. As stated earlier, the RIPE Database contains three registries and contact information. These will now be discussed. ____________________________________________________ ripe-153.txt Page 9 ripe-153 A. M. R. Magee ____________________________________________________ The IP address space allocation and assignment registry The objects in the IP Registry and their functions will now be described. The inetnum object: Here is an example of an inetnum object: inetnum: 193.0.0.0 - 193.0.0.255 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: DK143-RIPE tech-c: GJG1-RIPE rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops@ripe.net changed: orange@ripe.net 960815 changed: GeertJan.deGroot@ripe.net 970110 source: RIPE The inetnum attribute contains an address range specified in dotted quad notation, which is entered in the inetnum object. For example, if an organisa- tion is assigned a /22 address set for 1024 network addresses, the assigned range [e.g. 193.1.192.0 - 193.1.195.255], is put in the "inetnum" field of the inetnum object. The precise syntax allowed is spec- ified in detail in the Appendix*. To help identify this assignment in the RIPE database, a short, but semantically meaningful name is entered in the netname field. A short descrip- tion of the organisation that uses the assigned addresses is given. The information is specified using one or more descr fields in the Network Tem- plate. If, for example, the assigned addresses will be used by the Department of Neural Surgery at Cata- tonic State University, then the department and uni- versity names may be specified in two descr fields. The ISO 3166 country code should be specified in the country field. These country codes may be found at ftp://ftp.ripe.net/iso3166-countrycodes. The full country name can be used if the code is not known. ____________________________________________________ ripe-153.txt Page 10 ripe-153 A. M. R. Magee ____________________________________________________ The admin-c and tech-c fields are used to specify the IR handle (NIC handle) for the administrative and technical contact persons, respectively. The administrative person specified in the admin-c field must be physically located at the site of the net- work. The technical person specified in the tech-c field may be a network support person located on site, but could also be a consultant that maintains the network for the organisation. In both cases, more than one person can be specified. The use of NIC handles to specify each contact person is required, as it assures each person has a unique entry in the database. If the person doesn't have an entry in the database, a unique NIC handle can be obtained using an automatic process; see Section 2.2. For security purposes, a notify field can be filled out with an e-mail address to be notified when changes are made to the database object and a mnt-by field can reference a maintainer object which desig- nates who can make changes to the object. The status field can have one of these values: ALLOCATED PA (the most common allocation type for Local IR's) ALLOCATED PI (rare for Local IR's) ALLOCATED UNSPECIFIED ASSIGNED PA ASSIGNED PI These five values are explained in Appendix*. Below is the template of the inetnum object: ____________________________________________________ ripe-153.txt Page 11 ripe-153 A. M. R. Magee ____________________________________________________ inetnum: [mandatory] [single] netname: [mandatory] [single] descr: [mandatory] [multiple] country: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] rev-srv: [optional] [multiple] status: [optional] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] mnt-lower: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] aut-sys: [obsoleted] comm-list: [obsoleted] ias-int: [obsoleted] gateway: [obsoleted] The Domain Registry: There is only one type of object in this registry; the domain object. This object represents Top Level Domain (TLD) and other domain registrations. It is also used for Reverse Delegations. The domain name is written in fully qualified format, without trailing "." . An example of a domain object is shown below: domain: over.ripe.net descr: RIPE Network Coordination Centre descr: Kruislaan 409 descr: NL-1098 SJ Amsterdam descr: The Netherlands admin-c: HC56-RIPE tech-c: AMRM1-RIPE zone-c: AMRM1-RIPE mnt-by: AMRM-TEST changed: ripe-dbm@ripe.net 970115 source: RIPE ____________________________________________________ ripe-153.txt Page 12 ripe-153 A. M. R. Magee ____________________________________________________ The template of the domain object is given below: domain: [mandatory] [single] descr: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] zone-c: [mandatory] [multiple] nserver: [optional] [multiple] sub-dom: [optional] [multiple] dom-net: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] mnt-lower: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The Routing Registry: The objects in the Routing Registry are: aut-num (autonomous system), route, as-macro (autonomous system macro), community, dom-prefix (clns [connectionless network service] address space and routing object), inet-rtr (router name). The RIPE Routing Registry was developed as part of the PRIDE project at the RIPE NCC and was based on the architecture of the RIPE database. It is, like the IP address allocation registry, a sub-set of the information in the RIPE database. The definitive document on the RIPE Routing Registry is Ripe-181. Ripe-181 became RFC1786. The aut-num (Autonomous System, AS) object: An Autonomous System (AS) is a group of IP networks operated by one or more network operators which has a single and clearly defined external routing pol- icy. An AS has a unique number associated with it which is used both in exchange of exterior routing information and as an identifier of the AS itself. Exterior routing protocols such as BGP and EGP are used to exchange routing information between AS's. ____________________________________________________ ripe-153.txt Page 13 ripe-153 A. M. R. Magee ____________________________________________________ The term AS is often confused or even misused as a convenient way of grouping together a set of net- works which belong under the same administrative umbrella even if within that group of networks there are various different routing policies. We provide the "community" concept for such use. AS's can strictly have only one single external routing policy. An example of an aut-num object is: aut-num: AS3333 descr: RIPE NCC descr: European Regional Internet Registry as-in: from AS286 120 accept ANY as-in: from AS1103 120 accept ANY [.........stuff deleted.........] as-out: to AS286 announce AS3333 as-out: to AS1103 announce AS3333 as-out: to AS1104 announce AS3333 [.........stuff deleted.........] admin-c: DK143-RIPE tech-c: GJG1-RIPE tech-c: DK143-RIPE mnt-by: AS3333-MNT changed: GeertJan.deGroot@ripe.net 970114 source: RIPE The template of the aut-num object is: aut-num: [mandatory] [single] as-name: [optional] [single] descr: [mandatory] [multiple] as-in: [optional] [multiple] as-out: [optional] [multiple] interas-in: [optional] [multiple] interas-out: [optional] [multiple] as-exclude: [optional] [multiple] default: [optional] [multiple] guardian: [optional] [single] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] advisory: [obsoleted] The route object: ____________________________________________________ ripe-153.txt Page 14 ripe-153 A. M. R. Magee ____________________________________________________ The route object is used to represent a single route injected into the Internet routing mesh. There are several important aspects of the attributes wor- thy of note. The value of the route attribute is a classless address. It represents the exact route being injected into the routing mesh. The value of the origin attribute will be an AS reference of the form AS1234 referring to an aut-num object. It represents the AS injecting this route into the routing mesh. The "aut-num" object (see above) thus referenced provides all the contact information for this route. Special cases: There can only be a single originat- ing AS in each route object. However in today's Internet sometimes a route is injected by more than one AS. This situation is poten- tially dangerous as it can create conflicting routing policies for that route and requires coordi- nation between the originating AS's. In the routing registry this is represented by multiple route objects. This is a departure from the one route (net), one AS principle of the ripe-181 routing registry. ____________________________________________________ ripe-153.txt Page 15 ripe-153 A. M. R. Magee ____________________________________________________ An example of a route object is: route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 notify: ops@ripe.net mnt-by: RIPE-NCC-MNT changed: GeertJan.deGroot@ripe.net 960812 source: RIPE The template of the route object is: route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] hole: [optional] [multiple] withdrawn: [optional] [single] comm-list: [optional] [multiple] advisory: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The as-macro object: It may be difficult to keep track of each and every new AS that is represented in the routing reg- istry. A convenient way around this is to define an `AS Macro' which essentially is a convenient way to group AS's. This is done so the maintainer of an AS object does not have to add a new AS to it's routing policy as described by the as- in and as-out attributes of their AS object. An `AS Macro' is a group of autonomous systems with the same routing policies. An AS-Macro can be used in for the "as-in" and "as-out" attributes in the aut-num object. The AS-Macro object is then used to derive the list or group of AS's. ____________________________________________________ ripe-153.txt Page 16 ripe-153 A. M. R. Magee ____________________________________________________ An example of an as-macro object is: as-macro: AS-EBONE descr: EBONE AS's as-list: AS378 AS513 AS517 AS544 AS789 AS2060 AS3334 AS3293 [.......................stuff deleted.............................] as-list: AS6703 AS6740 AS6827 AS6867 AS6765 AS5608 AS6761 AS6866 as-list: AS-TIPNET AS-BTGB AS-BTTRANSIT AS-ACONET AS-DEMON as-list: AS-TAIDE AS-TELIANET AS-TMPEBONECWIX guardian: staff@ebone.net tech-c: BC83-RIPE admin-c: BE10 mnt-by: EBONE-MNT changed: bc@sunet.se 970115 source: RIPE The template of the as-macro object is: as-macro: [mandatory] [single] descr: [mandatory] [multiple] as-list: [mandatory] [multiple] guardian: [optional] [single] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The community object: A community is a group of routes that cannot be rep- resented by an AS or a group of AS's. It is in some circumstances useful to define a group of routes that have something in common. This could be a special access policy to a supercomputer centre, a group of routes used for a specific mission, or a disciplinary group that is scattered among sev- eral autonomous systems. Also these communities could be useful to group routes for the purpose of network statistics. Communities do not have a common routing policy. Communities do not exchange routing information, since they do not represent an autonomous sys- tem. More specifically, communities do not define routing policies, but access or use policies. ____________________________________________________ ripe-153.txt Page 17 ripe-153 A. M. R. Magee ____________________________________________________ However, they can de used as in conjunction with an AS's routing policy to define a set of routes the AS sets routing policy for. An example of a community object is given below: community: HEPNET descr: High Energy Physics Network authority: HEPnet technical committee IP (HTC-IP) guardian: farrache@ccpnxt5.in2p3.fr tech-c: Gilles Farrache admin-c: Gilles Farrache changed: farrache@ccpnxt5.in2p3.fr 940222 source: RIPE The template of the community object is: community: [mandatory] [single] descr: [mandatory] [multiple] authority: [mandatory] [single] guardian: [optional] [single] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] More details on community objects may be found in ripe-181. The dom-prefix object: This object is used for ConnectionLess Network Ser- vice (CLNS) representation. ____________________________________________________ ripe-153.txt Page 18 ripe-153 A. M. R. Magee ____________________________________________________ The template of this object is: dom-prefix: [mandatory] [single] dom-name: [mandatory] [single] descr: [optional] [multiple] bis: [optional] [multiple] dom-in: [optional] [multiple] dom-out: [optional] [multiple] default: [optional] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] guardian: [optional] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] maintainer: [obsoleted] The inet-rtr object: This object represents an internet router. Contact Information The person object: The person's name is specified in full in the person field. The full postal address is specified using multiple address fields. The international tele- phone number which can be used to reach the person at work is entered in the phone field, and the fax number is entered in the fax-no field. The NIC han- dle for this person is entered in the nic-hdl field to uniquely identify this person in the database. As with the network template, a notify field can be filled out with an e-mail address to be notified when changes are made to the database object and a mnt-by field can reference a maintainer object which designates who can make changes to the object. See Section 2.3 for further details on maintainer objects. ____________________________________________________ ripe-153.txt Page 19 ripe-153 A. M. R. Magee ____________________________________________________ An example of a person object is: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 970115 source: RIPE The template of the person object is: person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] nic-hdl: [optional] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The mntner object: Objects in the RIPE database may be protected using mntner objects. The mntner (or maintainer) object contains details of who is authorised to make changes to objects and details of a process that actually verifies that the person who makes the changes is authorised to do so. ____________________________________________________ ripe-153.txt Page 20 ripe-153 A. M. R. Magee ____________________________________________________ An example of a mntner object is: mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: CRYPT-PW otpbdphttaoas remarks: This is a test mntner. notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 970115 source: RIPE Attributes used in all objects. In all objects, space is reserved to identify the person submitting these entries to the registry database. Their e-mail address must be specified in the "changed" field together with the date the tem- plate is submitted. Similarly, the "source" field is used to specify the registry database where the requester information can be found after an assignment is made. Usually, it is RIPE. Details of attributes and objects may be found in the Appendix*. There are ways of obtaining the for- mat or template of an object; these are discussed in Section 2. 1.1.2 Management of the database objects: In principle, anyone can create, change or delete objects in the RIPE Database using electronic mail. E-mail is sent to , which is an "automatic" mailbox. The entire record or object must be in the body of the message, not only the attributes to be changed. ____________________________________________________ ripe-153.txt Page 21 ripe-153 A. M. R. Magee ____________________________________________________ More than one object may be in the message, but objects must be separated by at least one blank line. An acknowledgement message will be sent to you auto- matically once the update is complete. If a syntax error in your request is detected or if special authorization is required for a particular request, you will receive an error message. You will always receive a reply. If you do not receive any reply, it implies that the mail has bounced or been lost. E-mail updates are sent an automatic mailbox which handles update requests. When mail is sent to this address it is analysed, authorization checks are performed and finally the actual updates, if appro- priate, are done. In some cases, the request must be sent to a human mailbox. For security reasons, a request to create a mntner ("maintainer") object must be sent to . However, requests to change or delete a mntner object should be sent to . If a request to create a mntner is sent to , it will be forwarded to . This will be discussed further in Section 2.3. ____________________________________________________ ripe-153.txt Page 22 ripe-153 A. M. R. Magee ____________________________________________________ Chapter 2; Database queries and updates: 2.1 Querying the RIPE Database There are five ways of querying the RIPE database: whois client, WWW, WAIS, telnet and e-mail. The choice of which one to use depends on what resources are available at your site and which one your find the most appropriate. Each way of querying the database will now be explained. 2.1.1 RIPE whois client: Searching for the names of database objects; If you wish to look up objects in the RIPE database, you must use special search keys. A full list of the search keys is given below: OBJECT KEYS ----------------------------------------------------------------------------------- aut-num AS number (e.g. AS3333) as-macro as-macro name (e.g. AS-EBONE) community community name (e.g. HEPNET) domain domain name (e.g. over.ripe.net) inetnum range of IP addresses e.g 193.0.0.0 - 193.0.0.255; network name e.g.RIPE-NCC inet6num range of IP version 6 addresses or network name person a person's name or NIC-handle or e-mail address in RFC822 format. e.g. Ambrose Magee or AMRM1-RIPE or ambrose@ripe.net clns object domain-prefix domain-prefix, domain-name inet-rtr internet router name (e.g. limerick name of limerick mntner name of mntner object e.g. AMRM1-RIPE-MNT route internet route e.g. 193.0.0.0/24 role the name, the NIC-handle or the e-mail address (in RFC822 format) of a role object; e.g. RIPE NCC ____________________________________________________ ripe-153.txt Page 23 ripe-153 A. M. R. Magee ____________________________________________________ If you also want to search for other strings in the objects, you can use the WAIS interface; however it doesn't support the special options that are pro- vided in the RIPE 'whois' interface. The RIPE whois client has several options, which may be used either alone or in combination. The following is a list, in alphabetical order, of the available options, which are explained in more detail below. Option Function ------------------------------------------------------------------------------ -a search all databases -F fast raw output (implies -Fr) -h search alternate server -i inverse look-up -k used with the telnet interface -L find all Less specific matches -m find first level More specific matches -M find all More specific matches -p connect to other port than the default whois port -r turn off recursive lookups -s search databases with source "source" -S tell server to leave out "syntactic sugar" -t requests template for object of type "type" -T only look for objects of type "type" -HELP gives a copy of the current `HELP & HOWTO' document. A very useful option is "-h", which allows you to connect directly to the server at the RIPE NCC or to a "mirror" of the RIPE database elsewhere. - Example: $ whois -h whois.ripe.net AMRM1-RIPE -a option: Example: [an-lar] $ whois -h whois.ripe.net -a AMRM1-RIPE The following databases may be queried in this way: ____________________________________________________ ripe-153.txt Page 24 ripe-153 A. M. R. Magee ____________________________________________________ RIPE, RADB, INTERNIC, ANS, MCI, CANET, APNIC -F option: This option generates an output quickly, but with the abbreviated form of the attributes. Example: [an-lar]$ whois -h whois.ripe.net AMRM1-RIPE gives person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM-RIPE-MNT changed: ambrose@ripe.net 970115 source: RIPE However, [an-lar]$ whois -F -h whois.ripe.net AMRM1-RIPE gives *pn: Ambrose Magee *ad: RIPE Network Co-ordination Centre (NCC) *ad: Kruislaan 409 *ad: NL-1098 SJ Amsterdam *ad: The Netherlands *ph: +31 20 592 5065 *fx: +31 20 592 5090 *em: ambrose@ripe.net *nh: AMRM1-RIPE *ny: ambrose@ripe.net *mb: AMRM-RIPE-MNT *ch: ambrose@ripe.net 970115 *so: RIPE -i option: This option allows you to do reverse or inverse look-ups of particular combinations of attributes and objects. ____________________________________________________ ripe-153.txt Page 25 ripe-153 A. M. R. Magee ____________________________________________________ The attributes which can be used are: admin-c, tech-c, zone-c; notify; origin; mnt-by; author. The syntax of the usage is: whois -i Examples of how the "-i" option is used are now given: * whois -i admin-c,tech-c,zone-c [an-lar]$ whois -h whois.ripe.net -i admin-c,tech- c,zone-c AMRM1-RIPE finds all objects which cite AMRM1-RIPE as an admin- c or a tech-c or a zone-c. inetnum: 193.0.128.0 - 193.0.128.255 netname: BORK-NET descr: Test Allocation descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: AMRM1-RIPE status: ASSIGNED PA notify: orange@ripe.net changed: orange@ripe.net 960821 source: RIPE person: Ambrose Magee [.......stuff deleted.......] Any one or more of the three attributes admin-c, tech-c and zone-c may be used. Note that if "Ambrose Magee" was used, no objects would be found as "Ambrose Magee" is not used anywhere in an admin- c, tech-c or a zone-c attribute. ____________________________________________________ ripe-153.txt Page 26 ripe-153 A. M. R. Magee ____________________________________________________ * whois -i notify You can also find all objects which have a particu- lar e-mail address in their "notify" attribute; Example: [an-lar]$ whois -h whois.ripe.net -i notify ambrose@ripe.net finds all objects which have ambrose@ripe.net in their notify attribute. mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: MAIL-FROM Ambrose.Magee@ripe.net auth: MAIL-FROM ripe-dbm@ripe.net remarks: This is a test mntner. notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960815 changed: ambrose@ripe.net 960930 source: RIPE person: Ambrose Magee [.......stuff deleted.......] * whois -i origin Example: [an-lar]$ whois -h whois.ripe.net -i origin AS3333 finds all route objects which specify AS3333 as their origin. ____________________________________________________ ripe-153.txt Page 27 ripe-153 A. M. R. Magee ____________________________________________________ route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 notify: ops@ripe.net mnt-by: RIPE-NCC-MNT changed: GeertJan.deGroot@ripe.net 960812 source: RIPE route: 193.0.0.0/23 descr: RIPE-NCC origin: AS3333 notify: ops@ripe.net mnt-by: RIPE-NCC-MNT changed: GeertJan.deGroot@ripe.net 960812 source: RIPE * whois -i mnt-by Example [an-lar] $ whois -h whois.ripe.net -i mnt-by AMRM1-RIPE-MNT finds all objects which are maintained by AMRM1-RIPE-MNT. (See Section 2.3 for details on mntner objects). * whois -i author Example: [an-lar]$whois -h whois.ripe.net -i author AMRM1-RIPE finds all limericks written by by AMRM1-RIPE; The "-r" option: All the above options do recursive look-ups i.e. they will look-up any person objects associated with admin-c, tech-c, zone-c or author attributes. To disable this recursive look-up, use the "-r" option. This may be used with the other options, including "-i". ____________________________________________________ ripe-153.txt Page 28 ripe-153 A. M. R. Magee ____________________________________________________ Example: [an-lar]$ whois -h whois.ripe.net -r -i admin- c,tech-c,zone-c AMRM1-RIPE Note that the "-r" flag must precede the "-i" flag and the arguments. -k option: This is used in the telnet interface. See Section 2.1.4(b) -L option: Sometimes when doing a look-up on an inetnum object, you may wish to find the "next objects up" in the hierarchy i.e. all less specific matches; e.g. [an-lar]$ whois -h whois.ripe.net -r 193.1.0.0/16 inetnum: 193.1.0.0 - 193.1.255.255 netname: IE-HEANET-193-1 descr: DELEGATED BLOCK descr: Provider Local Registry descr: HEAnet country: IE admin-c: MN131 tech-c: MN131 mnt-by: RIPE-NCC-HM-MNT changed: roderik@ripe.net 950315 source: RIPE Now compare the above with the output of the follow- ing: [an-lar]$ whois -h whois.ripe.net -r -L 193.1.0.0/16 gives ____________________________________________________ ripe-153.txt Page 29 ripe-153 A. M. R. Magee ____________________________________________________ inetnum: 193.1.0.0 - 193.1.255.255 netname: IE-HEANET-193-1 descr: DELEGATED BLOCK descr: Provider Local Registry descr: HEAnet country: IE admin-c: MN131 tech-c: MN131 mnt-by: RIPE-NCC-HM-MNT changed: roderik@ripe.net 950315 source: RIPE inetnum: 193.0.0.0 - 193.255.255.255 netname: EU-ZZ-193 descr: European Regional Registry descr: Europe country: EU admin-c: DK58 tech-c: DK13-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 960123 source: RIPE In other words, the inetnum object which "includes" IE-HEANET-193-1, is also found. The same process is implemented for route objects, but not for domain objects. There is no "-l" option. The default behaviour of the database is to find exactly the object you want or first less specific match (for inetnum and route objects). -m option: This option allows you to look-up all those objects which are one level more specific than what you have given in your query. In the case of inetnum objects, this means that you can lookup all those inetnum objects which are the "children" of the inetnum object found by an exact match i.e. the first level more specific match. Example: [an-lar]$ whois -h whois.ripe.net -r 193.1.0.0/16 ____________________________________________________ ripe-153.txt Page 30 ripe-153 A. M. R. Magee ____________________________________________________ inetnum: 193.1.0.0 - 193.1.255.255 netname: IE-HEANET-193-1 [.......stuff deleted.......] But, [an-lar]$ whois -h whois.ripe.net -r -m 193.1.0.0/16 finds 86 objects; i.e. there are 86 objects which are directly within the range of IP addresses given by 193.1.0.0 - 193.1.255.255. -M option: Some of the objects found by a "-m" look-up have "children" themselves; i.e. there are objects directly within the range of IP addresses specified by the objects found by a "-m" look-up. These objects may be found by a "-M" look-up. Example: [an-lar]$ whois -h whois.ripe.net -r -M 193.1.0.0/16 finds 97 objects. -p option: Normally, when you do a "whois" query, you connect to port 43 of the server which you specified with the "-h" option. However, there are occasions when you wish to connect to a port different from the default port. E.g., if you had a private database, with a whois daemon of its own, you could connect to it. [an-lar]$ whois -h localhost -p 4327 connects to port 4327 on the localhost. -s option: The RIPE database contains objects that are from other databases. This is indicated by the "source" attribute in each object. The sources used in the RIPE database are RIPE, RADB, INTERNIC, ANS, MCI, CANET and APNIC. Not every object type may be found using a source other than RIPE. Normally, only inetnum and aut-num objects may be found using non- ____________________________________________________ ripe-153.txt Page 31 ripe-153 A. M. R. Magee ____________________________________________________ RIPE sources. Example: [an-lar]$ whois -h whois.ripe.net -s INTERNIC AS3333 gives aut-num: AS3333 descr: part of AS block AS3154 - AS3353 admin-c: 3353 remarks: this AS number is assigned by the InterNIC remarks: please query whois.internic.net for more information changed: ripe-dbm@ripe.net 970103 source: INTERNIC -S option: This option tells the server to leave out text which is only added to make aut-num objects readable by humans. This text is called "Syntactic Sugar". Example: [an-lar]$ whois -h whois.ripe.net -r AS3333 gives aut-num: AS3333 descr: RIPE NCC descr: European Regional Internet Registry as-in: from AS286 120 accept ANY [........stuff deleted ........] as-out: to AS286 announce AS3333 [........stuff deleted ........] Compare with the output of [an-lar]$ whois -h whois.ripe.net -r -S AS3333 aut-num: AS3333 descr: RIPE NCC descr: European Regional Internet Registry as-in: AS286 120 ANY [........stuff deleted ........] as-out: AS286 AS3333 [........stuff deleted ........] ____________________________________________________ ripe-153.txt Page 32 ripe-153 A. M. R. Magee ____________________________________________________ The "-t" option: This option allows you to obtain a template of any type of object that is accepted by the RIPE database. You may specify either the full or the abbreviated name of the object as follows: Full name Abbreviation -------------------------- aut-num an as-macro am community cm domain dn inetnum in inet6num i6 persons pn dom-prefix dp inet-rtr ir limerick li mntner mt route rt role ro -------------------------- Example: [an-lar]$ whois -h whois.ripe.net -t person ____________________________________________________ ripe-153.txt Page 33 ripe-153 A. M. R. Magee ____________________________________________________ person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] nic-hdl: [optional] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] [an-lar]$ whois -h whois.ripe.net -t pn gives the same output. The "-T" option: If you know the type of the object for which you are looking, you can restrict the search to that type only. This option is useful when different types of object have the same KEYS. Example: [an-lar]$ whois -h whois.ripe.net -r 193.0.0.0/24 gives ____________________________________________________ ripe-153.txt Page 34 ripe-153 A. M. R. Magee ____________________________________________________ inetnum: 193.0.0.0 - 193.0.0.255 netname: RIPE-MEETING descr: RIPE Meeting Terminal Room descr: Amsterdam, Netherlands country: NL admin-c: GJG1-RIPE tech-c: GJG1-RIPE changed: GeertJan.deGroot@ripe.net 970110 source: RIPE route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 notify: ops@ripe.net mnt-by: RIPE-NCC-MNT changed: GeertJan.deGroot@ripe.net 960812 source: RIPE cf. the output of [an-lar] $ whois -h whois.ripe.net -r -T inetnum 193.0.0.0/24 inetnum: 193.0.0.0 - 193.0.0.255 netname: RIPE-MEETING descr: RIPE Meeting Terminal Room descr: Amsterdam, Netherlands country: NL admin-c: GJG1-RIPE tech-c: GJG1-RIPE changed: GeertJan.deGroot@ripe.net 970110 source: RIPE In this situation, only the inetnum object is found. Note that when using the "-T" option, the abbrevi- ated form of the object names may be used; e,g, "in" can be used instead of "inetnum". -HELP option: The output of this option is an up-to-date copy of the "HELP & HOWTO" document for the RIPE database. Example: [an-lar]$ whois -h whois.ripe.net HELP ____________________________________________________ ripe-153.txt Page 35 ripe-153 A. M. R. Magee ____________________________________________________ gives Document: HELP & HOWTO use the RIPE database Version: 970106 Author: David Kessens E-mail: ripe-dbm@ripe.net Introduction This document describes how to access and cre- ate/change/delete your data in the RIPE (or test!) database. Also included is a section with hints and tips. At the end of the document is a chapter with pointers to more extensive documentation. [...stuff deleted...] To summarise, the syntax of the usage of the "whois" command is as follows: Usage: whois [-aFrSv] [-h host] [-s source] [-T type] [-L|-m|-M] Using non-RIPE `whois' clients: Please note that most of the options are NOT under- stood by non RIPE 'whois' client programs. Some- times the following work-around will work : Instead of [an-lar] $ whois -h whois.ripe.net -T person AMRM1-RIPE you can use [an-lar] $ whois -h whois.ripe.net "-T person AMRM1-RIPE" 2.1.2 WWW: http://www.ripe.net/db/ ____________________________________________________ ripe-153.txt Page 36 ripe-153 A. M. R. Magee ____________________________________________________ This is a web-based interface to the whois server; therefore you can only do a search on the KEYS listed in Section 2.1.1 2.1.3 WAIS: You should create a directory with a name like "wais-sources". In this directory, you can put all source files for WAIS applications. You should then create a file with a name like "ripe-database.src". The contents of the file should be this: (:source :version 3 :ip-name "wais.ripe.net" :tcp-port 210 :database-name "ripe-database" :cost 0 :cost-unit :free :maintainer "ripe-dbm@ripe.net" :description "This WAIS database contains the RIPE Network Management Database which is also available at: ftp://ftp.ripe.net/ripe/dbase") Now at your command line prompt, type "swais". You will now see a menu ("Source Selection") and a list of all the sources in your wais-sources directory. Follow the instructions. Note that you can search for any keyword, including addresses and telephone numbers. The "q" character allows to close the process: "?" gives you a list of all the keywords. 2.1.4 telnet There are currently two ways to telnet to the RIPE Database. (a) The first is to simply telnet "whois.ripe.net" and enter one of the options listed in Section 2.1.1(b), followed by one of the KEYS listed in Sec- tion 2.1.1(a). You are not required to type "whois". ____________________________________________________ ripe-153.txt Page 37 ripe-153 A. M. R. Magee ____________________________________________________ Example: [an-lar]$ telnet whois.ripe.net gives Trying 193.0.0.194... Connected to dbase.ripe.net. Escape character is '^]'. ******************************************************************** * RIPE NCC * * Telnet-Whois Interface to the RIPE Database * * Most frequently used keys are: IP address or pre- fix (classless), * network name, persons last, first or complete name, NIC handle, * and AS. * * Use 'help' as key to get general help on the RIPE database. * Contact for further help or to report problems. ******************************************************************** Enter search key [q to quit]: Ambrose Magee person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) [....stuff deleted....] Enter search key [q to quit]: -T route 193.0.0.0/23 route: 193.0.0.0/23 [....stuff deleted....] Enter search key [q to quit]: q Connection closed by foreign host. [an-lar]$ (b) The second is to telnet to "whois.ripe.net 43". This is a very basic interface to the whois server. You do not type "whois" in your query; you only type the whois option (e.g. "-r") and then the KEY. Example: [an-lar] $ telnet whois.ripe.net 43 gives ____________________________________________________ ripe-153.txt Page 38 ripe-153 A. M. R. Magee ____________________________________________________ Trying 193.0.0.194... Connected to dbase.ripe.net. Escape character is '^]'. -T rt 193.0.0.0/23 route: 193.0.0.0/23 [....stuff deleted....] Connection closed by foreign host. The connection is closed immediately after one query. If you wish to do more than one look-up dur- ing the same telnet session, you should use the "-k" option as shown: Example: Trying 193.0.0.194... Connected to dbase.ripe.net. Escape character is '^]'. -k -T rt 193.0.0.0/24 % Server is running at low priority for -M, -m and -k queries route: 193.0.0.0/24 descr: RIPE-NCC [....stuff deleted....] -r -T in 193.0.0.0/24 inetnum: 193.0.0.0 - 193.0.0.255 netname: RIPE-NCC [....stuff deleted....] -k Connection closed by foreign host. [an-lar] $ Note: "-k" is typed first, before any other charac- ters. Typing "-k" alone closes the session. 2.1.5 E-mail: (a) Send mail to with in the body text: ____________________________________________________ ripe-153.txt Page 39 ripe-153 A. M. R. Magee ____________________________________________________ whois KEY, where KEY is one of the KEYS from Section 2.1.1(a). "whois" must be at the beginning of a new line in the body of the message. Separate queries must be on separate lines. The "Subject:" line will not be interpreted. Example: An e-mail with the following in the body of the mes- sage whois 193.0.0.0/24 whois AMRM1-RIPE gets the following mail: > Dear mail whois user, > > The requested RIPE database queries gave the fol- lowing results: > > ------ > Query: 193.0.0.0/24 > > > inetnum: 193.0.0.0 - 193.0.0.255 > netname: RIPE-NCC > [.....stuff deleted.....] > > route: 193.0.0.0/24 > descr: RIPE-NCC > [.....stuff deleted.....] > > ------ > Query: AMRM1-RIPE > > > person: Ambrose Magee > address: RIPE Network Co-ordination Centre (NCC) > [.....stuff deleted.....] > > Regards > The RIPE NCC whois service (e-mail department) Important ! ____________________________________________________ ripe-153.txt Page 40 ripe-153 A. M. R. Magee ____________________________________________________ * This method doesn't support the whois options ! * Separate queries must be on separate lines. 2.1.6 Means of querying other databases To query the InterNIC database, use [an-lar] $ whois -h whois.internic.net All the databases that are mirrored by the RIPE NCC may be directly queried in this way. The databases that may be mirrored are: RIPE, RADB, INTERNIC, ANS, MCI, CANET, APNIC ____________________________________________________ ripe-153.txt Page 41 ripe-153 A. M. R. Magee ____________________________________________________ 2.2 Creating, Updating and Deleting an Object: 2.2.1 Creating a new object: To create a new object, follow this procedure: * get the template; * modify the template; * send the object to the appropriate mailbox i.e. for new autonomous system objects, for new mntner objects and for all other objects. (1) Getting the template: Use whois -t . See Section 2.1.1 for details on how to obtain the template of any object. example [spoor] $ whois -h whois.ripe.net -t person gives person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] nic-hdl: [optional] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] (2) modification of the template; (i) Now fill in the appropriate details in the tem- plate. Do not leave attributes with values such as "[optional]", or "[multiple]". (ii) Attributes which are mandatory should .B not .R be empty. Otherwise, the update will be rejected by the database software. ____________________________________________________ ripe-153.txt Page 42 ripe-153 A. M. R. Magee ____________________________________________________ (iii) Attributes which are optional may be left empty, but they will be removed by the database software. Example: person: Ambrose Magee address: RIPE NCC Network Co-ordination Centre [.....stuff deleted.....] phone: +31 20 592 5065 fax: e-mail: ambrose@ripe.net [.....stuff deleted.....] The empty attribute "fax" will be deleted by the database software. Attributes which are described in the template as "single" must be on only one line. Attributes which are described as "multiple" may be on more than one line, but the attribute name must be at the beginning of each line. The "address" attribute in the person object is an example of an attribute that may be multiple. person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands [.....stuff deleted.....] (iv) If you are completing a person template or want to reference a person in an another object, you should use a RIPE handle ('nic-hdl:'). You can also use NIC handles from other registries such as the InterNIC if you are also registered there. NIC-han- dles will give you a unique identifier attached to a person which you can use as a reference. This avoids problems with different persons having the same name. You can get yourself a RIPE NIC-handle by putting the following in the NIC handle field: nic-hdl: AUTO-1 ____________________________________________________ ripe-153.txt Page 43 ripe-153 A. M. R. Magee ____________________________________________________ OR nic-hdl: AUTO-1YourInitials The second case advises the database software to use YourInitials (no more then 4 characters) for build- ing the NIC handle while the first case asks the database software to find the initials itself. You can use the same identifiers (AUTO-1 or AUTO-1YourInitials) in the same update message in other objects as a reference. The database software will then fill in the freshly assigned NIC handles in the objects. Note that you can also use other numbers (example: AUTO-2) so that you can update more person objects and objects that reference the persons in one E-mail message. Example: domain: perl.com admin-c: AUTO-1 tech-c: AUTO-2 [ ... stuff deleted ...] person: Ambrose Magee nic-hdl: AUTO-1 [ ... stuff deleted ...] person: Larry Wall nic-hdl: AUTO-2 [ ... stuff deleted ...] N.B. The same rules apply when obtaining a NIC-han- dle for a role object. (iv) Put today's date and your e-mail address in the "changed" attribute. The format of the date must be YYMMDD. (v) use of "mnt-by" attribute; You can protect your objects with maintainer objects by adding a `mnt-by:' attribute. For some objects this is even mandatory. Put the name of the main- tainer object in the "mnt-by" field Example: ____________________________________________________ ripe-153.txt Page 44 ripe-153 A. M. R. Magee ____________________________________________________ person: Ambrose Magee [....stuff deleted....] mnt-by: AMRM-MNT [.....stuff deleted.....] More information on maintainer objects may be found in Section 2.3. (vi) use of the keywords "NEW" and "ASSIGN"; You can ensure that the database will only accept your object if it is not already in the database by using the keywords "NEW" and "ASSIGN". Put "NEW" in the `Subject' line of your e-mail if you want the database to only accept new objects. Use the keyword "ASSIGN" if you want the database to only accept new inetnum objects. N.B. at the moment, these keywords are case insensi- tive. Avoid putting strings such as "Old person object with new address" or "Re-assign address space" in your `Subject' line. (3) send the object to the appropriate mailbox. : is an automatic mailbox and all e-mails that create, update or delete objects (see above for exceptions) should be sent to this address. If you require a detailed acknowledgement, put the keyword "LONGACK" in the `Subject' line of your e- mail. You will always receive an acknowledgement, even if "LONGACK" is not in the `Subject' line. If you do not receive an acknowledgement, the reason could be that your e-mail address is unknown and therefore the acknowledgement mail has bounced or has been lost. : Questions and bug reports should be sent to . You are recommended to send as much ____________________________________________________ ripe-153.txt Page 45 ripe-153 A. M. R. Magee ____________________________________________________ information as possible. 2.2.2 Updating an existing object: How to update an existing object This is done by sending in the new object. Probably the easiest way to do this is to get a copy of the old object, change or add the fields you want to change or add, and then put a new 'changed:' attribute in the object. Here are the steps in more detail: (1) Get a copy of the existing object; you can do this using whois -h whois.ripe.net >Temporary- File Example: [spoor] $ whois -h whois.ripe.net AMRM1-RIPE > update-file (2) Load the TemporaryFile into your favorite editor and make your changes or additions to the object. It is recommended to use NIC handles instead of the person names for references to person objects to guarantee that your object points to a single per- son. See Section 2.2.1 for more information. If you are updating a person or role object with a new or different NIC handle, or if you are updating a route object with a new or different origin, please note: it is wise to delete the old person, role or route object before adding the new objects for the follow- ing reasons: (a) the database will treat two person objects with the same name but with different NIC handles, as different objects; (b) the database will treat two person objects with the same name as different objects, if one object has a NIC-handle, but the other does not; (c) the database will treat route objects with the same "prefix length" representation, but with dif- ferent origins as different route objects; (d) the database handles role objects in the same way as it handles person objects. ____________________________________________________ ripe-153.txt Page 46 ripe-153 A. M. R. Magee ____________________________________________________ If you do not delete the old objects first, then the database will see the old and new objects as differ- ent objects and the update request will be treated as the creation of a new object instead of an update of the old object. The database will however recog- nize that a person object is an update if the only difference between the old and new object is that the old object did not have a NIC handle. (3) Add a "changed" attribute. This attribute has the following syntax : changed: E-mailAddress Date where 'E-mailAddress' is an RFC822 E-mail address specifying who made the change and 'Date' is the date of the change in either YYYYMMDD or YYMMDD for- mat. (4) Send your message to . (5) You will receive an acknowledgement. If you send in an object that is identical to one that is already in the database, the acknowledgement message will say "NOOP" meaning "NO OPeration"; i.e. the object in the database is not modified. 2.2.3 Deleting an object: This is done by sending in the whole object just like an update and adding a special attribute, 'delete', to it: delete: It is recommended that the reason for deleting the object be put as the value of the delete attribute. ____________________________________________________ ripe-153.txt Page 47 ripe-153 A. M. R. Magee ____________________________________________________ Example: person: Ambrose Magee address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM2-RIPE notify: ambrose@ripe.net changed: ambrose@ripe.net 970110 source: RIPE delete: Duplicate person object. The deletion is only accepted if the object in the message is .B exactly very careful when deleting person or role objects unless you are sure that the person or role object is not referenced by other objects. You can find objects that reference a certain person by doing a '-i' query; see Section 2.1.1. Example: [spoor] $ whois -h whois.ripe.net -r -i tech- c,admin-c,zone-c AMRM1-RIPE Some people might have used their name as a refer- ence instead of their NIC-handle, so you should also do a look-up on that. If you're not sure that you were the only one refer- encing a certain person object, do NOT delete that person object. It will not affect the database very much if there are some obsolete person objects. Authorization, notification and acknowledgement mes- sages for deletes are handled exactly the same way as for ordinary updates. 2.2.4 Warning and Error messages: The syntax of all objects sent to is rigorously checked. Acknowledge- ment messages are generated by these syntax checks. (a) You will always receive an acknowledgement that your update has been received. ____________________________________________________ ripe-153.txt Page 48 ripe-153 A. M. R. Magee ____________________________________________________ (b) If there are no mistakes in your update, you will receive an acknowledgement message saying "No errors were found in your update". (c) Minor, but not fatal mistakes will be corrected and the object will be accepted into the database. The acknowledgement message will indicate what cor- rection was made. Example: suppose this object is sent to . person: Ambrose Magee [.....stuff deleted.....] changed: ambrose@ripe.net The following warning message would be generated: WARNING: added current date to "changed" field. (d) Fatal mistakes will .B not .R be corrected and the object will .B not .R be accepted into the database. An acknowledgement message will be sent, which will identify the error. Example: suppose this object is sent to . ____________________________________________________ ripe-153.txt Page 49 ripe-153 A. M. R. Magee ____________________________________________________ route: 193.0.0.139/32 descr: x1.ripe.net origin: AS3333 changed: ambrose@ripe.net 961221 source: RIPE The following warning message would be generated: -------------------------------------------------------- Update FAILED: [route] 193.0.0.139/32 route: 193.0.0.139/32 descr: x1.ripe.net origin: AS3333 notify: ambrose@ripe.net changed: ambrose@ripe.net 961221 source: RIPE *ERROR*: mandatory field "mnt-by" missing Objects that just generated a WARNING have been updated as shown. Objects that generated an *ERROR* have NOT been updated as requested. Please re-submit corrected objects. ------------------------------------------------------------- (e) If you have any questions about any error mes- sages, you may send e-mail to . This mailbox is checked regularly. Please send as much information as possible. ____________________________________________________ ripe-153.txt Page 50 ripe-153 A. M. R. Magee ____________________________________________________ 2.3 Object Protection: Authorization and authentication: "Authorization" indicates only who has the authority to change database objects, but does not check that it is that person who is making the changes. "Authentication" actually verifies that the person who is making the changes is authorised to do so. 2.3.1. The "mntner" object: (a) This is an object which can be used to notify you of any changes to your objects and to allow only certain individuals to change your objects. The mntner object contains information on contact per- sons and on authentication and notification details. The mntner object is used every time a database object with a "mnt-by" attribute is created, updated or deleted to determine whether or not the origina- tor of the update request is authorised to make the update. Each mntner object should have an unique name. From now on, "mntner" and "maintainer" will be used interchangeably. Sometimes, the word "maintainer" refers to the human being referenced in the "mnt-nfy" attribute of the "mntner" object. In this document, "mntner" refers to the object and "maintainer" refers to the person. Adding a new mntner object must be authorised manu- ally by RIPE NCC staff. Details are given later. 2.3.2 Functionality: (i) Individual Object Protection: You can protect any object with a mntner object. All you have to do is include a "mnt-by" attribute in your object. For some objects, a "mnt-by" attribute is mandatory. The value of the "mnt-by" attribute is a mntner object which details of how changes to the object ____________________________________________________ ripe-153.txt Page 51 ripe-153 A. M. R. Magee ____________________________________________________ are to be authorised. Example: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Kingdom of the Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 961220 source: RIPE The "mnt-by" attribute in the above object refers to this mntner object: mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: MAIL-FROM Ambrose.Magee@ripe.net remarks: This is a test mntner. notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960815 changed: ambrose@ripe.net 960930 source: RIPE You can have more than one "mnt-nfy" attribute in a mntner object. Multiple mntner objects can be ref- erenced in objects by separating them with blank spaces or by using multiple mnt-by attributes per object. ____________________________________________________ ripe-153.txt Page 52 ripe-153 A. M. R. Magee ____________________________________________________ Example: person: Ambrose Magee [.....stuff deleted.....] mnt-by: AMRM1-RIPE-MNT RIPE-DBM-MNT [.....stuff deleted.....] or person: Ambrose Magee [.....stuff deleted.....] mnt-by: AMRM1-RIPE-MNT mnt-by: RIPE-DBM-MNT [.....stuff deleted.....] In this case all maintainers referenced are equally authorised to make changes to the object. When responding to queries, the RIPE whois server will not automatically give the associated mntner object that is referenced in the object for which you asked. i.e. you must look up the mntner object separately. Whenever a change to an object is attempted, the mnt-by attribute of the current database object is examined. The object may only be updated or deleted according to the authorisation scheme described in the associated mntner object. See Section 2.3.3. (ii) Notification of (Successful) Changes to objects that are protected by a mntner object: The "notify" attribute can be included in every object. It contains an e-mail address to which noti- fications of changes to the object itself will be sent. It is possible to put a "notify" attribute in all your objects. However, if the notify e-mail address is changed, then every object with a notify attribute that references that e-mail address will have to be updated. A more efficient approach is to include a "mnt-by" attribute in all your objects. This attribute will reference a mntner object, which itself has a "mnt- nfy" (maintainer notify) attribute. The value of this attribute is an e-mail address to which a noti- fication will be sent if any object maintained by ____________________________________________________ ripe-153.txt Page 53 ripe-153 A. M. R. Magee ____________________________________________________ this mntner object is added, updated or deleted. The functionality is exactly the same as if a "notify" attribute had been defined in the object. Specifying it here has the advantage that any changes of the address affect only one object. Whenever a change to an object is attempted the mnt- by attribute of the current database object is exam- ined. If there is no mnt-by attribute, the update always proceeds causing any notifications specified in notify attributes of the object. It is also a per- fectly legitimate authorisation model for those objects that do not need sophisticated authorisa- tion. Also we would like to stress that using stronger authorisation requires timely processing of update requests. An unresponsive maintainer prevent- ing others from making updates frequently is a worse solution than having no authorisation at all. If the update is originated by a maintainer refer- enced in a mnt-by attribute, the update also pro- ceeds causing the necessary notifications. There are various methods to authenticate the origin of an update request. These can be configured in the mntner object as described in Section 2.3.3. If a new object with a mnt-by attribute is added to the database or a mnt-by attribute is added to an object that previously had no such attribute, the authorisation step is performed on the maintainer to be added. If a database object has both a "notify" attribute and a "mnt-by" attribute, then two notification mes- sages will be generated. If both notifications are to be sent to the same e-mail address, then only one e-mail is sent, but it will contain two identical parts. E.g. Dear Colleague, This is to notify you that some object(s) in the RIPE Database which you either maintain or are listed as to-be-notified have been added, deleted or changed. The objects below are the old and new entries for these objects in the database. In case of DELETIONS, ____________________________________________________ ripe-153.txt Page 54 ripe-153 A. M. R. Magee ____________________________________________________ the deleted object is displayed. NOOPs are not reported. The update causing these changes had the following mail headers: - From: Ambrose Magee - Subject: LONGACK - Date: Tue, 17 Dec 1996 10:36:47 +0100 (MET) - Msg-Id: <199612170936.KAA10058@kantoor.ripe.net> RIPE Database Notification Department --- ____________________________________________________ ripe-153.txt Page 55 ripe-153 A. M. R. Magee ____________________________________________________ PREVIOUS OBJECT: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose.magee@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960920 changed: ambrose@ripe.net 961001 changed: ambrose@ripe.net 961217 source: RIPE REPLACED BY: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Kingdom of the Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose.magee@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960920 changed: ambrose@ripe.net 961001 changed: ambrose@ripe.net 961217 source: RIPE --- PREVIOUS OBJECT: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose.magee@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960920 changed: ambrose@ripe.net 961001 changed: ambrose@ripe.net 961217 source: RIPE ____________________________________________________ ripe-153.txt Page 56 ripe-153 A. M. R. Magee ____________________________________________________ REPLACED BY: person: Ambrose Magee address: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Kingdom of the Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose.magee@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960920 changed: ambrose@ripe.net 961001 changed: ambrose@ripe.net 961217 source: RIPE NOOP means "NO OPeration" i.e. the object was not changed. (iv) Notification of unauthorised attempts to change objects protected by a mntner: Any request to change an object protected by a mnt- ner must first satisfy the authorisation scheme given in the mntner. If the request does not sat- isfy these scheme, then it is forwarded to the mail- box given in the "upd-to" attribute of the mntner object. Whoever attempted the update is also noti- fied that this has occurred. No other notifications are sent in this case. There is another use of the mailbox specified in the "upd-to" attribute. If a person wishes to change an object, but is not authorised to do so, then the update should be sent to this mailbox. If an update is not authorised and no appropriate maintainer can be identified the request will be forwarded to the RIPE NCC for action. 2.3.3 Authorization schemes: This is specified using the "auth" attribute of the mntner object. The required scheme is specified ____________________________________________________ ripe-153.txt Page 57 ripe-153 A. M. R. Magee ____________________________________________________ here. Example: mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net auth: CRYPT-PW qlfichzrkkwgm remarks: This is a test mntner. notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 970115 source: RIPE There are three schemes; NONE, MAIL-FROM and CRYPT-PW The format is: The scheme-ids currently defined are: NONE, MAIL- FROM and CRYPT-PW. The auth-info is additional information required by a particular scheme. When more than one auth attribute is specified any of them can be used alternatively for authentication of updates, i.e. specifying NONE and others does not make much sense. The auth attribute is not pro- tected information in any way; it is returned nor- mally like any attribute by the whois server and available in stored copies of the database. The strength of an authentication scheme thus has to lie in the scheme itself and cannot be based on the obscurity of the auth attribute or on keeping this information secret. It is very difficult to keep the information confidential and thus the RIPE NCC cannot take this responsibility. The "NONE" scheme: With this scheme, any changes made are notified to the mailbox specified in the "mnt-nfy" field. There is no authentication i.e. anyone can make changes. ____________________________________________________ ripe-153.txt Page 58 ripe-153 A. M. R. Magee ____________________________________________________ However, if you are in doubt whether or not to change the object maintained (i.e. protected) by the mntner, you should send your request to the mailbox specified in the "upd-to" attribute. This is the simplest authentication scheme which is entirely backwards compatible with the one previ- ously used. No authentication is provided, i.e. it is assumed that all update requests originate from an authorised maintainer or are at least coordinated with one. Anyone in doubt whether it is OK to issue update requests should check with the maintainer concerned first, preferably at the mailbox speci- fied in the upd-to attribute. When making any changes the mnt-by attribute should not be changed without explicit consent from the current main- tainer. This scheme is for those who want to give everyone the possibility to make changes while at the same time using the mnt-by attribute for its notification and documentation features. A good reason to use this scheme is when the maintainer cannot guarantee timely processing of updates themselves. The "MAIL-FROM" scheme: This scheme checks the "From" line in the e-mail which contains the update. If it is the same as what is specified here, the update is allowed. This authentication method checks the content of the RFC822 From: header of an update request against the regular expression specified as . If the regular expression matches the content of the From: header the update request is authenticated success- fully. The regular expres- sions supported are described in POSIX 1003.2 sec- tion 2.8. As it is expected that most regular expressions will either be literals or of a form similar to .*@some.domain.or.other an extensive description of the possibilities will not be given. Note that the matching is applied to the whole con- tent of the From: header including comments if present. No attempt is made to isolate the mailbox part. It should be stressed that this authentication scheme is very weak. Forging RFC822 headers does not take much effort or ingenuity. The reason for the scheme's existence is that it easily pre- vents accidental updates rather than allowing them ____________________________________________________ ripe-153.txt Page 59 ripe-153 A. M. R. Magee ____________________________________________________ first and fixing them later when notified. This scheme is for those who want to prevent acci- dental updates by others and are able to process update requests in a timely manner. The "CRYPT-PW" scheme: This uses an encryption process which is similar to that used to make and check login passwords in UNIX. A password is chosen by the user; this is encrypted and put in the database. The encrypted password can be seen by everyone. The user sends the clear pass- word in the same mail as the request to change an object. It is difficult to get the original, clear password from the encrypted one; that is why the encrypted one can be put in the public database. However, passwords based on words which may be found in a dictionary should be avoided; encrypted pass- words based on such words may be broken by the use of lots of fast machines running for a sufficiently long time. This scheme uses the Unix crypt(3) routine, which is also used for login passwords under Unix. This routine provides a so called "trap door" function, the inverse of which is somewhat hard to calculate. The password provided by the user is encrypted with this function and stored in its encrypted form only. When the user later provides the password again for authentication, the encryption is repeated and the results are compared. Since the original (cleart- ext) password cannot easily be computed from the encrypted version the encrypted password does not have to be kept secret. The is the encrypted password. This can either be obtained locally with the appropri- ate Unix tools or on e-mail request from . When sending in update requests the cleartext password has to be provided in the message body by specifying password: cleartext-password at the beginning of a line and preceding any update requests to be thus authenticated. The pass- word will remain valid for all requests following it in the same e-mail message or until another ____________________________________________________ ripe-153.txt Page 60 ripe-153 A. M. R. Magee ____________________________________________________ password is specified. This scheme is slightly stronger than the MAIL-FROM scheme. It is by no means meant to keep out a determined malicious attacker. The crypt function is vulnerable to exhaustive search by (lots of) fast machines and programs to do the searching are widely available. For this reason it is strongly discour- aged to use encrypted passwords also used for other purposes such as Unix login accounts in this scheme. As you are publishing the encrypted password in the database it is open to attack. The usual caveats about crypt passwords apply, so is not very wise to use words or combinations nations of words found in any dictionary of any language. See [R. Morris, K. Thompson: Password Security: A Case History] for more details about the scheme and its vulnerabilities. Example of use: * auth: NONE * auth: CRYPT-PW dhjsdfhruewf * auth: MAIL-FROM .*@ripe.net The "auth" field must be included in a mntner object, even if no authorisation scheme other than `NONE' is required. Furthermore, several "auth"fields may be included in the same mntner object. Example: mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner object. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net auth: MAIL-FROM Ambrose.Magee@ripe.net auth: MAIL-FROM ripe-dbm@ripe.net auth: CRYPT-PW eiktegisvfxg notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 961011 source: RIPE ____________________________________________________ ripe-153.txt Page 61 ripe-153 A. M. R. Magee ____________________________________________________ Multiple authentication methods can be specified in the same mntner object. They all have equal status i.e. any one of the authenticators is sufficient to authenticate the update request from the main- tainer. In the above example, objects protected by this mnt- ner object may be changed if: * (1) the e-mail message is from Ambrose.Magee@ripe.net; * (2) the e-mail message is from ripe- dbm@ripe.net; * (3) the e-mail message contains the unencrypted form of the password eiktegisvfxg. If multiple maintainers maintain an object this feature should not be used. Multiple maintainers should be represented by multiple mntner objects referenced in the mnt-by attribute. There is no way in the current model to require a combination of multiple authenticators to authenticate a request. 2.4 Obtaining a mntner object: Unlike other objects, mntner objects are not created automatically; they are created on your behalf by the staff at RIPE NCC. To obtain a mntner object, do the following: (i) First, obtain a template of a mntner object by using the "-t" option with the `whois' command (see Section 2.1). (ii) Fill in the template and send it to , from where it will be forwarded to . You may also send it directly to . (iii) Your mntner object will be created as soon as possible, if your request satisfies the criteria mentioned below. Criteria (i) The request comes from someone who is responsi- ble for the maintenance of objects that are related ____________________________________________________ ripe-153.txt Page 62 ripe-153 A. M. R. Magee ____________________________________________________ to public address space, domain names and routes. (ii) Normally, individuals who request a mntner object already have objects in the RIPE database which they wish to protect. (iii) Such objects should be related to public address space or domain names that have been assigned by the appropriate registry. ____________________________________________________ ripe-153.txt Page 63 ripe-153 A. M. R. Magee ____________________________________________________ Appendix Mailing Lists 1. Introduction There are three mailing lists that are relevant to the use and development of the RIPE database: * db-wg * db-beta * rr-impl 1.1. db-wg This is the mailing list of the RIPE Database Work- ing Group. This working group deals with all aspects of the RIPE network management database. The current chair of this group is Wilfried Woeber . Membership of this list is open. The list is archived since October 1992. Send mail to . 1.2. rr-impl This mailing list is to discuss Routing Registry Implementations. Membership is open, but aimed at Routing Registry Implementors. ____________________________________________________ ripe-153.txt Page 64 ripe-153 A. M. R. Magee ____________________________________________________ The list is archived since Feb 1994 Send mail to . 1.3. info db-beta This mailing list is used to exchange information about the current beta release of the RIPE database software. The list membership is closed to beta testers. The list is archived since October 1993. Send mail to . 2. More Information For more information about any of these lists, con- tact or . ____________________________________________________ ripe-153.txt Page 65