RIPE Database docs
Sidebar Navigation

Introduction to the RIPE Database

RIPE Database Documentation Overview

Intended Audience

Conventions Used in the RIPE Database Documentation

What is the RIPE Database

Purpose and Content of the RIPE Database

History of the RIPE Database

Personal Data Database Management and Reponsabilities

RIPE Database Structure

Database Object

Primary and Secondary Objects

List of Primary Objects

List of Secondary Objects

The Attributes in Database Objects

Attribute Names

Attributes in an Object

Attribute Values

Attribute Properties

How to Organise Your Data

REST API Data model

RPSL Object Types

Descriptions of Primary Objects

Descriptions of Secondary Objects

Available Databases

RIPE Database

TEST Database

Release Candidate Database

Experimental Databases

Update Methods

RESTful API

Webupdates

Syncupdates

Email Updates

Updating Objects in the RIPE Database

Format of the Update Message

Accessing the Object Templates

Object Processing

Update Operations

Historical Data

Special Considerations for Object Creation

Garbage Collection

Dry run

Set Objects

Notifications

Acknowledgment Message

Notification Messages

Authorisation

Authorisation Model

Using the Authorisation Methods

Security of Data Using Authorisation

Protection of PERSON and ROLE Objects

Protection of AUT NUM Object Space

Protection of Address Space

Protection of Route Object Space

Protection of Reverse Delegation Objects

Protection of Objects with Hierarchical Names

Protecting Membership of a Set

Referencing an ORGANIZATION Object

Referencing an IRT Object

IRT Object

Force Delete Functionality

Request ENUM delegation

Request DNSSEC delegation

How to Query the RIPE Database

The Structure of a Query

Web Query Form

RESTful API Queries

Command Line Queries

Query Responses

Registration Data Access Protocol

Access to Personal Data

Types of Queries

Queries Using Primary and Lookup Keys

Queries for IP Networks

Queries for Autonomous Systems

More and Less Specific Lookups For Reverse Domains

Inverse Queries

Abuse Contacts

Grouping the RIPE Database Output

Filtering the Query Reponse

IRR Toolset Support

Persistent Connections and Keeping State

Getting All the Members of Set objects

Access Control for Queries

RIPE NCC Global Resource Service

Other Query Flags

Referenced Objects in Query Response

Historical Queries

Related Software and Tools

Geolocation in the RIPE Database

RIPE Database Mirror

Setup RIPE Database Mirror

Near Real Time Mirroring v3

Near Real Time Mirroring v4

Access to NRTM

Tables of Query Types Supported by the RIPE Database

How to Recover Access to a Maintainer Object

Installation and Development

Getting started on macOS

Getting started on Ubuntu Linux

Building whois

Configure MariaDB

Coding standard

Installation instructions

Database Support

Support Overview

Clean up of Unreferenced Data

Database Security

Configuring Reverse DNS

Database Business Rules

Highlighted Values in the RIPE Database

Create First Role Mntner

Removal of personal data

Release Notes

FAQ

Appendices

Appendix A Syntax of Object Attributes

Appendix B Copyright Statement

Appendix C RIPE Database Query Server Response Codes and Messages

Appendix-D--Route-Object-Creation-Flowchart

Appendix-E--Domain-Object-Creation-Flowchart

Appendix F Special Considerations for Object Types

Appendix G Object Types with Personal Data

Appendix H PGP Authentication Method

Appendix I Client Certificate Authentication

Appendix J Ripe Test Database

Appendix K API Keys

Glossary

Legal Information

RIPE Database Acceptable Use Policy

HTML Terms And Conditions

All Documentation Combined

On this page

Special Considerations for Object Creation ​

Most object types follow the same rules when created. Some object types have additional business rules that only apply to those types when they are created.

Creating PERSON and ROLE Objects ​

To create person and role objects, you can either choose your own unique NIC handle or you can use 'AUTO-n' where the server will automatically assign a NIC handle.

To request the server to assign a NIC handle for you, specify the value of the "nic-hdl:" attribute as:

nic-hdl: AUTO-<number>[<initials>]

The number is required. It does not form part of the NIC handle but acts as an index. If your update message contains multiple objects, other objects can reference this NIC handle by the index. See the sub-section Object Processing for examples. The initials are optional. If you choose to specify the <initials> (between two and four characters), they will be used to try to make the NIC handle. Otherwise, the software will take the initials from the name in the "person:" or "role:" attribute. The syntax definition of a NIC handle allows for an optional suffix at the end of the character string. The default suffix is "-RIPE" when an 'AUTO-n' NIC handle is used. If you want to use another suffix, or have no suffix, or you want to select the number part, then you must specify the full NIC handle and not use the 'AUTO-n' option. Please note that if you specify a NIC handle that is currently in use, it may be considered as a modification operation, which may cause the operation to be refused depending on the update method used. See section 6.4 Update Operations for more details. If the operation continues, as a modification, it will usually result in an authentication error. If you select a NIC handle that has previously been used and deleted, an error will be returned.

If you are creating your first person or role object in the database, you must follow the procedure described in the sub-section 'New Organisation Startup'.

Reusing NIC Handles ​

The person and role objects are identified by NIC handles. Historically, these were available to reuse as soon as an object was deleted. Many NIC handles have been used and reused by several different people. As that can lead to confusion, the NIC handles are no longer reusable. When a person or role object is created, the NIC handle is added to a list of used NIC handles. When the object is deleted the NIC handle remains on the list. It can never be reused. Please note that these objects cannot be deleted if they are referenced by any other object. This avoids accidental deletion of an object that is still in use. While some people try to create NIC handles with a '"meaningful'" name, it should be remembered that they are only meant as a database index. If you delete one that is unreferenced, then realise you still need it, you will need to create a new one.

Creating ORGANISATION Objects ​

To create an organisation object, you must specify the ID of the object as 'AUTO-n'. It is not possible to select the ID yourself. It is always auto-generated.

organisation: AUTO-<number>[<initials>].

The number is required. It does not form part of the ID but acts as an index. If your update message contains multiple objects, other objects can reference this ID by the index. See the sub-section 'Object Processing' for examples. The initials are optional. If you choose to specify the <initials> (between two and four characters), they will be used to try to make the ID. Otherwise, the software will take the initials from the name in the "org-name:" attribute.

For example, if you want 'TTR' as the initials in the organisation ID, you should put 'AUTO-1TTR' into the "organisation:" attribute, when you create the object. If you delete an organisation object you cannot recreate one with the same ID as the one you deleted or with any other ID that has been used previously.

New Organisation Startup (Creating First Objects) ​

When you first use the RIPE Database, you need to create some basic objects. Every object you create in the database must be maintained. That means you need a mntner object. This object must reference a role (or person) object as a contact. However, the role (or person) object must be maintained. Therefore, a user cannot create either of these two objects first using any of the usual update methods.

There is separate page to create a role and maintainer pair, so that new users can get started.

If errors occur during the creation process, these are reported back to the user. If successful, the mntner object name and the NIC handle are returned to the user. There is no partial success allowed. If one object can be successfully created during the intermediate stage, but the second object has errors, no object will be created.

If you have nothing in the RIPE Database, this startup script is the only way to get started. Once you have this first pair of objects, you can use the normal update methods for all other objects.

Last updated:

Pager
Previous pageHistorical Data
Next pageGarbage Collection