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

Authorisation Model ​

The mntner objects serve as anonymous containers that hold authorisation credentials. A reference to a mntner object within any object defines authorisation necessary to perform operations on that object or on a set of related objects. Such reference is provided by means of several attributes including "mnt-by:", "mnt-lower:", "mnt-routes:", "mnt-domains:", "mnt-ref:" and "mbrs-by-ref:" attributes.

The mntner object contains one or more mandatory "auth:" attributes. Each attribute begins with a keyword identifying the authorisation method followed by the authorisation information or token needed to enforce that method. The irt object also has mandatory "auth:" attributes used for authorisation.

All updates require authorisation. A credential that is valid for one of the authorisation tokens of one of the relevant mntner objects, must be supplied. Different methods of authorisation require different authorisation tokens, as shown in the table below of authorisation methods that are currently supported.

Visit this section to know more about mntner object.

Authorisation MethodDescription
MD5-PW

This scheme is based on the MD5 hash algorithm. The authorisation information stored in the database is a passphrase, encrypted using md5-crypt algorithm, which is a concatenation of the "$1$" string, the salt, and the 128-bit hash output. Because it uses an eight-character salt, a passphrase of almost unlimited length and the encrypted hash is hidden from public view, this scheme is quite stable against dictionary attacks.

Please note that MD5 hashed passwords are deprecated and will be removed by end 2025. Choose an alternative authentication method.

Example:

auth: MD5-PW $1$abcd4321$HyM/GVhPqXkkIMVerxxQ3z
PGPKEYThis is a strong form of authorisation. The authorisation information is a signature identity pointing to a public key certificate, which is stored in a separate key-cert object. The update is authorised if the transaction is signed by the corresponding private key. The RIPE NCC does not guarantee that a key belongs to any specific entity. Anyone can supply any public keys, with any ownership information, to the RIPE Database. These keys can be used to protect other objects by checking that the update comes from a user who knows the corresponding secret key. The database software only allows current keys (that have not expired) to sign an update message, and signed messages are only valid for one hour.

Example:

auth: PGPKEY-1380K9U1
SSOThis scheme is based on the RIPE NCC Access single sign-on (SSO) system. It takes the management of these authorisation tokens outside of the RIPE Database. The authorisation tokens are managed by the RIPE NCC Access software. To use this, you must first create an account with RIPE NCC Access.

The SSO system was introduced so that when somebody signs in once with RIPE NCC Access, that account authorises them to use certain services that support it, such as Webupdates or the Syncupdates web form.

The credential in the mntner object uses the keyword SSO followed by the email address used to sign in to your SSO account. You can add many different SSO credentials to a mntner object and add your SSO credential to as many mntner objects as you wish (provided you have authority to update each mntner object using existing authorisation). If you change your email address in your RIPE NCC Access preferences, this will immediately be reflected in any mntner objects where this access account is referenced.

authorisation using SSO can be done from Webupdates and the Syncupdates web form. You can sign into your RIPE NCC Access account directly from Webupdates and Syncupdates. Using any of the update features from Webupdates/Syncupdates you can create, modify and delete objects. No password is needed - you are already authenticated and authorised to make these updates, assuming the object(s) are maintained by one of your SSO mntner objects.

Example:

auth: SSO dbtest _at_ ripe _dot_ net
API Keys

API keys are a new way to authenticate updates in the RIPE Database. They are associated with a user's RIPE NCC Access account, and are intended to help you script (automate) updates to the RIPE Database. If you only use webupdates then you don't need API keys!

To create an API key, login to Webupdates using RIPE NCC Access and choose API keys from the left-hand menu. Then click Create an API Key. When the key is created you will see a popup. You must copy the API key details as they will only be shown once. Store the copied credential securely.

Before using an API key, you must add your RIPE NCC Access account to a maintainer using an auth: SSO attribute.

To authenticate a query or update using an API key, send the credential using HTTP Basic authentication.

For an example, please refer to the appendix.

X.509This is similar to PGP. You need a certificate and a private key. The certificate must be included in a key-cert object. The update is authorised if the transaction is signed by the corresponding X.509 private key. The RIPE NCC does not guarantee that a certificate belongs to any specific entity. Anyone can supply any certificate, with any ownership information, to the RIPE Database. Those certificates can be used to protect other objects by checking that the update comes from a user who knows the corresponding private key. The database software only allows current keys (that have not expired) to sign an update message, and signed messages are only valid for one hour.

Example:

auth: X509-3333

Solving Authentication Problems ​

Given the flexibility of the RIPE Database and the maintainer system, there can be cases where you find yourself unable to authenticate. Currently, only certain combinations of authentication and update methods are compatible, as shown in this table:

SSOPGPMD5API Keys
Webupdates (Web interface)YesNoYes*No
EmailNoYesYes*No
APINoNoYesYes
SyncupdatesNoYesYes*Yes

*It works, but is not recommended

TIP

We recommend that if you predominantly use the web interface, you only use SSO, and if you mainly use syncupdates or email updates, you use PGP. If you use the API, then use API keys.

WARNING

Please note that MD5 hashed passwords are deprecated and will be removed by end 2025.

Depending on your use case, it is important to carefully consider which authentication method you put on each maintainer you manage. For example, there are three basic situations where authentication might fail when trying to use the web interface:

  • The object you are trying to modify is protected by a maintainer that is not yours. You therefore rightfully do not have access.
  • The object you are trying to modify is protected by a maintainer with several SSO account, none of which are yours. The maintainer also doesn't have a shared MD5 password that would allow you to authenticate.
  • The object you are trying to modify is protected by a maintainer that only has a PGP key as the authorisation.

For cases 1 and 2, you need to ask the administrative or technical contact of the maintainer to give you the appropriate access. For case 2, you can use another update method that does support your authentication, such as email.

Lastly, in case your maintainer is protected with a MD5 password that you forgot, you can reset it here.

Last updated:

Pager
Previous pageNotification Messages
Next pageUsing the Authorisation Methods