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

Purpose and Content of the RIPE Database ​

The RIPE NCC has been tasked by the RIPE community to maintain a database of Internet resource information. Some of this information is confidential between the RIPE NCC and the resource holder and some of it is publicly available. The RIPE Network Management Database, more often referred to as the RIPE Database, provides the public view of this data. Some of the management details for maintaining Internet resources in this database are also confidential, for example MD5 password hashes. The RIPE Database provides access to this private data for resource holders.

The RIPE Database holds data for three separate registries:

  • RIPE Internet Number Registry (RIPE INR)
  • RIPE Internet Routing Registry (RIPE IRR)
  • Reverse Delegation and ENUM Registry

These could be three independent databases, however the information in each of them is related to each other. It was therefore decided to integrate the three registries into one logical database. In practise, it is also one physical database.

Purpose of the RIPE Database ​

The RIPE Database contains information for the following purposes:

  • Ensuring the uniqueness of Internet number resource usage through registration of information related to the resources and their Registrants and Maintainers (RIPE INR)
  • To provide accurate registration information of these resources in order to meet a variety of operational requirements
  • Publishing routing policies by network operators (RIPE IRR)
  • Facilitating coordination between network operators (network problem resolution, outage notification etc.)
  • Provisioning of Reverse Domain Name System (DNS) and ENUM delegations
  • Scientific research into network operations and topology
  • Providing information to parties involved in disputes over Internet number resource registrations to parties who are legally authorised to receive such information.

RIPE Internet Number Registry ​

Global Internet resources are allocated by the Internet Assigned Numbers Authority (IANA) to five Regional Internet Registries (RIRs). The RIPE Internet Number Registry (RIPE INR) contains details of the Internet resources managed by the RIPE NCC within the RIPE NCC service region. These details in the RIPE Database are maintained jointly by the RIPE NCC and the Registrants of those resources. The RIPE INR also contains details of sub-allocations and assignments made from these resources by the Registrants. This information is maintained in the RIPE Database by the Registrants of those resources.

The information includes the organisations that hold the resources, where the allocations were made, and contact details for the networks. Dates of when changes were made to this information are also included, and some of the historical information is also available.

The RIPE Internet Routing Registry ​

The RIPE Internet Routing Registry (IRR) is part of a global distribution of databases by which network operators can publish their routing policies and their routing announcements so that other network operators can make use of the data. In addition to making Internet topology visible, the IRR is used by network operators to look up peering agreements, determine optimal policies, and more recently, to configure their routers.

Each RIR has its own IRR. There are also many independent IRRs, for example RADb. A resource holder can register their routing information in any of the IRR databases. Most of the larger IRRs mirror each others' routing information. Therefore, it is only necessary to enter this information into one IRR.

Only resources allocated to the RIPE region can be registered in the RIPE IRR.

The benefits of the IRR are only realised when registered routing policies are kept up-to-date, and reflect routing announcements in the 'real world'.

Reverse Delegation ​

What is Reverse Delegation? ​

The Domain Name System (DNS) is a globally distributed Internet service. It provides name-to-number (forward) and number-to-name (reverse) translations, using defined client-server and server-server protocols. The DNS is a public service - any Internet user is freely able to query the DNS system for forward or reverse translations.

Reverse DNS delegations allow applications to map to a domain name from an IP address. Reverse delegation is achieved by use of the special domain names in-addr.arpa (IPv4) and ip6.arpa (IPv6).

For all IP address blocks that IANA allocates to the RIPE NCC, they also delegate the corresponding reverse DNS zones within the centrally administered 'in-addr.arpa' and 'ip6.arpa' zones.

The RIPE NCC also publishes 'zone fragments'. These are the parts of zones managed by other parties - the other Regional Internet Registries (RIRs), who share zone management of early registration networks.

Reverse Delegation in the RIPE Database ​

The RIPE Database is used as the management database to produce the DNS zones RIPE Internet Number Resources. It can provide the information for each delegated IPv4 and IPv6 range registered in the reverse DNS.

The information is stored in routing policy specification (RPSL) format as domain objects. The name of each domain object is the reverse DNS zone under in-addr.arpa or ip6.arpa or e164.arpa. The "nserver:" attributes in each domain object define the officially delegated DNS name servers- the "NS" in DNS zone contents.

Domain Names ​

The RIPE Database used to contain information about domain names for Top Level Domain Registries based in the RIPE NCC service region as well as a few other regions. These were all removed from the RIPE Database by the end of 2011. The RIPE Database now contains no information about forward domain names. Further information about domain names can be found on the IANA ccTLD web page.

