# 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 publically 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 (opens new window).
# 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:
- (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 (opens new window), select the appropiate 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 (opens new window).
# Criteria for a Mirrored Database
Databases mirrored by the RIPE NCC must satisfy certain conditions.
The mirrored database must be:
- 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 (opens new window).
# 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 (opens new window).
# 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.