Administration of Internet Resources ​

IANA is responsible for ensuring the uniqueness of the full set of Internet resources. This includes the full range of IPv4 and IPv6 addresses and the whole 32-bit Autonomous System (AS) Number range. IANA allocates blocks of these resources to each of the five RIRs for them to distribute to their members and end users.

The RIPE Database contains large placeholder allocation objects to represent the range of IPv4 and IPv6 addresses that have been allocated by IANA to the RIPE NCC. Not all of this address space has been allocated yet by the RIPE NCC to LIRs or end users.

The RIPE Database also holds details of legacy Internet resources. "Legacy" is the term given to those Internet number resources that were distributed before (or outside of) the current system of hierarchical distribution by the Regional Internet Registries (RIRs). Legacy Internet resources were transferred to the RIPE NCC from the IANA's central registry according to the location of their legal organisation contact at the time.

Legacy address space represented in the RIPE Database is structured into an administrative hierarchy. For every legacy hierarchy in the RIPE Database there is one inetnum that sits at the top of the hierarchy. The RIPE NCC considers the holder of this inetnum as the top-level legacy resource holder. All more specifics to this object are considered to have some business or contractual or historical relationship with the top-level legacy resource holder.

It is intended that the RIPE Database must only hold information about IP addresses that the RIPE NCC is administratively responsible for. There may still be some historical data that needs cleaning up.

The full range of 32-bit AS Numbers are represented in the RIPE Database by the as-block objects. All ASNs assigned by the RIPE NCC are represented in the RIPE Database by aut-num objects.

It should be noted that the RIPE Database is part of the global Internet Routing Registry. It may contain route(6) objects relating to any address space. This does not indicate any authoritative or administrative control over these Internet resources by the RIPE NCC.

There is a link between the number registry and the routing registry in order to authorise the creation of these route(6) objects. As a result, the originating ASN must be represented in the RIPE Database. Because of this requirement, many aut-num objects have been created in the RIPE Database that are copies of ASNs that the RIPE NCC is not administratively responsible for. This can sometimes cause confusion when the copied aut-num object in the RIPE Database reflects different contact details or routing policy to the object held in the database of the authoritative RIR.

Mirrored Databases ​

The RIPE Global Resource Service (GRS) provides resource information mirrored from several other databases. These are held in physically separate databases but logically part of the RIPE Database service. They can be queried using several of the RIPE Database interfaces. The information is updated daily from the authoritative source.

The following databases are mirrored:

  • AFRINIC
  • APNIC
  • ARIN
  • JPIRR
  • LACNIC
  • RADb
  • (RIPE GRS)

To view the up-to-date list of mirrored databases, perform the following query:

whois.ripe.net -q sources

Because the RIPE NCC is bound by Dutch and European data privacy laws, we are obligated to remove all personal data received from other databases. This is either removed at the source or stripped out and deleted during the transformation process. The RIPE NCC does not store any personal data from other registries. Where necessary, we create and reference dummy objects to keep data integrity intact.

Before importing the data we transform objects into RIPE RPSL syntax by carrying out the following steps:

  • Adding missing mandatory attributes
  • Wrapping unrecognised attributes with "remarks"
  • Creating dummy objects for missing data to keep referential integrity
  • Converting attributes values
  • All these transformations are marked by "End Of Line" comments in the objects

To use GRS from the web interface, select the appropriate radio button below the search box. When using telnet or the whois command line client, add the --resource flag to your query to query only the dummified GRS databases, or the -a flag to query all available databases, i.e. GRS sources and the original RIPE Database combined.

Using the API, you can specify one or multiple GRS source names as parameters, e.g. "source=arin-grs" or "source=arin-grs&source=apnic-grs". For more information, please refer to the documentation on Github.

Criteria for a Mirrored Database ​

Databases mirrored by the RIPE NCC must satisfy certain conditions.

The mirrored database must be:

  • Public
  • Large
  • Useful to users in the RIPE NCC service region

The RIPE NCC reserves the final judgement on mirroring a database. You can request the RIPE NCC to mirror a database by contacting us.

I Want to Change Something in the RIPE Database ​

Changes can be proposed to the RIPE Database purpose and content by anyone from the RIPE community using the RIPE Policy Development Process.

Terms and Conditions ​

The legal statement of what the RIPE Database is, and how it can be used is defined in the RIPE Database Terms and Conditions. While the information in the RIPE Database is made freely available to the public, it is all subject to these terms and conditions.

Last updated:

Pager
Previous pageConventions Used in the RIPE Database Documentation
Next pageHistory of the RIPE Database