# Entire Documentation HTML

# RIPE Database Documentation

Welcome to the RIPE Database Documentation.

The Documentation is divided into sections that are featured in the sidebar to the left. You can switch between these sections and items at any time by clicking on the links.

You can also use the searchbar above to search for any word or phrase on any page.

# Access to Personal Data

For privacy and data protection reasons, there is a limit to how much personal data a user can query from the RIPE Database over a period of time. For more details of the legal background, see the RIPE NCC Data Protection Report (opens new window).

Personal information is contained in the person object. There may also be some personal information in some role objects. The access control mechanism built into the database software therefore applies to both person and role objects.

The access control mechanism used is based on the number of these objects that are returned in the results of any queries made. Limits are applied to the IP address of a user sending queries to the database server by any of the query methods. (See 'How to Query the RIPE Database' for more details of the methods.)

Sometimes an IP address may be acting as a proxy and submitting queries on behalf of other IP addresses (for example, a webserver providing an interface to the RIPE Database). The database software provides a facility for proxy operators, which allows accounting to be based on the IP address of the End Users using the proxy to query the RIPE Database, and not on the IP address of the proxy operator. This is done using the -V flag as follows:

-V <version>,<ip-address>
  • <version> is a client tag that can be any text string chosen by the proxy operator. Operators often use a string, showing the version of the software that the proxy operator uses, or, sometimes, they use an identifying string for the proxy operator.
  • <ip-address> is the IPv4 or IPv6 address of the End User that queries the database using the proxy service

Not all users can operate a proxy service and use this -V flag. You must contact RIPE Database Administration
[ripe-dbm _at_ ripe _dot_ net] and explain why you need this facility. If your request is approved, the IP address of the proxy server will be added to an access control list. The proxy operator can then use the -V flag, but only from the IP address stated in the request.
Attempting to use the -V flag without approval, or from any IP address not on the access control list, may result in permanent denial of access to the RIPE Database. This denial of access will apply to the IP address that submits the query using the -V flag.

# Blocking Access to the RIPE Database

Each time a person or role object is returned as part of a query result, a counter increases. When it reaches the limit defined in the AUP, the query execution is aborted and the connection is terminated, displaying an error message to the client (see the section on Access errors in the RIPE Database Query Server Response Codes and Messages). There is also a separate counter, tracking the number of times your request is denied. Retrieving any other object type does not affect these counters.

Any role object used for abuse contacts with an "abuse-mailbox:" attribute is an exception to this rule. No accounting is done on these objects.

We restrict access to the RIPE Database to stop people from using it to collect excessive amounts of contact data. If the number of personal contact objects returned by all your queries in a day (defined by UTC) from one IP address exceeds the limits defined in the Acceptable Use Policy (AUP), that IP address's access will be blocked. If your access is blocked, you will unable to query the RIPE Database for any object types - you are not just blocked from accessing contact data objects. This temporary block will be automatically released at midnight (UTC) to allow querying to continue. There is also a limit on the number of times an IP address can be blocked and recover. When this limit is reached, that IP address is permanently blocked from accessing the RIPE Database. This permanent block will not be removed automatically.

There are many reasons why you could find yourself blocked from querying the RIPE Database. One is that you are mining the RIPE Database for contact data to use for non-agreed purposes. In this case, the denial of access is justified and your IP address will remain on the blocked list. However, there may be other reasons why your IP address has been blocked. Queries for object types other than person and role objects return contact information by default. Using the -r or --no-referenced query flag to prevent contact data being included in your query results turns off this default. Alternatively, you may have an error in a script that runs automatically, retrieving contact data that you did not know about.

If you believe there was a genuine error or mistake that led to a permanent block, you should contact the RIPE Database administrators (opens new window), explaining the error and what steps you have taken to stop it happening again. The RIPE Database administrators will decide if the block will be removed. It will remain on record that this IP address has been permanently blocked and then unblocked. If another permanent block occurs, it is less likely to be removed again.

# Appendix A- Syntax of Object Attributes

The syntax definitions of the object attributes that the RIPE Database supports are shown below.

The value of an attribute has a type. Some of the most commonly used and complex types are shown in the table below. Others are explained in the descriptions of the attributes.

Commonly Used Attribute Types
Type Description
<quad> <xdigit>.){1,4}
<dlabel> Domain name label as specified in RFC 1034 (opens new window). The total length should not exceed 63 characters (octets)

<alnum>((-\
<action> Please see RPSL RFC 2622 (opens new window)
<address-prefix> An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 192.0.2.5/32, 192.0.2.0/24, 0.0.0.0/0. The following address prefixes are invalid: 0/0, 192.0.2/24 since 0 or 192.0.2 are not strings containing four integers.

<ipv4-address>/<integer>
<address-prefix-range> An address prefix range is an address prefix followed by an optional range operator. Please see RPSL RFC 2622 (opens new window).
<as-expression> Please see RPSL RFC 2622 (opens new window)
<as-number> An "AS" string followed by a 32-bit integer

AS<integer>
<condition> Please see RPSL RFC 2622 (opens new window)
<domain-name> Domain name as specified in RFC 1034 (opens new window) without a trailing dot ("."). The total length should not exceed 255 characters (octets)

<dlabel>(\.<dlabel>)*
<e-mail> Email address specification as defined in RPSL RFC 2822 (opens new window).
IDN domains will be encoded as Punycode as defined in RFC 3492 (opens new window)
<filter> Please see RPSL RFC 2622 (opens new window)
<freeform> A sequence of Latin 1 characters
<inet-rtr-name> Specifies the name of an inet-rtr object.
It is a <domain-name>.
<ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255, separated by the character dot ("."). For example, 192.0.2.5 represents a valid IPv4 address.

[0-9]+(\.[0-9]+){3,3}
<ipv6-address> <quad>(:<quad>){7,7}
<ipv6-address-prefix> An IPv6 address prefix is represented as an IPv6 address followed by the character slash "/" followed by an integer in the range from 0 to 128.

<ipv6-address>/integer
<ipv6-filter> Please see RPSLng RFC 4012 (opens new window)
<irt-name> Specifies the name of an irt object. It is an <object-name> starting with the prefix "IRT-" that is reserved for this object type.
<mntner-name> <object-name>
<nic-handle> From two to four characters, optionally followed by up to five digits, optionally followed by either a source specification of up to nine characters or two-letter country code. Source specification and country codes start with "-".

(<alpha>{2,4}([1-9]<digit>{0,5})?(-<alpha>

([a-zA-Z0-9_-]{0,7}<alnum>))?)\
<object-name> Many objects in RPSL have a name. An <object-name> is made up of letters, digits, the character underscore "_", and the character hyphen "-". The first character of a name must be a letter and the last character of a name must be a letter or a digit. The following words are reserved by RPSL, and they can not be used as names:
any, as-any, RS-any, peeras, and, or, not, atomic, from, to, at, action, accept, announce, except, refine, networks, into, inbound, outbound.

Names starting with certain prefixes are reserved for certain object types.
Names starting with "as-" are reserved for as-set names.
Names starting with "rs" are reserved for route-set names.
Names starting with "rtrs-" are reserved for rtr-set names.
Names starting with "fltr-" are reserved for filter-set names.
Names starting with "prng-" are reserved for peering-set names.
Names starting with "irt-" are reserved for irt object names.
<org-id> The 'org-' string followed by two to four characters, followed by up to five digits, followed by a source specification. The first digit must not be "0". Source specification starts with "-" followed by a source name up to nine-characters in length.

org-<alpha>{2,4}([1-9]<digit>{0,4})-<registry-name>
<organisation-name> A list of 1 to 30 words separated by white space. A word can contain alphanumeric characters in addition to any of the following: asterisk, plus and minus signs, forward slash and backslash, dash, quotes, at sign, comma, dot, underscore, ampersand, exclamation mark, colon, semicolon, brackets and square brackets. A word may have up to 64 characters and is not case sensitive. Each word can have any combination of the above characters with no restrictions on the start or end of a word.
<peering> Please see RPSL RFC 2622 (opens new window)
<person-name> It should contain 2 to 10 words separated by white space. The first and the last word cannot end with dot ("."). A word is made up of ASCII alphanumeric characters and additionally: digits, the character underscore "_", and the character hyphen "-". The first character of a name must be a letter and the last character of a name must be a letter or digit. Max 64 characters can be used in each word.
<protocol> Please see RPSL RFC 2622 (opens new window)
<registry-name> RIPE
<role-name> It should contain 2 to 10 words separated by white space. The first and the last word cannot end with dot ("."). A word is made up of ASCII alphanumeric characters and additionally: digits, the character underscore "_", and the character hyphen "-". The first character of a name must be a letter and the last character of a name must be a letter or digit. Max 64 characters can be used in each word.
<router-expression> Please see RPSL RFC 2622 (opens new window) and RPSLng RFC 4012 (opens new window)
<telephone-number> Contact telephone number. Can take one of these forms:

+<integer-list>

+<integer-list> \(<integer-list> \)<integer-list>

+<integer-list> ext.<integer-list>

+<integer-list> \( integer-list \) <integer-list> ext. <integer-list>
<integer> An integer
<alpha> Any alphabetical character.

[A-Za-z]
<alnum> Any alphabetical or numerical character.

[A-Za-z0-9]
list

of		 A list of words separated by a comma (","). Cannot be empty.
ripe-list

of		 A list of words separated by white space. Cannot be empty.
<integer-list> A list of integers separated by white space or a dash ("-").

Descriptions of the attributes are listed below in the following format:

<attribute_name> <attribute_value(type)>
<description>

abuse-c: <nic-handle>
References a role object holding contact details of an abuse role.

abuse-mailbox: <e-mail>
Specifies the e-mail address to which abuse complaints should be sent.

address: <freeform>
Full postal address of a contact.

admin-c: <nic-handle>
References an on-site administrative contact.

aggr-bndry: <as-expression>
Defines a set of ASNs which forms the aggregation boundary.

aggr-mtd: inbound | outbound [<as-expression>]
Specifies how the aggregate is generated. Please see RPSL RFC 2622 (opens new window) for more information.

alias: <domain-name>
Specifies a canonical DNS name for the router.

as-block: <as-number> - <as-number>
Specifies the range of ASNs that the as-block object represents. Please see RPSS RFC 2725 (opens new window) for more information.

as-name: <object-name>
A descriptive name associated with an AS Number.

as-set: <object-name>
Defines the name of the set.

auth: <auth-scheme> <scheme-info>
Defines an authorisation scheme to be used. For a description, see the section, 'Authorisation Model'
<auth-scheme> and <scheme-info> can take the values listed below:

Authorisation Schemes
<auth-scheme> <scheme-info>
MD5-PW $1$abcd4321$HyM/GVhPqXkkIMVerxxQ3z
PGPKEY-<id> 1380K9U1
SSO dbtest _at_ example _dot_ net

author: <nic-handle>
References a poem author.

aut-num: <as-number>
The autonomous system number.

certif: <public-key>
Contains the public key for a PGP key or an X509 certificate. The value of the public key is exported from your local key ring in ASCII-armored format or the certificate from your browser. All the lines of the exported key must be included. For PGP, this includes the begin and end markers and the empty line that separates the header from the key body. For X509 certificates, this includes the BEGIN CERTIFICATE and END CERTIFICATE lines.

components: [ATOMIC] [[<filter>] [protocol <protocol> <filter> ...]]

or: [ATOMIC] [[<ipv6-filter>] [protocol <protocol> <ipv6-

filter> ...]]
The "components:" attribute defines what component routes are used to form the aggregate.
<protocol> is a routing protocol name such as BGP4, OSPF or RIP, and <filter> or <ipv6-filter> is a policy expression.
Please refer to RPSL RFC 2622 (opens new window) and RPSLng RFC 4012 (opens new window) for more information.

country: <country-code>
Identifies a country. <country-code> must be a valid two-letter ISO 3166 country code.

default: to <peering> [action <action>] [networks <filter>]
Specifies default routing policies. Please refer to RPSL RFC 2622 (opens new window) for more information.

descr: <freeform>
A short description that is related to the object.

domain: <reverse-domain-name>
Reverse delegation for IPv4 or IPv6 address space.

e-mail: <e-mail>
Specifies an email address of a person, role, organisation or IRT team.

encryption: PGPKEY-<id>
References a key-cert object representing a Computer Security Incident Report Team (CSIRT) public key used to encrypt correspondence sent to the CSIRT. <id> is the key-id of the PGP public key in eight-digit hexadecimal format without "0x" prefix.

export: to <peering-1> [action <action-1>]
. . .
to <peering-N> [action <action-N>]
announce <filter>
Specifies an export policy expression. Please refer to RPSL RFC 2622 (opens new window) for more information.

export-comps: <filter> or <ipv6-filter>
Specifies an RPSL filter that matches the more specifics that need to be exported outside the aggregation boundary. Please refer to RPSL RFC 2622 (opens new window) and RPSLng RFC 4012 (opens new window) for more information.

export-via: [protocol <protocol-1>] [into <protocol-2>]

afi <afi-list>

<peering-1>

to <peering-2> [action <action-1>; <action-2>; ... <action-N>;]

…

<peering-3>

to <peering-M> [action <action-1>; <action-2>; ... <action-N>;]

announce <filter>

Specifies export policy expression for non-adjacent networks. Please refer to the RFC on export-via (opens new window) for more information.

fax-no: <telephone-number>
The fax number of a contact.

filter: <filter>
Defines the set's policy filter, a logical expression which, when applied to a set of routes, returns a subset of these routes. Please refer to RPSL RFC 2622 (opens new window) for more information.

filter-set: <object-name>
Defines the name of the filter. Please refer to RPSL RFC 2622 (opens new window) for more information.

fingerpr: <generated>
A fingerprint of a key certificate generated by the database. Please refer to RFC 2726 (opens new window) for a detailed description of this attribute.

form: FORM <string>
Specifies the identifier of a registered poem object.

holes: list of <address-prefix> or <ipv6-address-prefix>
Lists the component address prefixes that are not reachable through the aggregate route (possibly because that part of the address space is unallocated). Please refer to RPSL RFC 2622 (opens new window) and RPSLng RFC 4012 (opens new window) for more information.

ifaddr: <ipv4-address> masklen <integer> [action <action>]
Specifies an interface address within an Internet router. Please refer to RPSL RFC 2622 (opens new window) for more information.

import: [protocol <protocol-1>] [into <protocol-2>]
from <peering-1> [action <action-1>]
. . .
from <peering-N> [action <action-N>]
accept <filter>
Specifies import policy expression. Please refer to RPSL RFC 2622 for more information.

import-via: [protocol <protocol-1>] [into <protocol-2>]

afi <afi-list>

<peering-1>

from <peering-2> [action <action-1>; <action-2>; ... <action-N>;]

…

<peering-3>

from <peering-M> [action <action-1>; <action-2>; ... <action-N>;]

accept (<filter>|<filter> except <importexpression>|

<filter> refine <importexpression>)

Specifies import policy expression for non-adjacent networks. Please refer to RPSL RFC 2622 (opens new window) for import-via for more information.

inetnum: <ipv4-address> - <ipv4-address>
Specifies a range of IPv4 addresses. The end address should be greater than or equal to the start address..

inet6num: <ipv6-address>/<prefix-length>
Specifies a range of IPv6 addresses in prefix notation. The <prefix length> is an integer in the range from 0 to 128.

inet-rtr: <domain-name>
Fully qualified DNS name of the inet-rtr, written without a trailing dot ".". Please refer to RPSL RFC 2622 for more information.

inject: [at <router-expression>]
[action <action>]
[upon <condition>]
Specifies which routers perform the aggregation and when they perform it. In route objects, the router expression can contain only IPv4 expressions. In route6 objects, it can only contain IPv6 expressions. Please refer to RPSL RFC 2622 (opens new window) and RPSLng RFC 4012 (opens new window) for more information.

interface: <ipv4-address> or <ipv6-address> masklen <masklen> <integer> [action <action>]

[tunnel <remote-endpoint-address>,<encapsulation>]

Specifies a multiprotocol interface address within an Internet router. Please refer to RPSLng RFC 4012 (opens new window) for more information.

irt: <irt-name>
A unique identifier of an irt object. The name should start with the prefix "irt-", reserved for this type of object.

irt-nfy: <e-mail>
Specifies the email address to be notified when a reference to the irt object is added or removed.

key-cert: PGPKEY-<id>
Defines the public key stored in the database. <id> is the ID of the PGP public key in eight-digit hexadecimal format without "0x" prefix.

local-as: <as-number>
Specifies the autonomous system that operates the router. Please refer to RPSL RFC 2622 (opens new window) for more information.

method: <generated>
Defines the type of the public key. Currently, the only methods supported are "PGP" and "X509". Please refer to RFC 2726 (opens new window) for detailed description of this attribute.

member-of: list of <set-name>
This attribute can be used in the route, route6, aut-num and inet-rtr objects. The value of the "member-of:" attribute identifies a set object that this object wants to be a member of. This claim to membership, however, should be acknowledged by a respective "mbrs-by-ref:" attribute in the referenced object. Please refer to RPSL RFC 2622 (opens new window) for more information.

members: list of <as-number> or <as-set-name>
or
members: list of <address-prefix-range>or
<route-set-name><range-operator>
or
members: list of <inet-rtr-name> or <rtr-set-name> or
<ipv4 address>

Lists the members of the set. The first form appears in the as-set object. The syntax of <as-set-name> is the same as the syntax of <object-name>. The second form appears in the route-set object. The syntax of <route-set-name> is the same as the syntax of <object-name>. The third form appears in the rtr-set object. The syntax of <inet-rtr-name> is the same as the syntax of <object-name>. Please refer to RPSL RFC 2622 (opens new window) for more information.

mbrs-by-ref: list of <mntner-name> | ANY
This attribute can be used in all the set objects. It allows indirect population of a set. If this attribute is used, the set also includes objects of the corresponding type (aut-num objects for as-set, for example) that are protected by one of these maintainers and whose "member-of:" attributes refer to the name of the set. If the value of a "mbrs-by-ref:" attribute is ‘ANY', any object of the corresponding type that refers to the set is a member of the set. If the "mbrs-by-ref:" attribute is missing, the set is defined explicitly by the "members:" attribute.

mntner: <object-name>
A unique identifier of the mntner object.

mnt-by: list of <mntner-name>
Specifies the identifier of a registered mntner object used for the authorisation of operations performed on the object containing this attribute.

mnt-domains: list of <mntner-name>

Specifies the identifier of a registered mntner object used for reverse domain authorisation. Controls creation of domain objects. The authorisation method of this mntner object will be used to authorise the creation of an exact match or more specific reverse domain object.

mnt-irt: list of <irt-name>
May appear in an inetnum or inet6num object. It references an existing irt object representing a CSIRT that handles security incidents for the address space specified by the inetnum or inet6num object.

mnt-lower: list of <mntner-name>
Specifies the identifier of a registered mntner object used for hierarchical authorisation. Controls creation of objects that are one level more specific in the hierarchy of an object type (i.e. inetnum, inet6num, as-block, aut-num, route, route6 objects). The authorisation method of this mntner object will then be used to authorise the creation of any object one level more specific to the object that contains the "mnt-lower:" attribute.

mnt-nfy: <e-mail>
Specifies the email address to be notified when an object protected by a mntner is successfully updated.

mnt-ref: list of <mntner-name>

This attribute is only in an organisation object. It specifies the mntner objects that can authorise the addition of references to the organisation object from other objects.

mnt-routes: <mnt-name> [ { list of <address-prefix-range> } | ANY ]
May be used in an aut-num, inetnum, inet6num, route or route6 object. Specifies the identifier of a registered mntner object that controls the authorisation of the creation of route and route6 objects. After the reference to the maintainer, an optional list of prefix ranges inside of curly brackets ‘{}' or the keyword ‘ANY' may follow. The default, when no additional set items are specified, is ‘ANY' or all more specifics. The address prefix range can contain only IPv4 prefix ranges in inetnum and route objects, only IPv6 prefix ranges in inet6num and route6 objects, and it can contain both IPv4 and IPv6 prefix ranges in aut-num objects. Please refer to RPSL RFC 2622 (opens new window) and RPSLng RFC 4012 (opens new window) for more information.

mp-default: to <peering> [action <action>] [networks <filter>]

Specifies default multiprotocol routing policies. Please refer to RPSLng RFC 4012 (opens new window) for more information.

mp-export:

[protocol <protocol-1>] [into <protocol-1>]

afi <afi-list>

to <peering-1> [action <action-1>]

.

.

.

to <peering-N> [action <action-N>]

announce <filter>

Specifies a multiprotocol export policy expression. Please refer to RPSLng RFC 4012 (opens new window) for more information.

mp-filter:

Defines the set's multiprotocol policy filter. Please refer to RPSLng RFC 4012 (opens new window) for more information.

mp-import: [protocol <protocol-1>] [into <protocol-1>]

afi <afi-list>

from <peering-1> [action <action-1>]

.

.

.

from <peering-N> [action <action-N>]

accept (<filter>|<filter> except <importexpression>|

<filter> refine <importexpression>)

Specifies multiprotocol import policy expression. Please refer to RPSLng RFC 4012 (opens new window) for more information.

mp-members: afi <afi-list> list of <address-prefix-range> or

<route-set-name> or

<route-set-name><range-operator>

Lists the multiprotocol members of the set. Refer to RPSLng RFC 4012 (opens new window) for more information.

mp-peer: <protocol> afi <afi> <ipv4- or ipv6- address> <options>

| <protocol> <inet-rtr-name> <options>

| <protocol> <rtr-set-name> <options>

| <protocol> <peering-set-name> <options>

Specifies the details of any (interior or exterior) multiprotocol router peerings. Please refer to RPSLng RFC 4012 (opens new window) for more information.

mp-peering: <as-expression> [<mp-router-expression-1>] [at <mp-router-expression-2>] | <peering-set-name>

Defines a multiprotocol peering that can be used for importing or exporting routes. Please see RPSLng RFC 4012 (opens new window) for more information.

netname: <netname>
Specifies the name of a range of IP address space. The syntax of the <netname> attribute is the same as the syntax of the <object-name> attribute, but it does not have a restriction on RPSL-reserved prefixes.

nic-hdl: <nic-handle>
Specifies the NIC handle of a role or person object. When creating an object, one can also specify an "AUTO" NIC handle by setting the value of the attribute to "AUTO-1" or AUTO-1 <initials>. In these cases, the database software will assign the NIC handle automatically.

notify: <e-mail>
Specifies the email address to which notifications of changes to this object should be sent.

nserver: <domain-name> [ <ipv4-address> | <ipv6-address> ]
Specifies the name servers of the domain, optionally followed by a glue record.

org: <org-id>

This optional attribute may be used in any object type. It references an existing organisation object. For some resource objects, it is a required attribute. In these cases, the referenced organisation object represents the entity that holds the resource. In other objects, it can be used to specify a business relationship. The value of this attribute is the ID of the organisation object. It is required in the inetnum and inet6num objects with the following status values:

  • ALLOCATED-BY-RIR
  • ALLOCATED PA
  • ALLOCATED-ASSIGNED PA
  • ALLOCATED PI
  • ALLOCATED UNSPECIFIED

The "org:" attribute is single-valued in the inetnum, inet6num and aut-num objects, and it is multi-valued in all other objects.

org-name: <organisation-name>

Specifies the name of the organisation that this organisation object represents in the RIPE Database. This is an ASCII-only text attribute. This restriction is because the attribute is a look-up key and the RIPE Database protocol does not allow specifying character sets in queries. The user can put the name of the organisation using Latin 1 character set in the "descr:" attribute if required. But any use of non-ASCII characters in any object may cause problems during the update process.

org-type:

Specifies the type of the organisation. The possible values are shown in the section 'Description of the ORGANIZATION Object''.

organisation: <org-id>

Specifies the ID of an organisation object. When creating this object, the value of this attribute is automatically generated. The user has to specify an "AUTO" ID by setting the value to "AUTO-1" or "AUTO-1<letterCombination>, so that the database will assign the ID automatically.

origin: <as-number>
Specifies the AS Number that originates the route. The corresponding aut-num object should exist in the database.

owner: <generated>
Specifies the owner of the public key. Please refer to RFC 2726 (opens new window) for a detailed description of this attribute.
peer: <protocol><ipv4-address><options>
<protocol><inet-rtr-name><options>
<protocol><rtr-set-name><options>
<protocol><peering-set-name><options>

May appear in an inet-rtr object. Specifies a protocol peering with another router. Please refer to RPSL RFC 2622 (opens new window) for more information.

peering: <peering>
Defines a peering that can be used for importing or exporting routes. Please refer to RPSL RFC 2622 (opens new window) for more information.

peering-set: <object-name>
Specifies the name of the peering-set. Please refer to RPSL RFC 2622 (opens new window) for more information.

person: <person-name>
Specifies the full name of an administrative, technical or zone contact person for other objects in the database.

peering-set: <object-name>
Specifies the name of the peering-set. Please refer to RPSL RFC 2622 (opens new window) for more information.

phone: <telephone-number>
Specifies a telephone number of the contact.

poem: POEM <string>
Specifies the title of a poem.

poetic-form: FORM <string>
Specifies the poem type.

ref-nfy: <e-mail>
Specifies the email address, as defined in RFC 2822 (opens new window), to be notified when a reference to the organisation object is added or removed.

remarks: <freeform>
Contains remarks.

role: <role-name>
Specifies the full name of a role entity, e.g. RIPE DBM.

role-name: <role-name>

Specifies the name of the role in the RIPE Database. This is an ASCII-only text attribute. This restriction is because the attribute is a look-up key and the RIPE Database protocol does not allow specifying character sets in queries. Any use of non-ASCII characters in any object may cause problems during the update process.

route: <address-prefix>
Specifies the prefix of the interAS route. Together with the "origin:" attribute, it constitutes a primary key of the route object.

route6: <ipv6-address>/<prefix-length>
Specifies an IPv6 prefix. The <prefix length> is an integer in the range from 0 to 128. This is the prefix of the interAS route. Together with the "origin:" attribute, it constitutes a primary key of the route6 object.

route-set: <object-name>
Specifies the name of the route set. It is a primary key for the route-set object. Please refer to RPSL RFC 2622 (opens new window) for more information.

rtr-set: <object-name>
Defines the name of the rtr-set. Please refer to RPSL RFC 2622 (opens new window) for more information.

signature: PGPKEY-<id>
References a key-cert object representing a CSIRT public key used by the team to sign their correspondence. <id> is the key-id of the PGP public key in eight-digit hexadecimal format without "0x" prefix.

source: <registry-name>
Specifies the registry where the object is registered. This should be "RIPE" for the RIPE Database.

status: <status>
Specifies the status of the address range represented by an inetnum or inet6num object or the status of an AS Number represented by an aut-num object. For the possible values, see the sections 'Description of the INETNUM Object', 'Description of the INET6NUM Object' and 'Description of the AUT-NUM Object'.

Please refer to the RIPE Document ripe-622, "IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region" (opens new window), for further information.

tech-c: <nic-handle>
References a technical contact.

text: <freeform>
Contains text of the poem. Should be humorous, but must not be malicious or insulting.

upd-to: <e-mail>
Specifies the email address to be notified when an object protected by a mntner is unsuccessfully updated. See also the section, 'Notifications''.

zone-c: <nic-handle>
References a zone contact.

# Appendix B- Copyright Statement

Copyright (c) 1992-2022 the Réseaux IP Européens Network Coordination Centre RIPE NCC. All rights restricted.

This documentation can be used externally for research, educational and other non-commercial purposes.

If you want to use these materials for advertising, marketing or other commercial purposes, please get in touch with us first at ncc@ripe.net

For more information, please see our Copyright Statement (opens new window).

# Appendix C- RIPE Database Query Server Response Codes and Messages

If the server encounters a problem, an error message is returned as a query result. The format of an error message is as follows:

%ERROR:#:<message>,

where # is the error or response code and <message> is a short description of the problem. There are no white spaces in this line, except in the <message> string. This maybe followed by a more descriptive message, each line of which starts with % followed by a white space and some text.

Example:

% This is the RIPE Database query server. 
% The objects are in RPSL format. 
%
% The RIPE Database is subject to Terms and Conditions.  
% See http://www.ripe.net/db/support/db-terms-conditions.pdf 
%ERROR:101: no entries found  
%  
% No entries found in the selected source(s).

# Query Errors

%ERROR:101: no entries found No entries were found in the selected source(s).

%ERROR:102: unknown source Unknown source was supplied as argument to the -s query ag. Use -q sources for a list of available sources.

%ERROR:103: unknown object type Unknown object type is specified as an argument to the -T query flag.

%ERROR:104: unknown attribute Unknown argument is specified to the inverse query flag (-I). See Queryingthe RIPE Database for more information.

%ERROR:105: attribute is not searchable The argument specified for the inverse query flag is not a searchable attribute. See Queryingthe RIPE Database for more information.

%ERROR:106: no query argument specified No query argument has been specified in the query.

%ERROR:107: input line too long Input exceeds the maximum line length.

%ERROR:108: bad character in input An invalid character was passed in the query. The only allowed characters are letters,numbers and -_:+=.,@/?'

%ERROR:109: invalid combination of flags passed The specified query flags cannot be included in the same query.

%ERROR:110: multiple use of flag The same flag cannot be used multiple times.

%ERROR:111: invalid option supplied Query flag that does not exist was given. Use the help query to see the valid options.

%ERROR:112: unsupported query -mM query options are not allowed on very large ranges/prefixes.

%ERROR:114: unsupported query Search key doesn't match any known query types.

%ERROR:115: invalid search key Search key entered is not valid for the specified object type(s).

%ERROR:116: unsupported query Versions are not supported for PERSON/ROLE objects.

%ERROR:117: version cannot exceed X for this object Versions are numbers greater or equal to 1 but cannot exceed the object's current version number.

# Access Errors

%ERROR:201: access denied Access from the host has been temporarily or permanently denied because of excessive querying. You should contact a customer service representative (opens new window) to discuss this problem.

%ERROR:202: access control limit reached Limit of returned objects has been reached. The connection is terminated. Continued attempts to excessively query the database will result in permanent denial of service. See section Access Control for Queries for more information.

%ERROR:203: address passing not allowed The host is not registered as a proxy and is not allowed to pass addresses on the query line (-V ag). See section Access Control for Queries for more information.

# Connection Errors

%ERROR:301: connection has been closed The connection is administratively or abnormally closed.

%ERROR:302: referral timeout The connection was closed due to referral timeout.

%ERROR:303: no referral host Referral host cannot be found.

%ERROR:304: referral host not responding The connection to the referral host cannot be established.

%ERROR:305: connection has been closed The connection to the server has been closed after a period of inactivity.

%ERROR:306: connections exceeded Number of connections from a single IP address has exceeded the maximum number allowed.

# NRTM Errors

%ERROR:401: invalid range: Not within <rst>-<last> This happens when the requested range or part of it is outside the serial numbers available at the server. <rst> is the lowest serial number available. <Last> is the most recent serial number available.

# Warnings

%WARNING:901: duplicate IP ags passed More than one IP flag (-x, -M, -m, -L, -l, -c, or -b) was passed to the server. Only the last one in the list of query flags will be used for this query.

%WARNING:902: useless IP flag passed An IP flag (-x, -M, -m, -L, -l, -c, or -b) was passed to the server when query did not include an IP key as the argument.

# Route Object Creation Flowchart

flowchart TB A[Begin]:::initLastNodes --> B{Is there an exact <br> match route?}:::decisionNodes B --> |Yes| C{Does exact match route <br> have 'mnt-routes'?}:::decisionNodes B --> |No| D{Is there a less <br> specific route?}:::decisionNodes C --> |No| F[Check authorisation using maintainers <br> in 'mnt-by' of exact match route]:::operationNodes C --> |Yes| E[Check authorisation using maintainers <br> in 'mnt-routes']:::operationNodes D --> |Yes| G{Does less specific route <br> have 'mnt-routes'?}:::decisionNodes D --> |No| H{Is there an exact <br> match inetnum?}:::decisionNodes G --> |Yes| E[Check authorisation using maintainers <br> in 'mnt-routes']:::operationNodes G --> |No| I{Does less specific route <br> have 'mnt-lower'?}:::decisionNodes I --> |Yes| J[Check authorisation using maintainers <br> in 'mnt-lower']:::operationNodes I --> |No| K[Check authorisation using maintainers <br> in of less specific route]:::operationNodes H --> |Yes| L{Does exact match inetnum <br> have 'mnt-routes'?}:::decisionNodes H --> |No| M{Is there a less <br> specific inetnum?}:::decisionNodes L --> |No| N[Check the authorisation using <br> the maintainers in 'mnt-by']:::operationNodes L --> |Yes| O[Check authorisation using maintainers <br> in 'mnt-routes']:::operationNodes M --> |Yes| P{Does less specific inetnum <br> have 'mnt-routers'?}:::decisionNodes M --> |No| Q[Reject creation]:::initLastNodes P --> |Yes| O[Check authorisation using maintainers <br> in 'mnt-routes']:::operationNodes P --> |No| R{Does less specific inetnum <br> have 'mnt-lower'?}:::decisionNodes R --> |No| S[Check the authorisation using <br> the maintainers in 'mnt-by']:::operationNodes R --> |Yes| T[Check the authorisation using <br> the maintainers in 'mnt-lower']:::operationNodes F --> U{Authorisation successful?}:::decisionNodes E --> U J --> U K --> U N --> U O --> U S --> U T --> U U --> |Yes| V[Go to authorisation check from route object itself]:::initLastNodes U --> |No| Q %% Class Definitions %% ================= classDef initLastNodes fill:#a4a1c4,stroke:#9b96cf,stroke-width:4px classDef decisionNodes fill:#00e4b8,stroke:#00b693,stroke-width:4px classDef operationNodes fill:#bbb4ff,stroke:#c2bcff,stroke-width:4px

# Domain Object Creation Flowchart

flowchart TB A[Begin]:::initLastNodes --> B{Is there an exact <br> match inetnum?}:::decisionNodes B --> |Yes| C[I=matching <br> inetnum?]:::operationNodes B --> |No| D{Is there a less <br> specific inetnum?}:::decisionNodes C --> E{Does 'I' have <br> 'mnt-domains:'?}:::decisionNodes D --> |Yes| C D --> |No| F{Is there a less <br> specific domain?}:::decisionNodes E --> |Yes| G[Check the authorisation <br> using the maintainers <br> mentioned in the 'mnt-domains']:::operationNodes E --> |No| H{Does 'I' have <br> 'mnt-lower:'?}:::decisionNodes F --> |Yes| I[D=matching domain]:::operationNodes F --> |No| J{reject creation}:::initLastNodes G --> K{Is the <br> authorisation successful?}:::decisionNodes H --> |Yes| L[Check the authorisation <br> using the maintainers <br> mentioned in 'mnt-lower']:::operationNodes H --> |No| M[Check the authorisation <br> using the maintainers <br> mentioned in 'mnt-by']:::operationNodes I --> N{Does 'D' have 'mnt -lower'?}:::decisionNodes K --> |Yes| O{accept creation}:::initLastNodes K --> |No| F L --> K M --> K N --> |Yes| P[check the authorisation <br> using the maintainers <br> mentioned in 'mnt-lower']:::operationNodes N --> |No| Q{Does 'D' have 'mnt-by:'?}:::decisionNodes P --> R{Is the authorisation <br> successful?}:::decisionNodes Q --> |Yes| S[Check the authorisation <br> using the maintainers <br> mentioned in 'mnt-by']:::operationNodes Q --> |No| J R --> |Yes| O R --> |No| J S --> R %% Class Definitions %% ================= classDef initLastNodes fill:#a4a1c4,stroke:#9b96cf,stroke-width:4px classDef decisionNodes fill:#00e4b8,stroke:#00b693,stroke-width:4px classDef operationNodes fill:#bbb4ff,stroke:#c2bcff,stroke-width:4px

# Appendix F- Special Considerations for Object Types

This is a list of actions required of the Maintainer in a situation where one of the following object types references the person object to be removed and:

  • This is the only person or role object referenced in the object.
  • There are no options available for changing the reference.

Forward domain
This is a Top-Level Domain (TLD) problem. If the TLD is not responsive, the TLD should remove its data from the RIPE Database.

Reverse domain
These objects should be deleted and removed from the DNS system.

inet(6)num
The address space must be returned to the appropriate Internet Registry and then the object can be deleted.

The RIPE NCC will take no action until the Data Subject has cancelled any routing arrangements for the address space to be returned and any related route(6) objects have been deleted.

aut-num
These objects should be deleted.

The RIPE NCC will take no action until the Data Subject has cancelled any routing arrangements where this AS number is the origin and any related route(6) objects have been deleted.

role
If the role object only references this one person object, find all the references to the role object and consider them as if they were direct references to the person object.

mntner
Find all objects that reference this mntner object and carry out the following actions on each of these objects:

  • Where there are references to more than one mntner object in the same attribute type, remove the reference to this mntner object.
  • If it is referenced in an optional attribute, remove the attribute.
  • Where an object references only this mntner object in a single instance of a mandatory attribute, consider this object as if it had a single reference to the person object to be deleted. This object may also need to be deleted and then follow the chain of references to this object and handle all referencing objects according to this list.

When all references to the mntner object have been removed, delete the mntner object.

key-cert
References to person objects are optional, so remove any reference to this person object from the key-cert object.

irt
Remove references to this irt object from inet(6)num objects, then delete the irt object.

organisation
References to person objects are optional, so remove any reference to this person object from the organisation object.

# Appendix G- Object Types with Personal Data

Personal Contact Details are only held in these object types:

  • person
  • role
  • organisation
  • irt

Role object references can be replaced by one or more of the person objects it references.

Organisation object references are optional everywhere except in inetnum objects with a status of ALLOCATED. References to organisation objects can simply be removed from anywhere else.

Irt object references are all optional. These references can also simply be removed.

In all cases, the role, organisation and irt object can then be deleted when there are no references to it.

Person objects are discussed in detail in this procedure.

# Appendix H- PGP Authentication Method

In this section, we provide an example of the PGP authentication method. For this example we will start from the beginning, supposing that there is no a previous mntner object created.

  • Create the first mntner and role object.
  • Install gpg or a similar tool. In this example, gpg will be used. brew install gpg
  • Run the next command to create public and private key gpg --gen-key. The output of this command should contain the next piece of text:
    pub   ed25519 2024-05-03 [SC] [expires: 2027-05-03]
6A9DFE0F2C9239EF07CADA4A4BD32D1CF9C96367
  • Before creating the key-cert object gpg --export --armor 6A9DFE0F2C9239EF07CADA4A4BD32D1CF9C96367 need to be executed. This command will export the public key in plain text.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: GPGTools - http://gpgtools.org
mDMEZjSZDRYJKwYBBAHaRw8BAQdABOx/dcn6Ask5cni3zdKtiYgOG1VN3QQLHQ1c
iz16UQO0HFRlc3QgVXNlciA8bm9yZXBseUByaXBlLm5ldD6ImQQTFgoAQRYhBGqd
/g8skjnvB8raSkvTLRz5yWNnBQJmNJkNAhsDBQkFo5qABQsJCAcCAiICBhUKCQgL
AgQWAgMBAh4HAheAAAoJEEvTLRz5yWNn1YgA/3NEr9/vNPVeCr0NVh9I0DVucTbk
qNwzDy/6Fs81GxvNAP4vJq3n5S9hTFY0aQCZ4mjYXzrDHcJaY+ZKKJcIilesALg4
BGY0mQ0SCisGAQQBl1UBBQEBB0DwPQN5sgVdMCVtCYtQ1UBSq35V1VbiN5MKRT3T
P3hCAAMBCAeIfgQYFgoAJhYhBGqd/g8skjnvB8raSkvTLRz5yWNnBQJmNJkNAhsM
BQkFo5qAAAoJEEvTLRz5yWNnUfMBALG5vIKAJ2msltAPoECQuFmjB6HxFh2HX6vE
os2DfBlmAP9VdqYSQAdqzoQcUWS8j+AIkmmGe/wzKRg3lVEjX6CMBg==
=XknZ
-----END PGP PUBLIC KEY BLOCK-----
  • Now is time to create the key-cert object. For that you can use one of the update methods. It is recommended to use the last 8 digits from the 6A9DFE0F2C9239EF07CADA4A4BD32D1CF9C96367 for "key-cert:" attribute. For example:
key-cert:        PGPKEY-F9C96367
certif:          -----BEGIN PGP PUBLIC KEY BLOCK-----
certif:          Comment: GPGTools - http://gpgtools.org
certif:
certif:          mDMEZjSZDRYJKwYBBAHaRw8BAQdABOx/dcn6Ask5cni3zdKtiYgOG1VN3QQLHQ1c
certif:          iz16UQO0HFRlc3QgVXNlciA8bm9yZXBseUByaXBlLm5ldD6ImQQTFgoAQRYhBGqd
certif:          /g8skjnvB8raSkvTLRz5yWNnBQJmNJkNAhsDBQkFo5qABQsJCAcCAiICBhUKCQgL
certif:          AgQWAgMBAh4HAheAAAoJEEvTLRz5yWNn1YgA/3NEr9/vNPVeCr0NVh9I0DVucTbk
certif:          qNwzDy/6Fs81GxvNAP4vJq3n5S9hTFY0aQCZ4mjYXzrDHcJaY+ZKKJcIilesALg4
certif:          BGY0mQ0SCisGAQQBl1UBBQEBB0DwPQN5sgVdMCVtCYtQ1UBSq35V1VbiN5MKRT3T
certif:          P3hCAAMBCAeIfgQYFgoAJhYhBGqd/g8skjnvB8raSkvTLRz5yWNnBQJmNJkNAhsM
certif:          BQkFo5qAAAoJEEvTLRz5yWNnUfMBALG5vIKAJ2msltAPoECQuFmjB6HxFh2HX6vE
certif:          os2DfBlmAP9VdqYSQAdqzoQcUWS8j+AIkmmGe/wzKRg3lVEjX6CMBg==
certif:          =XknZ
certif:          -----END PGP PUBLIC KEY BLOCK-----
mnt-by:          ***-MNT
notify:          ***@ripe.net
created:         2013-12-10T17:02:02Z
last-modified:   2019-09-09T15:24:06Z
source:          RIPE
password: *****-MNT
  • Once the key-cert object is created you need to update your previous mntner object adding a new "auth:" attribute pointing to the created key-cert.
  • Finally, now that the key-cert object is created and associated with the mntner. The last step is to perform an update authenticated with the key-cert object. In this example syncupdates is used for it.
    • You need to create a file with the updated object.
    • This file must be signed by your private key running the next command: gpg --clearsign --armor --default-key F9C96367 file. This command will generate an .asc.
    gpg: using "F9C96367" as default secret key for signing
edtop:~ $
edtop:~ $ cat file.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
person:          Name Removed
address:         ***UPDATED***
address:         ***
address:         The Netherlands
e-mail:          ***@nonexistant.org
phone:           +31 20 ... ....
remarks:         ***
remarks:         ***
remarks:         ***
remarks:         ***
remarks:         ***
nic-hdl:         ****-RIPE
mnt-by:          ****-MNT
created:         2013-12-10T16:54:20Z
last-modified:   2023-09-06T14:47:15Z
source:          RIPE
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iHUEARYKAB0WIQRqnf4PLJI57wfK2kpL0y0c+cljZwUCZjSZ8QAKCRBL0y0c+clj
Z93+AQCrvZZzcRHh8m8vj9a0Byea41xcthfKP11CQt5tmBR1ggEA4mSgCaMpClSu
Wbpg95npLZo+LQB7PdK4Fb+ydsewGA0=
=Hc7R
-----END PGP SIGNATURE-----
    • The last step is to perform the update, in this example curl is used: curl -v --data-urlencode DATA@file.asc https://syncupdates.db.ripe.net. Whois will authenticate this signature using the public key in the key-cert object.

# Appendix I- Client Certificate Authentication

In this section, we provide an example of how to use client certificate authentication to make a Whois Update via the REST API.

One advantage of this method is that no secret is shared with the Whois server during the request. However, one drawback is that getting started is more complicated than other authentication methods.

# Generate a Self-signed Certificate

First generate a self-signed x509 certificate using OpenSSL, along with a private key, in a single step.

$ openssl req -x509 -days 365 -newkey rsa:4096 -sha384 -subj "/C=NL/CN=ripe.net" -keyout client-key.pem -nodes -out client-cert.pem

A signed x509 certificate from a Certificate Authority can also be used, but Whois does not verify the trust path to the CA, only the signature against the certificate.

# Convert Certificate to ASCII

Next display the certificate as ASCII, which is a base64 encoded version of the binary (PEM) certificate file, which is necessary to create a key-cert object.

$ openssl x509 -in client-cert.pem
-----BEGIN CERTIFICATE-----
MIIFITCCAwmgAwIBAgIUHD8QpV+IvEVs/pDVK3Ml63TNJUgwDQYJKoZIhvcNAQEM
BQAwIDELMAkGA1UEBhMCTkwxETAPBgNVBAMMCHJpcGUubmV0MB4XDTI0MDUxNDEz
NDQyNloXDTI1MDUxNDEzNDQyNlowIDELMAkGA1UEBhMCTkwxETAPBgNVBAMMCHJp
cGUubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAssEU+sbcX9YB
UH/qX9qbF63elLlLmYFZ2LR119qgqQqYQURO6onCimEJFlbL90c7TDkRcBoyMtzm
KP3kSuiIWOZpxGcmUtGnoiry9q5thxp60lZNad/Yi59PyTrs8DRo24ebPSKCa1FS
edpFYwP1b0o61ipDARGldx0qtbSXZOujxgicQTZxLjakMUKltjLczGN6lXpblM0a
vZNbL6tTNan3p5Y/0gAVBtvEQtAc0z2wqmzpWPmXmOs1nucIqRUlJoHwecmSN3zf
1lYwFn+baDOQpTo6oFttZYJfhWFvWLEKDw1nscvPeq0q9/yHVJpi54L7osPb/P0P
mI1CTtROe6fG5+zshHxolqdWNwdOJ1q1+/tMglzWq6NOpf5ZBK06wUrdygNl5Adi
7ToxNmFA1OUD8bx2FxyAEzByEOm46NOeNLwszn1hoTvtm1hJ7TAMKCnHbyEF67qh
uY6f8mJzeYO6PWTIl90vz2HCYcN9Ij6M4dsQA/w52kQ7Wld1xpRacaCVK+hC0W1J
lZeHaqCbwdfa4jgVXOGFrnnwU8Iy5H7b4U3ukx5hT9aq6mGA6W9VxcYRuArtlU1f
9iPYRtAVOebHnW6FNGdyGmoeofqOsZoXI21J8vq2o4JEEsz1vu+JtNgBcat7buYt
bUHrbF840tWsA8IgzMiQkIkfzy9meA8CAwEAAaNTMFEwHQYDVR0OBBYEFFLJKFpY
3vmlUVaQ9qgo59QRodfuMB8GA1UdIwQYMBaAFFLJKFpY3vmlUVaQ9qgo59QRodfu
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEMBQADggIBAIX+S5jwBueCo3Ka
u+sqCr5eP2DZKmTrUEJPf5NW0k5FBKtmVzkBDXobL7ipctmlmehvEzF9gLgLJhnL
lekKdyWrgbunHTfeRFl1jxC8js1p4t9BNQ+wpqgom8/V1F9pNRGDzVDS5arok0OU
xoAThRqS22DX6JMSDmvTF/DnRZ71j1quLf7eUVjdLA8J1Dwvz4YfiYseQEvGAxvY
u3+ZrA1qScImHv1WERETskiAjy5GxpxMW19WIZtBJ3d3QTo4wIrsd050F9ecF2Zs
Up7/pcv+vNxr/TgfO1l9yuJzzDJyklaumkeOwWvqHz/t6SIisgxAMMFlvAiYvYgC
uh3UHrPEVG/x4Z5RNBqSb+7Mk08jGrVj5qUhtD6FyeJ53uOM1jQQEAZ+G1zsZZzw
x80fSveD5QXj5pzgzLvP0nlk3m5cJEu4FILtzVol1TX4QQXDdeYOCwNK2393ac56
vCxGxD4oqaYyZa3FzOrjWSDlBwhynd+OCq2PvIw7wLIYxq7UuZ77W3QL6/LRRzrs
X17yf8Ux8feNJwKke/L3mq6QBZ9wzoadK+XjTQYWQCbj6WlH9QEYpmFS/XCz5kfQ
sUI9iChbKvcWOFFPID+XMbzKMgbSvP6aBzOhbUz3b9Tn4qfn9Yp2YWpPci7RrvlK
lECvj7YuYAysqbZKiulSN6N3OKHd
-----END CERTIFICATE-----

# Create Key-cert Object

Next use the ASCII encoded certificate to create a key-cert object in the RIPE database, using Syncupdates or Mailupdates. Use "AUTO-1" as a placeholder for the primary key.

key-cert:        AUTO-1   
certif: -----BEGIN CERTIFICATE-----
certif: MIIFITCCAwmgAwIBAgIUHD8QpV+IvEVs/pDVK3Ml63TNJUgwDQYJKoZIhvcNAQEM
certif: BQAwIDELMAkGA1UEBhMCTkwxETAPBgNVBAMMCHJpcGUubmV0MB4XDTI0MDUxNDEz
certif: NDQyNloXDTI1MDUxNDEzNDQyNlowIDELMAkGA1UEBhMCTkwxETAPBgNVBAMMCHJp
certif: cGUubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAssEU+sbcX9YB
certif: UH/qX9qbF63elLlLmYFZ2LR119qgqQqYQURO6onCimEJFlbL90c7TDkRcBoyMtzm
certif: KP3kSuiIWOZpxGcmUtGnoiry9q5thxp60lZNad/Yi59PyTrs8DRo24ebPSKCa1FS
certif: edpFYwP1b0o61ipDARGldx0qtbSXZOujxgicQTZxLjakMUKltjLczGN6lXpblM0a
certif: vZNbL6tTNan3p5Y/0gAVBtvEQtAc0z2wqmzpWPmXmOs1nucIqRUlJoHwecmSN3zf
certif: 1lYwFn+baDOQpTo6oFttZYJfhWFvWLEKDw1nscvPeq0q9/yHVJpi54L7osPb/P0P
certif: mI1CTtROe6fG5+zshHxolqdWNwdOJ1q1+/tMglzWq6NOpf5ZBK06wUrdygNl5Adi
certif: 7ToxNmFA1OUD8bx2FxyAEzByEOm46NOeNLwszn1hoTvtm1hJ7TAMKCnHbyEF67qh
certif: uY6f8mJzeYO6PWTIl90vz2HCYcN9Ij6M4dsQA/w52kQ7Wld1xpRacaCVK+hC0W1J
certif: lZeHaqCbwdfa4jgVXOGFrnnwU8Iy5H7b4U3ukx5hT9aq6mGA6W9VxcYRuArtlU1f
certif: 9iPYRtAVOebHnW6FNGdyGmoeofqOsZoXI21J8vq2o4JEEsz1vu+JtNgBcat7buYt
certif: bUHrbF840tWsA8IgzMiQkIkfzy9meA8CAwEAAaNTMFEwHQYDVR0OBBYEFFLJKFpY
certif: 3vmlUVaQ9qgo59QRodfuMB8GA1UdIwQYMBaAFFLJKFpY3vmlUVaQ9qgo59QRodfu
certif: MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEMBQADggIBAIX+S5jwBueCo3Ka
certif: u+sqCr5eP2DZKmTrUEJPf5NW0k5FBKtmVzkBDXobL7ipctmlmehvEzF9gLgLJhnL
certif: lekKdyWrgbunHTfeRFl1jxC8js1p4t9BNQ+wpqgom8/V1F9pNRGDzVDS5arok0OU
certif: xoAThRqS22DX6JMSDmvTF/DnRZ71j1quLf7eUVjdLA8J1Dwvz4YfiYseQEvGAxvY
certif: u3+ZrA1qScImHv1WERETskiAjy5GxpxMW19WIZtBJ3d3QTo4wIrsd050F9ecF2Zs
certif: Up7/pcv+vNxr/TgfO1l9yuJzzDJyklaumkeOwWvqHz/t6SIisgxAMMFlvAiYvYgC
certif: uh3UHrPEVG/x4Z5RNBqSb+7Mk08jGrVj5qUhtD6FyeJ53uOM1jQQEAZ+G1zsZZzw
certif: x80fSveD5QXj5pzgzLvP0nlk3m5cJEu4FILtzVol1TX4QQXDdeYOCwNK2393ac56
certif: vCxGxD4oqaYyZa3FzOrjWSDlBwhynd+OCq2PvIw7wLIYxq7UuZ77W3QL6/LRRzrs
certif: X17yf8Ux8feNJwKke/L3mq6QBZ9wzoadK+XjTQYWQCbj6WlH9QEYpmFS/XCz5kfQ
certif: sUI9iChbKvcWOFFPID+XMbzKMgbSvP6aBzOhbUz3b9Tn4qfn9Yp2YWpPci7RrvlK
certif: lECvj7YuYAysqbZKiulSN6N3OKHd
certif: -----END CERTIFICATE-----
mnt-by: SHRYANE-MNT
source: RIPE

The generated primary key is returned in the response.

# Add Authentication Method to Maintainer

From the previous step, the created key-cert object has a generated primary key "X509-3571".

Now add the authentication method to the maintainer with an additional "auth:" attribute with a value "X509-3571", so the certificate can be used to authenticate updates as that maintainer.

# Lookup An Object

Now update an object using the certificate to authenticate.

First lookup a PERSON object ES7554-RIPE as JSON and save to file.json. You must use the unfiltered query parameter to request the full object including attributes that may contain personal data.

$ curl -o file.json https://rest.db.ripe.net/ripe/person/ES7554-RIPE.json?unfiltered

You can also authenticate a MNTNER lookup with a client certificate, which will return the mntner including full auth: attribute values. Be sure to also include the unfiltered query parameter to return attributes that may contain personal data.

$ curl -o file.json --key client-key.pem --cert client-cert.pem https://rest-cert.db.ripe.net/ripe/person/ES7554-RIPE.json?unfiltered

# Update An Object

Next modify the remarks: attribute value in file.json and submit an update, authenticating with the client certificate.

$ curl -v --header "Content-type: application/json" -d @file.json -X PUT --key client-key.pem --cert client-cert.pem https://rest-cert.db.ripe.net/ripe/person/ES7554-RIPE.json

The PERSON object has been updated successfully.

# Appendix J- Ripe Test Database

# Introduction

The RIPE NCC has a test database where users may learn how to use the software. This database uses the same software as the RIPE Database, but is completely separate. You cannot change anything in the RIPE Database by changing an object in the TEST database.

The data in the TEST database is not a copy of the data in the RIPE Database. Also, it is not authoritative data. No value should be put on the data in the TEST database. The database is reset to a default state each night.

You can create objects in the TEST database to simulate a part of your real network. You can then experiment with different situations in this TEST environment safely.

# Creating Objects in the TEST Database

There are different ways to create objects in the TEST database
Web interface For creating a single object using a form. Go to
https://apps-test.db.ripe.net/db-web-ui/#/webupdates/select
To get started, create a role and maintainer pair. Go to
https://apps-test.db.ripe.net/db-web-ui/webupdates/create/TEST/role/self
Mailupdates Email you object to test-dbm@ripe.net. You will receive an acknowledgement message with the result.
Syncupdates For creating one or more objects at a time, using a single field to edit objects. Go to https://apps-test.db.ripe.net/db-web-ui/syncupdates You can also submit updates from the command line (or script) via: https://syncupdates-test.db.ripe.net/
REST API Software API to create a single object at a time. Documented in whois rest api. The base URL for the TEST environment is https://rest-test.db.ripe.net/test

# Finding Objects in the TEST Database

There are different ways to find objects in the TEST database
Web interface Go to https://apps-test.db.ripe.net/db-web-ui/query
Command line Do
whois -h whois-test.ripe.net <Search String>
e.g.
whois -h whois-test.ripe.net PB3-RIPE
The query flags that work in the RIPE Database also work in the TEST Database. We invite you to try them.
REST API Software API to search Whois or lookup a single object. Documented in whois rest api

# MNTNER Objects in the TEST Database

You can create your own mntner objects in the TEST database. This mntner object only maintains objects in the TEST database.

These are different ways to create a mntner object in the TEST database.
Web interface To create a single object (choose mntner from the dropdown):
(a) Go to https://apps-test.db.ripe.net/db-web-ui/webupdates/select
(b) Choose mntner from the dropdown and click Create
(c) Complete the form and click Submit
REST API Software API to create, update or delete a single object. Documented in whois rest api
Mailupdates (a) complete (fill in) a mntner object template
(b) email the completed template to test-dbm@ripe.net.
(c) You will receive an email reply with the result.

There are some RIPE NCC maintainers in the TEST database which can be used for authentication.
TEST-DBM-MNT Maintainer for TEST DBM objects. The maintainer password is "emptypassword" without the quotes.
TEST-NCC-HM-MNT Hostmaster maintainer. The maintainer password is "emptypassword" without the quotes.

# Creating INETNUM Allocations in the TEST Database

For this example, use the web interface (opens new window) to create an inetnum.

If you did not create your own mntner object, please use TEST-NCC-HM-MNT as the mntner of the inetnum.

After typing in the inetnum field value, you will be prompted to choose a mntner to authenticate the update operation. Choose TEST-DBM-MNT and deselect the checkmark that says "Also authorise my RIPE NCC Access account for this maintainer".

For example, create an inetnum with a /21 prefix in the 2/8 range.

The “org:” (organisation) attribute is required for an inetnum object with the status ‘ALLOCATED PA’ or ‘ALLOCATED PI’. The mntner password for the organisation "mnt-ref:" attribute must be known in order to make a reference to the organisation. The organisation object must have an "org-type:" attribute with the value ‘LIR’ for the 'ALLOCATED PA' status (for example, use ORG-EIPB1-TEST as an LIR and authenticate with the TEST-DBM-MNT password).

# Creating AUT-NUM Objects in the TEST Database

Aut-num objects in the RIPE database are only assigned by the RIPE NCC. However, you are free to create aut-num objects in the TEST database.

You can create an aut-num object from create an Object (opens new window) page.

You can also create an aut-num object using the Syncupdates (opens new window).

You need to authenticate with the TEST-DBM-MNT password, which maintains the root as-block object.

# Creating Route Objects

For this example, use the web interface (opens new window) to create a pair role and maintainer.

You need to create an LIR organisation (opens new window) as well. Normally LIR organisations are created by the RIPE NCC for a member. Only an LIR organisation can be referenced from an allocation. Use your newly created role (e.g TR1-TEST) as the admin-c and tech-c. Use your newly created mntner (e.g. TESTMNT-MNT) as the mnt-by.

You can also create the organisation using the Syncupdates (opens new window). e.g.:

organisation:    AUTO-1
org-name:        Test Organisation
org-type:        LIR
address:        Amsterdam
e-mail:         eshryane@ripe.net
admin-c:         TR1-TEST
tech-c:          TR1-TEST
mnt-ref:         TESTMNT-MNT
mnt-by:          TEST-NCC-HM-MNT
mnt-by:          TESTMNT-MNT
source:          TEST
password: emptypassword

After creating the organisation you need to create an allocation (opens new window). Normally the allocations are created by the RIPE NCC for a member organisation. You need some address space before creating a route object. Use your new organisation (e.g. ORG-TO2-TEST) as your "org:" reference

You can also create the allocation using the Syncupdates (opens new window). e.g.:

inetnum:         11.0.0.0 - 11.0.0.255
netname:         NL-TEST
country:         NL
org:               ORG-TO2-TEST
admin-c:         TR1-TEST
tech-c:          TR1-TEST
status:          ALLOCATED PA
mnt-by:     TEST-NCC-HM-MNT
mnt-by:          TESTMNT-MNT
source:          TEST
password: emptypassword

Finally, you can create the route object (opens new window) in the address space that you have just allocated.

You can also create the route object using the Syncupdates (opens new window). e.g.:

route:           11.0.0.0/24
origin:          AS3333
descr:           route
mnt-by:          TESTMNT-MNT
source:          TEST

# Authorisation

Authorisation in the RIPE Database is based on the Routing Policy System Security (RPSS) that is explained in more detail in RFC 2725 (opens new window).

  • Authorisation - The power or right to make decisions and have access. This can be delegated.
  • Authentication - To ensure that the entity making use of the authorisation is what or who it claims to be.
  • Credential - Something that shows an entity has a right to exercise authorisation, providing the basis for confidence.

These three words are often confused. When talking about the RIPE Database, an authenticated person may be granted or given a credential by a system administrator or official contact, authorising this person to access and manage objects in the database.

Different types of objects in the database require different levels of protection. The server supports multiple authorisation methods. Because of the data model used by the RIPE Database, it is not always possible to identify who is making an update. The mntner objects only hold credentials – for example, encrypted password hashes or references to cryptographic keys. There is no connection between many of these credentials and any identifiable person.

In order to make the password tokens a more secure form of protection, the encrypted hashes are hidden from public view. A query on a mntner object will have any password hashes removed in the query result. These hashes can only be seen if you can supply the clear text password as part of the query. The only way to do this via the Webupdates form.

# 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 Method Description
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.

Example:

auth: MD5-PW $1$abcd4321$HyM/GVhPqXkkIMVerxxQ3z
PGPKEY This 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
SSO This 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 (opens new window).

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
X.509 This is similar to PGP. You ned 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 froma 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:

SSO PGP MD5
Webupdates (Web interface) Yes No Yes*
Email No Yes Yes*
API No No Yes
Syncupdates No Yes Yes*

*It works, but is not recommended

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

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.

# Force Delete Functionality

Force delete allows you to delete inet(6)num, route(6) and domain objects by using the maintainer of a covering address space object, instead of the maintainer of the object itself. This means the "mnt-lower:" of an allocation or the "mnt-by:" of a provider independent (PI) or anycast assignment or legacy under contract, each have the authority to force delete any more specific or related object.

In some cases it can occur that objects in the RIPE Database that fall under your address space have a maintainer that you do not control. For example, when you give joint control over an object to another user by using their "mnt-by:", you and the other party now have equal permissions. Now they have the ability to remove your maintainer from the object and take complete control. Another common issue is where an existing route object blocks the creation of a new exact matching route object.

Force delete allows you to remove these objects even though you do not have the credentials for the maintainer on them. Instead, you can use the maintainer of the covering address space object, i.e. the "mnt-lower:" of the allocation or the "mnt-by:" of the PI or anycast assignment or legacy under contract.

There are very strict rules about which objects can be force deleted and whose authorisation is allowed to override the object's authorisation. Also keep in mind that it is only possible to delete objects: modifying them is not possible.

# Authorisation to Force Delete

Normally an object can only be deleted if the operation is authorised by one of the mntner objects in the "mnt-by:" attributes of the object to be deleted. With force delete, the RIPE Database also looks for the exact match, encompassing, or less specific address space object that was allocated or assigned by the RIPE NCC.

The result is that in addition to the "mnt-by:" attribute of the object itself, the "mnt-lower:" of an allocation or the "mnt-by:" of a PI or anycast assignment or legacy under contract, each have the authority to force delete any more specific or related primary object.

# Example of Force Delete

The force delete functionality only applies to holders of resources that are issued directly by the RIPE NCC. In the example below, the mntner object LIR-MNT can authorise the deletion of any of the objects shown, except for the allocation object itself. The holder of a sub-allocation does not have the authority to delete an assignment from that sub-allocation. So in this example, SUB-MNT cannot be used to delete the ASSIGNED PA block.

The same applies to the route and domain object in this example. Even though they fall under the sub-allocation, SUB-MNT cannot be used. Only LIR-MNT can force delete these objects.

ALLOCATED PA  
inetnum: 10.128.0.0 - 10.128.255.255  
mnt-by: RIPE-NCC-HM-MNT  
mnt-lower: LIR-MNT  
mnt-routes: LIR-RT-MNT  
SUB-ALLOCATED PA  
inetnum: 10.128.0.0 - 10.128.127.255  
mnt-by: SUB-MNT  
mnt-lower: SUB-MNT  
route: 10.128.0.0 - 10.128.127.255  
origin: AS3333  
mnt-by: AS3333-MNT  
ASSIGNED PA  
inetnum: 10.128.1.0 - 10.128.1.255  
mnt-by: END-MNT  
domain: 1.128.10.in-addr.arpa  
mnt-by: END-MNT

# Objects that can be Force Deleted

Not all object types can be force deleted by a resource holder. Only the following primary object types are covered by this functionality:

  • inetnum
  • inet6num
  • route
  • route6
  • domain

For inetnum and inet6num object types, all objects more specific to an allocation made by the RIPE NCC are included, regardless of their status. The parent allocation object itself is not included as it is managed by the RIPE NCC. Objects related to PI assignments are included but, again, the PI assignments themselves are not included as they are assigned by the RIPE NCC. Therefore, a resource holder cannot accidentally delete their own resource object.

For route and route6 object types, any route(6) objects with a prefix exactly matching or more specific to any resource allocated or assigned by the RIPE NCC are included. Multiple route(6) objects with the same prefix, and different origins, are all included.

Reverse delegation domain objects, ending with ip6.arpa or in-addr.arpa, with a prefix exactly matching or more specific to any resource allocated or assigned by the RIPE NCC, are included. ENUM domain objects are not included.

Autonomous System Number objects are not included. These aut-num objects are resources assigned by the RIPE NCC and so can only be deleted by the RIPE NCC.

No secondary objects (for example person and role) are included, even if they are directly referenced by any of the primary objects listed above and so would be unreferenced after deleting the primary object.

# IRT Object

IRT: Incident Response Team - handles security incidents and/or cases of abuse of omputer networks or its components.

TI: Trusted Introducer - this service is a trustbroker for IRTs. More information (opens new window)

# How to Create an IRT Object

# Manual creation

# Requirements

If you are an IRT and want to create an irt object in the RIPE Database, you need to following:

  • A maintainer for that object. This should be a mntner object in the RIPE Database
  • A key-cert object in the RIPE Database containing a public PGP key
  • An IP address (range) for which you are responsible as an IRT. This should be in the form of an inet(6)num object in the RIPE Database.
  • Any other information that is mandatory for an irt object

# The Maintainer (MNTNER object)

A maintainer of an object in the RIPE Database is an entity, which can alone make changes to that object. A mntner object represents the maintainer. The maintainer authenticates change request either by using a PGP-Key, password or SSO account as specified in "auth:" attribute.

If you as a team are responsible for a range of IP addresses, there almost certainly will be an inet(6)num object in the database. The maintainer of this object can also maintain your irt object.

The RIPE NCC will not create a mntner object just for maintenance of an irt object.

# The PGP Key and the KEY-CERT Object

A PGP key for secure email communication is mandatory for an IRT to create an irt object. Before creating one, you will have to create a key-cert object matching your PGP key in the RIPE Database.

You can create one by sending a completed template by email to auto-dbm@ripe.net

Here is an example:

key-cert:     PGPKEY-6DFC4771
method:       PGP
owner:        DFN-CERT (2003), ENCRYPTION Key 
fingerpr:     E8 A7 18 F7 DF 3D 19 64  8D 26 C4 CC BF 2F 0C C4
certif:       -----BEGIN PGP PUBLIC KEY BLOCK-----
certif:       Version: PGP Key Server 0.9.5
certif:
certif:       mQENAz3SIaUAAAEIAKze7wWJ9BDa3iDcQpxZ9+YSVxq+j1prWPsnINMm8GyTMU2H
[...]
certif:       epPs4s0AnjV6ncb6BrbHiU+zeVY8tcW1bopeAJ0VuW0D/+3joueFiL7fDGSV6KPu
certif:       Uw==
certif:       =DKvl
certif:       -----END PGP PUBLIC KEY BLOCK-----
mnt-by:       TRUSTED-INTRODUCER-MNT
notify:       tiirt@stelvio.nl
notify:       dfncert@cert.dfn.de
source:       RIPE

As you can see, you also need a mntner for the key-cert object.

These are the fields of a key-cert object:

key-cert:       [mandatory]   [single]     [primary/lookup key]
method:         [generated]   [single]     [ ]
owner:          [generated]   [multiple]   [ ]
fingerpr:       [generated]   [single]     [inverse key]
certif:         [mandatory]   [multiple]   [ ]
org:            [optional]    [multiple]   [inverse key]
remarks:        [optional]    [multiple]   [ ]
notify:         [optional]    [multiple]   [inverse key]
admin-c:        [optional]    [multiple]   [inverse key]
tech-c:         [optional]    [multiple]   [inverse key]
mnt-by:         [mandatory]   [multiple]   [inverse key]
created:        [generated]   [single]     [ ]
last-modified:  [generated]   [single]     [ ]
source:         [mandatory]   [single]     [ ]

You can use the text above as a template.

# The Creation Process

You start the process of creating an irt object by sending a completed template by e-mail to the RIPE NCC. As creation of an irt object is a manual process, you should address your email to ripe-dbm@ripe.net

In your mail, you need to explain why you want to create a new irt object. To prevent misuse of the object, the RIPE NCC will need to check your request, so include a full explanation. A good idea is the listing of the inet(6)num objects you, as an IRT, are responsible for and from which you want to link to from your new irt object.

You will get a reply from the RIPE NCC asking you to acknowledge your request.

# Creation Through the Trusted Introducer (TI) Service

You need to become a TI accredited team. The TI will register and maintain your IRT object.

Here is an example:

This is the body of an example e-mail with which the TI creates object for a newly accredited team:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
irt:        IRT-TCERT
address:    Telia AB, HQ
address:    TeliaCERT
address:    SE-123 86 Farsta
address:    Sweden
phone:      +46 8 713 1872
fax-no:     +46 706 175 101
e-mail:     tcert@telia.se
signature:  PGPKEY-D47485CF
encryption: PGPKEY-D47485CF
admin-c:    TI123-RIPE
tech-c:     TI123-RIPE
auth:       PGPKEY-D47485CF
remarks:    Emergency telephone number +46 8 713 1872 (GMT+1/GMT+2 with DST)
remarks:    http://www.trusted-introducer.org/teams/tcert.html
remarks:    This is an accredited IRT (level 2)
irt-nfy:    tcert@telia.se
notify:     tiirt@s-cure.nl
notify:     tcert@telia.se
mnt-by:     TRUSTED-INTRODUCER-MNT
source:     RIPE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32) - WinPT 0.5.13
iD8DBQE/O1yZHxjOrs1gxBcRAn5TAJ9lBL4op6txrM17m1SF1pIIjptTTgCcCt4n
P0fRecfQHzFxhvASPKfTt1Q=
=Q9fl
-----END PGP SIGNATURE-----

# Requirements

To link an inet(6)num object to an irt object you need:

  • The authorisation of the team the irt object belongs to
  • The authorisation of the maintainer of the inet(6)num object

Authorisation can be provided by a PGP signature, password or SSO account. All possibilities are represented by the "auth:" field in the irt object.

This is done by sending an email to auto-dbm@ripe.net. You provide the inet(6)num object with the necessary changes. In most cases you just need to add a "mnt-irt:" attribute.

Here is an example:

An inet(6)num object as you find it in the RIPE Database before the change:

inetnum:        193.174.13.0 - 193.174.13.255
netname:        DFNCERT-NET
descr:          DFN-CERT  Zentrum fuer sichere Netzdienste GmbH
country:        DE
admin-c:        KM4692-RIPE
tech-c:         KM4692-RIPE
status:         ASSIGNED PA
mnt-by:         DFN-LIR-MNT
created:        2022-08-14T11:48:28Z
last-modified:  2022-10-25T12:22:39Z 
source:         RIPE

And this is the same object linked to an irt object:

inetnum:        193.174.13.0 - 193.174.13.255
netname:        DFNCERT-NET
descr:          DFN-CERT  Zentrum fuer sichere Netzdienste GmbH
country:        DE
admin-c:        KM4692-RIPE
tech-c:         KM4692-RIPE
status:         ASSIGNED PA
mnt-by:         DFN-LIR-MNT
mnt-irt:        IRT-DFN-CERT
created:        2022-08-14T11:48:28Z
last-modified:  2022-10-25T12:22:39Z 
source:         RIPE

Now both the team and the maintainer of the inet(6)num object have to authorise the link request.

# If Both Parties Use (different) PGP Keys for Authorisation

Both need to sign the request -mail. It does not matter in which order this signing occurs as long as both parties sign the request.

# If Only One Party Uses a password or SSO for Authorisation

In this case, whoever is using PGP should initially sign the request and send it to the other. They forward it to the RIPE NCC, together with their password. This maintains password confidentiality. It is strongly recommended that anyone using passwords, switch to PGP authentication. It is a more secure way to handle requests made to the RIPE NCC.

If using SSO for authentication, then login to RIPE NCC access and send the request using Syncupdate.

# If Both Parties Use Password or SSO Authorisation

In this case, at least one, if not both parties should consider switching to PGP authentication.

# If the IRT Object and INET(6)NUM Object are Maintained by the Same Maintainer

In this case, the process is straightforward.

# Step-by-Step Guide

How to link a single inet(6)num object to a single irt object.

Exact the inet(6)num object from the RIPE Database:

whois -h whois.ripe.net -r <ipadress> > inetnum.txt

Alternatively you can search for any other entry in that object with -i, for example for the "mntner:" attribute.

whois -h whois.ripe.net -i mnt-by <mntner-name> > inetnum.txt

Here is an example:

$ whois -h whois.ripe.net -r 193.174.13.99 > inetnum.txt
$ cat inetnum.txt
inetnum:        193.174.13.0 - 193.174.13.255
netname:        DFNCERT-NET
descr:          DFN-CERT  Zentrum fuer sichere Netzdienste GmbH
country:        DE
admin-c:        KM4692-RIPE
tech-c:         KM4692-RIPE
status:         ASSIGNED PA
mnt-by:         DFN-LIR-MNT
created:        2022-08-14T11:48:28Z
last-modified:  2022-10-25T12:22:39Z 
source:         RIPE

Add an mnt-irt: attribute. If you have only inet(6)num to change, you can do this by hand using a standard text editor.

Here is an example:

$ cat inetnum-irt.txt
inetnum:        193.174.13.0 - 193.174.13.255
netname:        DFNCERT-NET
descr:          DFN-CERT  Zentrum fuer sichere Netzdienste GmbH
country:        DE
admin-c:        KM4692-RIPE
tech-c:         KM4692-RIPE
status:         ASSIGNED PA
mnt-by:         DFN-LIR-MNT
mnt-irt:        IRT-DFN-CERT
created:        2022-08-14T11:48:28Z
last-modified:  2022-10-25T12:22:39Z 
source:         RIPE

Sign the new text file, making sure that the "auth:" section of your irt object contains your PGP key. You can find out the correct key by using:

whois -h whois.ripe.net <irt-object name> | grep auth

Here is an example:

$ whois -h whois.ripe.net irt-dfn-cert | grep auth
auth: PGPKEY-6DFC4771
$ gpg --clearsign -a -u 0x*234567 inetnum.txt
$ cat inetnum.txt.asc
-----BEGIN PGP SIGNED MESSAGE-----
inetnum:        193.174.13.0 - 193.174.13.255
netname:        DFNCERT-NET
descr:          DFN-CERT  Zentrum fuer sichere Netzdienste GmbH
country:        DE
admin-c:        KM4692-RIPE
tech-c:         KM4692-RIPE
status:         ASSIGNED PA
mnt-by:         DFN-LIR-MNT
mnt-irt:        IRT-DFN-CERT
created:        2022-08-14T11:48:28Z
last-modified:  2022-10-25T12:22:39Z 
source:         RIPE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (SunOS)
iQEVAwUBP4VPg1FwV5Zt/EdxAQFk+Af/dUMEyjeQATGZ+8LVerSIyWHFmntjxh6Z
hQE3jP5dbtklCaRiCpdgRKw0sBiNG6fPyhmno4kcFYInKYxukhkLH+5HRXzQxk5R
Ay/oW4fn7K8hl1SgZn5cbN61UcMRDgDV88SeWOnCtc/CQ3bqv6N+l9TbTbzFS6kF
3e4a9G3G8tEKjilCWvDYgEhnYAlEPZr0+jvxFaEEN/4UuX2q0npE0269x2sybQlD
hfPQ++RtQ5vstablHW9/6m4r+bqlgfcAirVucmHaw/mgd4yK6CLrQEh9MRXcVest
0LVwuHI/HQGZ4bwbwUB+pnlMvU/W+wiD7ct3rwoqP2xKI8BUzPkjDg==
=7JK5
-----END PGP SIGNATURE-----

Send the new file to the maintainer of the inet(6)num object. If you do not know the maintainer, you can find out the person behind the mntner object by using the RIPE Database:

whois -h whois.ripe.net -r <ipadress> | grep mnt-by
whois -h whois.ripe.net <mntner name> | grep e-mail

Here is an example:

$ whois -h whois.ripe.net -r 193.174.13.99 | grep mnt-by
mnt-by: DFN-LIR-MNT
$ whois -h whois.ripe.net DFN-LIR-MNT | grep e-mail
e-mail:       hostmaster@dfn.de

Let the other maintainer also authenticate the request by either signing the file (inetnum.txt.asc) with the PGP key referenced in his mntner object. An alternative would be to send the file, along with this maintainer password to the RIPE NCC.

Send this authenticated request to auto-dbm@ripe.net

Both the maintainer of the inet(6)num object and the team who owns the irt object will receive a change notifications by e-mail, when the request has been completed. If there is an error, both will receive a notification.

# All INET(6)NUM Object Have the Same Maintainer Object

You should collect all the inet(6)num objects into one list. Make the appropriate changes and send the change request in one email to auto-dbm@ripe.net.

# Some INET(6)NUM Objects Have Different Maintainer Objects

You need authorisation from each party involved. You should collect the inet(6)num objects maintained by different maintainers into separate lists. Authorise these separately and then send each in a separate email to auto-dbm@ripe.net.

# Step-by-Step Guide

How to link multiple inet(6)num objects with the same maintainer to one single irt object.

Extract all the inet(6)num objects belonging to the mntner object from the RIPE Database:

whois -h whois.ripe.net -r -i mnt-by <maintainer name> > inetnums.txt

You will see a list of objects, separated by an empty line.

  • Here is an example:

    $ whois -h whois.ripe.net -r -i mnt-by DFN-LIR-MNT > inetnums.txt

Add an "mnt-irt:" attribute to every object in the list.

Sign the new textfile with the PGP key from the "auth:" section of your irt object. You can find the correct key by issuing the following command:

whois -h whois.ripe.net <irt-object name> | grep auth

  • Here is an example:

    $ whois -h whois.ripe.net irt-dfn-cert | grep auth auth: PGPKEY-6DFC4771 $ gpg --clearsign -a -u 0x6DFC4771 inetnums.txt

Send that file to the other maintainer. He should authenticate the request by either signing the file (inetnum.txt.asc) with the PGP key referenced in his mntner object or send the file, along with his RIPE maintainer password to the RIPE NCC. The address to use is auto-dbm@ripe.net

Both the maintainer of the inet(6)num object and the team who owns the irt object will receive a change notification by email, when the request has been completed. If there is an error, both will receive a notification.

This document was first published on the TERENA website. The author of the original document was: Marco Thorbrügge, DFN-CERT / thorbruegge@cert.dfn.de Subsequently updated by the RIPE NCC.

# Protecting Membership of a Set

When membership of a set is specified through the use of the "member-of:" attribute, the server checks the validity of the membership when creating or modifying a member object. This "member-of:" attribute can be used in route(6), aut-num and inet-rtr objects. The value of the "member-of:" attribute identifies a set object that this object wants to be a member of.

The set object may also have a related "mbrs-by-ref:" attribute, listing the maintainer of the object that wants to be a member of the set. The membership claim of an object with a "member-of:" attribute must be validated. Validation occurs by matching a "mnt-by:" attribute of the object with one of the "mbrs-by-ref:" attributes of the set object. If the claim is not valid at the time of creation or modification of a member object (route(6), aut-num or inet-rtr), the operation fails. If a set object has no "mbrs-by-ref:" attributes, the set is defined explicitly by the "members:" attributes in the set object. In this case, no other object can validate a claim to be a member of this set. Below is an example of "member-of:" usage:

aut-num:     as3333
member-of:   as-ripe
mnt-by:      ripe-dbm-mnt
as-set:      as-ripe
mbrs-by-ref: ripe-dbm-mnt

# Protection of Address Space

The inetnum and inet6num objects represent address space allocations and assignments. The "mnt-lower:" attribute is used to reference a mntner object that authorises the creation of more specific inetnum or inet6num objects. If no "mnt-lower:" attribute is present, one of the "mnt-by:" attributes of the parent object will be used instead.

This parent authorisation is only required when an inetnum or inet6num object is created. This authorisation is in addition to the authorisation of the individual object itself.

# Protection of AUT-NUM Object Space

Protection of aut-num object space is done using as-block objects. The mntner object that authorises the creation of aut-num objects is specified by any one of the "mnt-lower:" attributes of the parent as-block object. When no "mnt-lower:" attribute exists, the mntner object from any one of the parent "mnt-by:" attributes is used.

This parent authorisation is only required when an aut-num object is created. It is in addition to the authorisation of the individual object itself.

# Protection of Objects with Hierarchical Names

RPSL set objects do not have a natural hierarchy of their own but allow hierarchical names, such as the as-set object. An as-set object may have a non-hierarchical name such as "AS-Foo" or a hierarchical name in the form "AS1:AS-BAR".

For set objects with non-hierarchical names, authorisation corresponds to the rules for individual objects described in the section 'Security of Data Using Authorisation'.

If hierarchical names are used, then the creation of an object must be authorised by the object whose primary key is named by everything to the left of the rightmost colon in the primary key name of the object being created. Consider the object "AS1:AS-BAR:AS2". This would need to be authorised by "AS1:AS-BAR". This object is considered to be the 'parent' of the object being created.

Hierarchical authorisation is determined by first using any mntner object referenced by the parent object's "mnt-lower:" attributes. If none of these exist, then any mntner object referenced by the parent object's "mnt-by:" attributes is used.

The parent authorisation is required in addition to the authorisation of the individual object itself and is only required when an object is created.

# Protection of PERSON and ROLE Objects

When "mnt-by:" was made mandatory on these objects a circular dependency was created. A person object must be maintained and a mntner must reference an existing person. Therefore, a new user who has no data in the RIPE Database must follow the procedure in the section, 'New Organisation Startup' to get started.

# Protection of Reverse Delegation Objects

Protection of the reverse domain object space for "in-addr.arpa" and "ip6.arpa" domains is done with separate methods for creation, deletion and modification. The domain object creation is described in a flow chart.

The creation of domain objects for "in-addr.arpa" and "ip6.arpa" domains must satisfy several authorisation criteria. As with all objects, it must satisfy its own mntner object references in the "mnt-by:” attributes. It must also satisfy a hierarchical authorisation. Both authorisations must be passed for the object to be created. For modification and deletion of a domain object, only its own mntner object in the "mnt-by:" attributes needs to authorise the operation. Where a deletion fails, mntner objects referenced in a "mnt-domains", "mnt-lower" or "mnt-by" attribute of the corresponding inet(6)num object can authorise the deletion. They will be checked in this order. The first attribute type found will be taken as the only one to use.

The hierarchical authorisation uses the related address space objects. An address space object (inetnum or inet6num) with an exact matching prefix will be used; otherwise a less specific prefix is used. One of these objects will always be found in the database. Following this order, the first valid object found is the one used to authorise the new object creation. If the supplied credentials do not satisfy the authorisation required by this first valid object found, then authorisation fails. The software does not look for the next possible valid object in the sequence.

There is no hierarchy allowed in the reverse domain objects. Therefore, no hierarchical authorisation is required from the domain objects, as is also the case for route objects.

# Protection of Route(6) Object Space

The route(6) object creation must satisfy several authorisation criteria. As with all objects, it must satisfy its own mntner object references in the "mnt-by:" attributes. It must also satisfy two separate hierarchical authorisations. All three authorisations must be passed for the object to be created. For modify and delete of a route(6) object, only its own mntner object in the "mnt-by:" attributes needs to authorise the operation.

Address space: the creation of a route(6) object needs to be authorised either by existing, related route(6) objects or related address space objects. The route(6) objects are checked first. If a route(6) object with an exact matching address prefix exists, it will be used for authorisation. If this does not exist, one with a less specific prefix is used. If no such route(6) object exists, an address space object (inetnum or inet6num) with an exact matching prefix will be used, otherwise a less specific prefix is used. One of these objects will always be found in the database. Following this order, the first valid object found is the one used to authorise the new object creation. If the supplied credentials do not satisfy the authorisation required by this first valid object found, then authorisation fails. The software does not look for the next possible valid object in the sequence.

Autonomous System (AS) Number: you do not need to authenticate against the origin AS Number when creating a route(6) object. Any originating AS Number can be used, so long as it’s not in reserved space. The originating AS Number does not need to exist in the RIPE Database.

The origin AS holder is notified of a route(6) creation, using the "notify:" attribute on the aut-num object, if the both the AS Number exists and the "notify:" attribute is set.

The RIPE Database is used as an inter-routing registry. However, it is only possible to create a route(6) object in the RIPE Database with an origin prefix that has been allocated to the RIPE region.

# Authorisation rules for creating route objects

The IRR that the RIPE NCC operated is tightly coupled with the RIPE Database, which contains resource and contact information for the address space and ASNs that the RIPE NCC manages. This means that when you query for a certain resource in the RIPE Database, you will also get relevant results from the IRR. Conversely, when entering data into IRR, authorisation for the relevant RIPE Database objects is required.

To create a route(6) (i.e. a route or route(6)) object in the RIPE database, you must authenticate against the address space you are referring to. Only address space within the RIPE region can be referred to.

When creating a route(6) object you must authenticate against multiple maintainers to verify that you have control over the address space you are referring to. This means the related inet(6)num object must exist in the RIPE Database and you can authenticate against it, before you can create a route(6) object in the IRR.

When you submit a new route(6) object, the following validation process is triggered:

  • The maintainer of any existing route(6) object that is exactly matching or covering a less specific prefix is checked. If there is none, the maintainer of the inet(6)num object that is exactly matching or covering a less specific prefix is checked.
  • If successful, the maintainer of the route(6) object you are creating is verified.

The order in which the RIPE Database will verify available maintainers is:

  • mnt-routes
  • mnt-lower
  • mnt-by

This means that if a route(6) or inet(6)num object has all three kinds of maintainers defined, you must use the "mnt-routes:" attributes to authenticate. In this case, you cannot use the "mnt-lower:" or "mnt-by:" attributes. Likewise, if you have a "mnt-lower:" and a "mnt-by:" attribute on the objects, the "mnt-lower:" attribute must be used.

Here is a flowchart outlining the entire authorisation process.

You can only create a route(6) object for a prefix you manage. If these objects are maintained by your organisation's single shared maintainer, you just need to supply one credentials to satisfy all of the requirements. However, when you use multiple maintainers, you may need to supply different credentials to create a single route(6) objects.

If you wish to avoid having to supply multiple credentials, it is best to set up hierarchical authorisation by adding a "mnt-routes:" attribute to all of your resource objects and consistently use this maintainer to create and manage route(6) objects.

# Creating route objects referring to resources you don't manage

You do not need to authenticate against the origin AS Number when creating a route(6) object. Any originating AS Number can be used, so long as it's not in reserved space. The originating AS Number does not have to exist in the RIPE Database.

If the originating AS Number exists in the RIPE Database, and if the aut-num object contains one or more notify: attributes, these will be used to notify the originating AS Number holder when the route(6) object is created.

# Creating route objects for out-of-region (non-RIPE) resources

It is not possible to create a route(6) object in the RIPE Routing Registry that refers to a prefix that is not managed by the RIPE NCC, but by one of the other Regional Internet Registries.

This change was introduced by NWI-5, which is documented in a RIPE Labs article: Out-of-Region ROUTE(6) and AUT-NUM Objects in the RIPE Database (opens new window).

# Force deleting blocking route objects

When the RIPE Database gets authorisation from the address space for the creation your new route(6) object, it will first check if there is an exact matching or less specific route(6) object. If this route object has a maintainer that you do not have the credentials for, it can block you from creating a new route(6) object. In this case you, as the resource holder, can simply delete the blocking route(6) object.

Normally an object can only be deleted if the operation is authorised by one of the maintainers in the "mnt-by:" attributes of the object to be deleted. However, the force delete functionality also looks for the exact matching, encompassing or less specific address space object that was co-maintained by the RIPE NCC in the hierarchy of the object that is to be deleted. Co-maintained objects include resources that were allocated or assigned by the RIPE NCC, and also legacy resources under contract.

The result is that the "mnt-lower:" attribute of an allocation, or the "mnt-by:" attribute of a PI or anycast assignment, has the authority to reclaim any more specific or related object. Practically, this means a route object can be deleted by:

  • the mnt-by: attribute of the route object
  • the mnt-routes: attribute of the parent inet(6)num that was allocated or assigned by the RIPE NCC
  • the mnt-lower: attribute of the parent inet(6)num that was allocated or assigned by the RIPE NCC

It is important to understand that this functionality only works when the parent inet(6)num object is protected by the RIPE-NCC-HM-MNT (opens new window) or RIPE-NCC-LEGACY-MNT (opens new window) maintainer. If not, the system will look up in the hierarchy until it finds an inet(6)num which has a RIPE NCC maintainer on it, after which it will look at the "mnt-lower:" or "mnt-routes:" attributes on that inet(6)num object and use them for the authentication.

# Referencing an IRT Object

The irt object can be referenced in inetnum and inet6num objects. This reference is made by adding an optional "mnt-irt:" attribute to the inet(6)num object with the value set to the name of the irt object. Adding a reference to an irt object requires authorisation from the irt object. Authorisation can be approved by any of the credentials referenced in any of the "auth:" attributes of the irt object. The authorisation will not default to the "mnt-by:" attributes of the irt object if no suitable credential is found in the "auth:" attributes, and, in this case, the update will fail.

Authorisation from the irt object is only required when a "mnt-irt:" attribute is added to a referencing object, either on creation or by modification. The irt authorisation is required in addition to the authorisation of the individual object itself.

# Referencing an ORGANISATION Object

The organisation object can be referenced in any object. This reference is made by adding an optional "org:" attribute to the referencing object, along with the name of the organisation object. Adding this reference requires authorisation from the organisation object. Authorisation can be approved by any of the mntner objects referenced in any of the "mnt-ref:" attributes of the organisation object. The authorisation will not default to the "mnt-by:" attributes if no suitable maintainer is found in the "mnt-ref:" attributes and, in this case, the update will fail.

Authorisation from the organisation object is only required when an "org:" attribute is added to a referencing object, either on creation or by modification. This is in addition to the authorisation of the referencing object itself.

# DNSSEC Delegations

This procedure is in addition to the normal procedure for requesting reverse delegations.

# The DOMAIN Object

You can request reverse delegation by submitting domain objects. DNSSEC will not mean any change the existing authorisation mechanisms. The delegation checker (opens new window) will only carry out DNSSEC specific tests if DNSSEC related information is being exchanged.

To allow for the exchange of DNSSEC related information, the domain object now includes a "ds-rdata:" attribute.

# Delegation Checks

When it receives an update, the update engine will perform a number of checks. These are the most important:

  • Is there a matching DNSKEY available in the DNS for each "ds-rdata:" attribute that is submitted in the domain object?
  • Is there a valid RRSIG made with the DNSKEY matching the "ds-rdata:"? - The resolution protocol (opens new window) needs this, without it the update will fail.
  • Does the DNSKEY has its "SEP" flag set? Setting the SEP flag is not mandatory. If it is not set, a warning will be produced, however the "ds-rdata:" content will still be copied to the zone.
  • Is the signature validity period close to expiring and are the Times To Live (TTLs) a reasonable fraction of the signature validity period? We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period. If the TTL would be of similar order as the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of Resource Records for the DNS Security Extension (opens new window) suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL". As a result query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches. To avoid query load peaks we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. We currently test on the TTL being at least two times smaller than the signature validity period.

These tests will only be done for "ds-rdata:" attributes using supported digest types, [section 5.1.3 from RFC4033] (https://www.ietf.org/rfc/rfc4033.txt). A Zonemaster (opens new window) check determines whether the digest type is supported.

If the "ds-rdata:" attribute uses an unsupported digest type, you will see a warning message, however the "ds-rdata:" content will still be copied into the parent zone.

NOTE: The domain objects wizard in the webupdates does not support requesting DNSSEC delegations yet. However, you will be able to use webupdates to add the "ds-rdata:" attribute to an existing domain object.

# Request ENUM Delegation

ENUM is a protocol that is the result of work of the Internet Engineering Task Force's (IETF's) Telephone Number Mapping Working Group. The charter of this working group was to define a Domain Name System (DNS)-based architecture and protocols for mapping a telephone number to a Uniform Resource Identifier (URI) which can be used to contact a resource associated with that number.

The RIPE NCC provides DNS operations for e164.arpa (opens new window) zone(ENUM) is accordance with the Instructions from the Internet Architecture Board (opens new window).

# Requesting Secure Delegation in the ENUM Domain

Example of an ENUM domain object, including a "ds-rdata:" attribute

domain:     1.3.e164.arpa
descr:      Stichting ENUM Nederland
org:        ORG-SEN3-RIPE
admin-c:    MD6066-RIPE
tech-c:     ENT6-RIPE
zone-c:     ENT6-RIPE
nserver:    ns1.enum.nl
nserver:    ns7.domain-registry.nl
ds-rdata:   10567    5   1   8f138cd3e55db6590f51fe47e390a2d1743b5bd4
mnt-by:     ENUM-NL-MNT
source:     RIPE # Filtered

# The four steps to updating an ENUM delegation to have a secure DS record in e164.arpa

  1. Setup you server to serve a secure zone

    Ensure that the zone you are serving is signed and it contains a Key Signing Key (KSK) marked with the SEP flag.

  2. Create your domain object

    The "ds-rdata:" attribute of your domain object should be created by performing a hash over the SEP KSK key. An easy way to create a domain object which includes the ds-rdata: hash is to visit the RIPE NCC Delegation Checker (opens new window), input your zone name and follow the instructions provided. The end result will be a domain object you can use in the next step.

  3. Submitting the domain object Once you have set up your sever(s) to serve the ENUM zones you are ready to request delegation by submitting a domain object:

    1. By using webupdates (opens new window)

      • First authorise yourself in the authorisation section. Then go to the add section
      • Select domain, by clicking on 'Create a New Object' and then click on 'Add Object'
      • Fill in all the available fields
      • Use the 'Add New Field' feature to add at least two "nserver:" attributes. Here, you supply the names of the name servers that are serving the zones as set up in Step 3 and that you have specified in the NS resource records of those zones
      • For the "mnt-by:" attribute use the mntner you prepared in Step 1

    2. By email You need to create a domain object containing information about the zone you need reverse delegation for. For further information go here

    3. Verifying the setup Once you have submitted the domain object you will receive a notification.

      You should then be able to query for your object in the RIPE Database: whois -h whois.ripe.net 1.3.e164.arpa After the object appears in the RIPE Database it may take between 15 and 60 minutes before the delegation information is available in the DNS.

      The ultimate test is to query a recursive name server that is not authoritative for your zone for a record from your zone.

      Please contact us (opens new window) if, six hours after the appearance of your domain object in the database, your delegation does not appear. Include the details such as name server addresses and the domain object in your request. Also include the full response, including headers, as received from the database.

      Any resolver which has the DNSSEC public key for e164.arpa configured should now return DNS answers which have the authenticated data bit set.

# Additional Notes

From time to time, you may have to roll the keys in your zone. When you do this, make sure that you also update the ds-rdata information. This places a new DS record in the parent zone.

For further details on rolling keys and other important information on DNSSEC operational practices we recommend reading RFC 4641 (opens new window).

# Security of Data Using Authorisation

Individual data objects must be protected with a mntner object. The mntner is referenced by the "mnt-by:" attribute in the object. This attribute is defined as multiple in all object types, so several mntner objects can be used to protect one object.

Only those mntner objects referenced by the "mnt-by:" attributes are authorised to modify or delete the object. Authorisation checks work in line with the logical “OR” - for the operation to be authorised, you must supply information required by at least one credential from one of the referenced mntner objects. As you can supply information required by any credential for the operation to be authorised, this means that an object's protection level is determined by the weakest authorisation method used in the mntner objects referenced by that object.

When the "mnt-by:" attribute is added to an object for the first time (as part of object creation or modification), the operation should pass authorisation checks for at least one of the mntner objects referenced by one of the "mnt-by:" attributes.

If the operation is a modification and the old object already has one or more "mnt-by:" attributes, then one of the mntner objects referenced in one of the "mnt-by:" attributes in the old object must authorise the change. If the old object does not have any "mnt-by:" attributes, then one of the mntner objects referenced in one of the "mnt-by:" attributes in the new object must authorise the change. All new objects must have at least one "mnt-by:". There are still some historic person and role objects that do not have any "mnt-by:" attributes.

Authorisation is also used in a hierarchical way. Much of the operational data in the RIPE Database is structured hierarchically. For example, the address space is allocated in large blocks, which can then be divided in a number of ways and then finally assigned to End Users. Authorisation in a hierarchy works from the top down to the bottom. So each child object needs to be authorised by the holder of the parent object. There are a range of additional attributes for this including "mnt-lower:", "mnt-routes:" and "mnt-domains:".

# Using the Authorisation Methods

# MD5 Password

An MD5 password can be used by any of the update methods currently in use. See section 5.2 Update Methods for more details of these methods.

For email updates, password authorisation information is supplied using a "password:" pseudo-attribute. The value of this attribute is a clear-text passphrase, corresponding to the encrypted hash. It can appear anywhere in the body of the message, but not within mail headers. Line continuation is not allowed for this attribute. The attribute and the passphrase should fit on one line. If you split the passphrase across multiple lines, this will be treated as a syntax error. If you have a very long passphrase, please note that some email clients split lines at a pre-defined character position. If multiple passwords are required, a "password:" pseudo-attribute must be included in the update for each password. The Webupdates web form includes a ‘Session Passwords' field. Many passwords can be added, one at a time, using this field, up to a pre-defined limit. For any update in this session, all session passwords will be added to the update that is performed via the web form.

In the single text area form of Webupdates, the "password:" pseudo-attribute can be added as part of the update body, in the text area, in the same way as with an email update. The session passwords also apply in this case.

Using the Syncupdates web form there is no ‘Session Passwords' field but again the "password:" pseudo-attribute can be added. When using the HTTP POST and GET requests for Syncupdates, the "password:" pseudo-attribute must be supplied as part of the message body.

With the RESTful API, any required passwords must be included in the URI query parameters. For more details see the API documentation.

# PGP Key

To use PGP authentication you must first create a private/public key pair. There are many third-party applications that will allow you to do this. You must keep the private key secure. The public key is entered into the RIPE Database in a key-cert object. (See 'Description of the key-cert Object' for details.)

Some email clients allow you to import your private key into the client. This can then be used to sign any email update you submit. Alternatively, you can use third-party software to sign an update with your private key and paste the signed update into the body of an email.

A signed update message can also be pasted into the Syncupdates web form. When using the HTTP POST and GET requests for Syncupdates, the signed update must be supplied in the message body.

PGP-signed updates cannot be submitted using the RESTful API. As Webupdates uses the API in the background, you cannot paste a signed update into a Webupdates text area either.

For your PGP-signed update to pass authentication checks, you must have your public key in the database in a key-cert object.

PGP authentication creation steps are in the appendix.

# Use in the MAINTAINER object

PGP authentication can be activated by setting the value of an "auth:" attribute to PGPKEY-<id> where <id> is the PGP key ID to be used for authentication. This string is the same one which is used in the corresponding key-cert object's "key-cert:" attribute.

Remember that if you have multiple "auth:" attributes in a maintainer or if you have multiple "mnt-by:" attributes in an object, all possible authentication methods are combined by a logical OR which means that any single one of the specified authentication methods can be used. There is not security advantage in using PGP authentication with an object which can also be updated with password authentication.

There are currently no referential integrity checks carried out on the "auth:" attribute values. If you change your "auth:" to refer to a non existent key-cert object, or someone else's key-cert object you have locked your mntner. You will then have to contact us for assistance to un-lock it. Also, if you delete your key-cert object you will again lock your mntner until you re-create the key-cert object.

This is an example of a valid mntner object which uses PGP authentication:

mntner:         EXAMPLE-MNT
descr:          Example maintainer
admin-c:        JOE1-RIPE
upd-to:         joe@example.net
auth:           PGPKEY-4B8AE00D
mnt-by:         EXAMPLE-MNT
created:        2022-10-26T11:38:51Z
last-modified:  2022-10-26T11:38:51Z
source:         RIPE

# Using authentication when sending updates

PGP signed updates can be sent to the database simply by signing the body of the message containing the updates and sending it to the server. Remember to use ASCII armoring.

Multiple GP-signed and non-signed parts can be supplied in a single update message, each part is processed separately. You can supply several objects which are protected by different PGP keys in a single update message, providing all required signatures are present.

PGP parts with invalid signatures are handled as plain text. If the object is protected by an authentication method other than PGP, or has multiple authentication schemes in use and the required authentication is present, it will still be authorised. If PGP is the only form of authentication present the authentication will fail.

PGP authentication can be mixed with any of the other forms of authentication in the same mntner object. Each authentication method used can have multiple instances present. All the authentications present in a mntner object are processed with a logical 'OR' to determine if the authentication is passed.

PGP can be used with updates submitted by e-mail or using the syncupdates facility. It cannot be used with the webupdates interface.

# X.509 Certificate

This is handled in a similar way to PGP. You need a certificate and private key. There is third-party software available to generate these as well as command-line tools, for example OpenSSL. The certificate must be included in a key-cert object in the database. The generated certificate and private key are in binary files. The OpenSSL tool will convert the certificate into plain text to be included in the key-cert object. For X.509 key-cert objects, you must specify the "key-cert:" value as ‘AUTO-1'. The database software will then set this value. These values cannot be reused. Once deleted, an X.509 key-cert object cannot be recreated.

If your email client supports S/MIME you can import the certificate and private key into the client. Email updates can now be signed with your X.509 private key. Alternatively, you can sign your update using your private key with OpenSSL and paste it into the email message body.

A signed update message can also be pasted into the Syncupdates web form. When using the HTTP POST and GET requests for Syncupdates, the signed update must be supplied in the message body.

X.509 signed updates cannot be submitted via the RESTful API. Additionally, since Webupdates utilizes the API in the background, you are unable to paste a signed update into a Webupdates text area. However, you can submit updates through the RESTful API using Client Certificate Authentication.

For your X.509 signed update to pass authorisation checks, you must have your certificate in the database in a key-cert object.

# Single Sign-On

The SSO (single sign-on) authorisation is different to all the other methods. This one provides some authentication as well. SSO is based on RIPE NCC Access. To use SSO as an authorisation method in the RIPE Database, you must first create a RIPE NCC Access account. This provides some details about who you are. It is no longer a totally anonymous password in a box (where the box is the mntner object).

The RIPE NCC Access account username, which is your email address, becomes the authorisation credential used by the database software. If you change your RIPE NCC Access username to a different email address, this is immediately reflected in the mntner object.

Currently SSO authorisation only works with web-based update methods. This includes Webupdates and the Syncupdates web form. You need to sign in to your RIPE NCC Access account in order to authorise an update.

# Available Databases

An update is the submission of information for entry into, or removal from, a database. As the database records are RPSL objects, these updates create, modify or delete one or more objects.

There are several databases that can be updated and a number of ways in which you can submit an update. Each of the databases described below have a fully operating software system built around them. This includes the core database software as well as the external interfaces, for example email service, Webupdates, Syncupdates and RESTful API.

# Experimental Databases

There are times when some features need to be deployed in a proof of concept mode. It may be an idea that some community users have suggested but does not yet have widespread support. A proof of concept software release can be made and a temporary database, similar to the RC Database, set up to demonstrate the feature. That database will be a full copy of the production database with dummified personal data and modified mntner object credentials.

Similar projects may be set up when a major data migration project is proposed. A test run may be carried out on a database copy and this may be made available to the community to review what their data looks like after the change.

# Release Candidate Database (RC)

The release procedure for new software requires the new system to be available in a test environment for a period of time. This test environment is built around the RC Database. This is a fully functioning service where all your client software can be tested against the new software release. The RC database is dummified to remove personal data. Also all mntner object authorisation tokens are set to a password using the mntner object name. This allows more flexibility, as you can create objects that are only created by the RIPE NCC in the production version, Other than that, it is an exact copy of the production database, with the copy made at some point in time close to the software release date.

# RIPE Database

The RIPE Database is the authoritative database and is sometimes referred to as the ‘live’ or ‘production’ database or service. This holds all the current data for all the existing RPSL objects. It also holds historical data for deleted objects and previous versions of the current objects. Most operational services and tools are built around this database.

# TEST Database

This database is provided as an operational service to all users. It allows anyone to try out updates or changes to their data. New users can set up any data they like and practise making updates and doing queries.

The TEST Database works in exactly the same way as the production service, for most of its operations. Some rules are relaxed and some mntner objects have the password included in a "remarks:" attribute. This allows users to create objects in this TEST Database that only the RIPE NCC can create in the production database. If you want to copy your allocation and build a copy of your network you can do this in the TEST Database.

Each evening, at midnight (UTC) the whole contents of this database are deleted. It is then reset with a standard, basic set of objects. This prevents anyone from creating large objects and blocking off huge pieces of the address space. So if you are testing anything that will take you more than a day to complete, you need to build your objects in a text file that you can either paste into a syncupdates web page or submit as an email update. Make sure you order them in the text file to match how you actually created them. If you get the order wrong, some may fail when you re-submit them. You can add to the text file as you create or change data in the database. Then the next day, you can recreate the whole set of objects to the point you reached previously and continue with your tests.

# Database Support

# RIPE Database Support

The RIPE Database contains registration details of IP addresses and AS Numbers originally allocated by the RIPE NCC. It shows the organisations that hold the resources, where the allocations were made, and contact details for the networks.

# Problems with Spam?

What can the RIPE NCC do about spam? Who can I report this to? How do I take things further? What you can do about network abuse (opens new window)

# Database Working Group

The Database Working Group deals with all issues related to the RIPE Database. Changes of existing objects, creation of new objects and features, and distribution of databases and security issues are discussed here. Join the Working Group (opens new window)

# Clean-up of Unreferenced Data

# Introduction

Any data entered into the RIPE Database must comply with the RIPE Database Terms and Conditions. Over a period of time, data is changed and references are removed. This often results in many of the secondary objects (for example organisation, person, role and mntner objects) being left in the database and serving no useful purpose. In order to keep the database clean and to comply with data protection rules, this unnecessary data must be removed. New personal data should not be stored in the RIPE Database beyond a reasonable "work in progress" period before it is referenced by operation data objects.

# Authority

Cleaning up this data has been discussed many times at RIPE Meetings and on the mailing list of the RIPE Database Working Group (opens new window)

The authority to clean-up this data was first given to the RIPE NCC at the RIPE 40 Meeting in Prague in 2001 (opens new window)

The scope was expanded at the RIPE 41 Meeting in Amsterdam in 2002 (opens new window)

A clean-up process (opens new window) to do periodic clean-ups was put in place in 2003. However, this process proved to be inadequate and the number of unreferenced objects continued to grow.

The issue was raised again at the RIPE 54 Meeting in Tallinn in 2007 (opens new window), continued on the RIPE Database Working Group mailing list throughout 2007 (opens new window) and then consensus was reached at the RIPE 56 Meeting in Berlin in 2008 (opens new window).

# Process

A simplistic implementation that cleaned up unreferenced person and role objects was started on 26 january 2009. However, since this approach was incomplete (e.g. it did not detect person-maintainer pairs as described below) it was largely ineffective. The process was therefore stopped again on 21 March 2014.

Since 6 September 2016 the RIPE NCC has implemented a more complete clean-up process for the following object types:

  • organisation
  • person
  • role
  • mntner

If the organisation, person or role object is unreferenced, it is eligible to be deleted. If a person or role object is only referenced in a mntner object and the mntner object only references that person or role object, then both the mntner and the person or role objects are eligible to be deleted.

To be deleted, they must be unreferenced by any other object, and must not have been referenced by any aut-num, domain, inet(6)num, route(6), as-set, filter-set, inet-rtr, peering-set, route-set, rtr-set, as-block, key-cert or irt object during the last 90 days.

Notifications of the deletion of objects will be sent to anyone who has optionally included a "notify:" attribute in the person, role or mntner objects, or a "mnt-nfy:" attribute in the mntner objects. These notifications include a link to this page.

# Configuring Reverse DNS

Computer networks use the Domain Name System (DNS) to determine the IP address associated with a domain name. This process is also known as forward DNS resolution. Reverse DNS (rDNS) is the inverse process of this: the resolution of an IP address to its designated domain name. This document explains how reverse DNS works and how to configure it for your zone

# Reverse DNS Overview

The reverse DNS database of the Internet works with a hierarchical tree of servers, just like forward DNS. It is rooted in the Address and Routing Parameter Area (arpa) top-level domain of the Internet. One level below the arpa root are the delegated servers in-addr.arpa for IPv4 and ip6.arpa for IPv6.

Further down the tree, there are delegations for the /8 blocks that IANA allocated to the RIRs, the allocations that the RIRs gave to the address holders, all the way down to the individual IP addresses and names that you have configured for your Internet-enabled hosts. The process of reverse resolving an IP address uses the pointer DNS record type (PTR record).

In order to do a DNS lookup for data that is associated with a certain IP address, you should map the IP addresses into the DNS name hierarchy. This means that, as an address holder, you will have to configure two things. Forst, you have to configure your zone for reverse DNS. Second, you have to request reverse delegation of your zone. The second part is one by creating a domain bject in the RIPE Database.

Before you can submit the domain object to the RIPE Database, you will first have to configure reverse DNS for your zone on at least two name servers. Upon submission, the RIPE Database will perform checks to see if your name servers are configured properly. If so, delegation will be propagated to the DNS by the RIPE NCC's name servers.

# Mapping IP addresses into the DNS name hierarchy

For IPv4, the mapping of the reverse address space can only happen on "byte" boundaries, i.e. multiples of 8 bits. This means that you should take the four octets - the decimal numbers between the dots - of an IP address range, put them in reverse order and then map them into the in-addr.arpa domain.

For example, an address (A) record for mail.example.com points to the IP address 192.0.2.5. In pointer record of the reverse database, this IP address is stored as the domain name 5.2.0.192.in-addr.arpa. pointing back to its designated host name mail.example.com. The resulting PRT record would look like this:

5.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com

Reverse DNS for IPv6 uses the hexadecimal notation on "nibble" boundaries, i.e. multiples of 4 bits. This means you should take the IPv6 address, expand all the zerps, put each hexadecimal number in reverse order and map them into the ip6.arpa domain.

For example, the pointer domain name corresponding to the IPv6 address 2001:db8::567:89ab is b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., which would result in this PTR record:

b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR mail.example.com.

# Dealing with multiple zones for one address block

Because the particular mapping delegation of reverse address space can only happen on byte boundaries for IPv4 and nibble boundaries for IPv6, you could be dealing with multiple zones for one address block.

IPv4 One or more /24 type zones need to be created if your address space has a prefix length between /17 and /24. If your prefix length is between /16 and /9 you will have to request one or more delegations for /16 type zones.

For example, if you have been allocated 10.155.16.0/22, you need to create four reverse zones:

16.155.10.in-addr.arpa.
17.155.10.in-addr.arpa.
18.155.10.in-addr.arpa.
19.155.10.in-addr.arpa.

IPv6 If you have been allocated an IPv6 block that is not on a nibble boundary, you will need to go down to the next nibble and create multiple zones to cover the entire block.

For example, an allocation such as 2001:db8::/29 will result in eight reverse zones of /32 each:

8.b.d.0.1.0.0.2.ip6.arpa.
9.b.d.0.1.0.0.2.ip6.arpa.
a.b.d.0.1.0.0.2.ip6.arpa.
b.b.d.0.1.0.0.2.ip6.arpa.
c.b.d.0.1.0.0.2.ip6.arpa.
d.b.d.0.1.0.0.2.ip6.arpa.
e.b.d.0.1.0.0.2.ip6.arpa.
f.b.d.0.1.0.0.2.ip6.arpa.

# Creating DOMAIN Objects for Reverse DNS

# Step 1: Set up authorisation

The creation and maintenance of domain objects must be handled by a designated maintainer. You can use an existing maintainer or create a specific one for the people who will be creating and managing domain objects. You should refer to this maintainer using the "mnt-domains:" attribute in inetnum object for the address block that you hold. You will be able to add the "mnt-domains:" attribute in the RIPE Database, for example using webupdates (opens new window). If you are an LIR, you may need to select your default maintainer first, before you can add this attribute.

# Step 2: Configure your DNS server

Configure your DNS servers in such a way that you will pass all the tests that we will perform. Here are some recommendations to help you:

  • Make sure you set up at least two name servers that are authoritative for the zone
  • Ensure that the servers are at least in different subnets, but preferably in different networks that are geographically distributed.
  • The resolvable names of these name servers should be in the NS resource records of the zone.
  • The SOA resource record (RR) should have the same content, both serial number and other data, on all the name servers.
  • The SOA should contain a valid "RNAME" (the contact address)
  • The timing parameters should be reasonable

When you are satisfied with your configuration, we recommend that you perform a test fo your setup using the DNSCheck (opens new window) tool so you can find and resolve any problems.

# Step 3a: Create your domain objects using webupdates

When you submit a domain object you are requesting reverse delegation, asking the RIPE NCC to enter NS records pointing to your name servers in RIPE NCC's parent zone. The domain object has the following mandatory attributes:

domain:   <zone name>
admin-c:  <nic-handle for administrative contact>
tech-c:   <nic-handle for technical contact>
zone-c:   <nic-handle for zone contact>
nserver:  <primary name server>
nserver:  <secondary name server>
mnt-by:   <your maintainer>
source:   RIPE

In the web interface (opens new window) for the RIPE Database, there is a wizard that will automatically create one or more domain objects for you. It allows you to fill in an IPv4 or IPv6 prefix and the wizard will take care of creating one or multiple reverse zones out of it. After filling in your name servers, the wizard will also perform a basic check to see if the name servers are online. The full set of tests will happen after you submit the form. A one-minute video (opens new window) with a demonstration is available online.

After you have entered all of the required fields you can submit the form. Depending on the amount of domain objects that are going to be created, it can take up to several minutes for the process to complete. The tests return log level information, categorised as INFO, NOTICE, WARNING, ERROR and CRITICAL. We reject any update that has ERROR or CRITICAL for any test. If this happens to you, resolve the problem and try completing the wizard again.

If the update was successful, the success page will show you the first couple of domain objects that were created, along with a link to the full list. Still, it may take up to 24 hours before the delegation information is available in the DNS. The ultimate test is to query a recursive name server that is not authoritative for your zone for a record from your zone.

# Step 3b: Create your domain objects using syncupdates, email or the API

If you choose to create domain objects using syncupdates, email or the API, you will first need to chop your address block into "chunks" that can be delegated. For example, if you have been allocated 10.155.16/22, you need to create four reverse zones:

16.155.10.in-addr.arpa.
17.155.10.in-addr.arpa.
18.155.10.in-addr.arpa.
19.155.10.in-addr.arpa.

In the "domain:" attribute, you specify the name of the reverse zone, e.g. "16.155.10.in-addr.arpa". As discussed, you will have to do this for each "chunk" you have created. If you need reverse delegation for a /22 block, you will need to create four domain objects, one for each /24.

Enter all other attributes and submit your domain object to the RIPE Database. After verifying syntax and authorisation, we will perform a number of tests to see if you configured reverse DNS correctly. The tests return log level information, categorised as INFO, NOTICE, WARNING, ERROR and CRITICAL. We reject any update that has ERROR or CRITICAL for any test. If this happens to you, resolve the problem and try submitting the domain object again.

If the update was successful, you should then be able to query for your object in the RIPE Database. Still, it may take up to 24 hours before the delegation information is available in the DNS. The ultimate test is to query a recursive name server that is not authoritative for your zone for a record from your zone.

# Requesting DNSSEC Delegations

To allow for the exchange of DNSSEC-related information, the domain object includes a "ds-rdata:" attribute.

In DNSSEC, the Delegation Signer (DS) resource record is created from a DNSkey resource record by comparing it with the public key. The parent publishes the DS resource record. The "ds-rdata:" attribute contains the RDATA of the DS resource records related to the domain, as shown in the "domain:" attribute.

ds-rdata: 64431 5 1 278BF194C29A812B33935BB2517E17D1486210FA

The tools provided with BIND (version 9.3.0 and later) will generate a "ds set" during signing. You should copy the DS RDATA into the "ds-data:" attributes.

When we receive a domain object with DNSSEC-related information, we will carry out additional tests.

# Automated update of DNSSEC Delegations

Whenever you want to change the DNSSEC key whose digest is in the "ds-rdata:" attribute, it is necessary to update the attribute. This can be done manually using any means of RIPE Database update methods or automatically using a special Child Delegation Signed (CDS) DNS record. This procedure works as follows:

  • The reverse domain has to be already DNSSEC-secured.
  • Whenever a change in "ds-rdata:" attribute is required, you should publish a CDS record at the apex (root) of your reverse zone.
  • RIPE NCC regularly scans all DNSSEC-secured reverse domains for CDS records.
  • If a CDS record is found whose contents differ from the current "ds-rdata:" attribute and all safety measures (see below) are fulfilled, RIPE NCC will update the domain object on your behalf.

There are some additional requirements mandated by RFC 7344 in order to ensure the process is hardened against accidents and abuse:

  • The CDS record set is properly signed by a key represented in the DS record of the parent zone. This usually means that the CDS record set has to be signed by Key-Signing Key (KSK) instead of Zone-Signing Key (ZSK).
  • Applying the CDS record must not break the DNSSEC delegation. Therefore for each DNSSEC algorithm present in the CDS record set, there has to be at least one matching key in the DNSKEY record set with a proper signature.
  • The inception date of the DNSSEC signature of the CDS record set must not be older than the date stored in the "last- modified:" attribute of the domain object.

It is also possible to switch to insecure delegation by publishing a special CDS record containing "0 0 0 00". Please note that this is a one way process. Once the reverse domain is switched to insecure, you have to add the "ds-rdata:" attribute manually to activate DNSSEC again.

# Reverse DNS Troubleshooting

Here is an overview of the most common warnings and errors that the reverse delegation checker reports, along with the likely causes and suggested solutions.

Error Likely cause and suggested solution
ERROR: No SOA RR were found. No Start of Authority records were found. This tends to indicate that the nominated name servers are not replying correctly for the zone in question. Usually, the fix for this involves reloading all of the name servers.
WARNING: some of the specified name servers appear to be in the same subnet. According to RFC 2182 (opens new window), they should be geographically separated. If you supply two or more name servers that appear to be in the same physical location, this warning is a reminder that the zone may not be visible if your connection to the Internet fails. We highly recommend that you have multiple geographically distributed secondary name servers.
ERROR: NS RR for abc.b.c.d found on xyz.b.c.d but not in template. The machine abc.b.c.d is reported to be a name server for this domain by the machine xyz.b.c.d, but you did not list abc.b.c.d when submitting the domain object.
ERROR: nserver: a.b.c.d ERROR: The specified name server is not responding The name server a.b.c.d has failed to respond because: * a name server process is not running on port 53; or * the name server does not accept both UDP and TCP port 53 queries; or * the name server process is running on the given host but has not been loaded with information about itself Correct your name server or firewall/router configuration and resubmit the domain object.
ERROR: cross-check of listed NS RR failed. The name servers on both zones should be the same.
ERROR: SOA on "machine1.b.c.d" does not match SOA on "machine2.b.c.d". Some of the name servers supplied could not be contacted, or some of them failed to respond appropriately, i.e. there may not be a name server running on the hosts, or they may not know about the zone in question. This message is also generated when the list of name servers that you supply does not match the list of name servers that you set up. The comparison is done on a textual basis, meaning that supplying IP addresses will not work.
I'm sure my zone is set up correctly, but the RIPE Database just won't accept my domain object! You can always contact us (opens new window) for help, but we suggest that you first read RFC 1912 - Common DNS Operational and Configuration Errors (opens new window)

# Create the First ROLE and MNTNER Objects

# What is a ROLE object?

A role object should describe a business function or operational unit, not an individual person, and contains information about a technical or administrative contact that are responsible for the object where it is referenced. Each role object has a unique NIC handle ("nic-hdl:").

# What is a NIC handle?

NIC handles are unique identifiers of roles.

It is basically the role's unique ID and it helps to keep different roles with the same name apart from each other.

Whenever a role object is referenced in another object they are referenced by their NIC handle ("nic-hdl:") and not by their name.

# What is a MNTNER (pronounced "maintainer")?

All objects in the RIPE Database must be protected using mntner objects. A mntner object specifies authentication information required to authorise creation, deletion or modification of the objects protected by the mntner.

The value of the "mnt-by" attribute is the name of the maintainer (mntner) object that will protect the object.

To create a role object and a mntner object at the same time, go to the web application (opens new window).

For more information about maintainers and hierarchical authorisation, please see ['Authorisation Model'].

To find out how to create role and mntner objects, and to protect objects using your mntner, see the e-learning course (opens new window).

# Database Business Rules

The RIPE Database contains objects formatted according to the Routing Policy Specification Language (RPSL), which has a set of syntax rules you have to comply with when creating, updating or deleting objects. In addition, the RIPE NCC enforces certain business rules to ensure data integrity and registry accuracy. This document gives an overview of all current business rules.

Applies To Object Type On Action Business Rule
all Create An object cannot be created if it already exists. The creation will fail if another object of the same type and with the same primary key is already present in the RIPE Database.
all Create, Update Only the RIPE NCC is authorised to add or remove RIPE NCC maintainers.
all Create, Update On objects where the "language:" or "country:" attribute is used, the value must be a valid two-letter ISO 3166 code (opens new window).
all Create, Update When creating or updating an object in the RIPE Database, all references to other objects must exist, such as mntner, person and role objects.
all Create, Update A warning is displayed if the object refers to a person or role object that does not have a maintainer.
all Create, Update A warning is displayed if the maintainer that is used for the object refers to a person or role object that does not have a maintainer.
all Create, Update Comments are not allowed in the "source:" attribute.
all Delete An object can only be deleted if the submitted object matches exactly the current object in the RIPE Database.
all Delete If an object has a RIPE NCC maintainer as one of the maintainers, the object can only be deleted by RIPE NCC.
all Delete An object can only be deleted if it is no longer referenced. An exception to this rule is made for aut-num objects. They may be deleted even if references in "import:" and "export:" attributes exist.
When an aut-num object is deleted, a warning email is automatically sent to all maintainers of objects that still reference the associated AS Number.
all Create, Update The "mnt-routes:" attribute refers to a maintainer, followed by an optional list of prefix ranges inside of curly braces, or the keyword "ANY". It is not allowed to have the "ANY" value on every "mnt-routes:" attribute in the object.
inetnum, inet6num Update On Provider Independent address space assignments, the End User maintainer cannot be removed.
inetnum, inet6num Create inet(6)num objects cannot overlap, meaning two objects that cover the same range and have the same status cannot exist.
inetnum, inet6num Update On an inetnum object with the status "ALLOCATED PA" or "ALLOCATED-ASSIGNED PA", the RIPE NCC has specified a "mnt-lower:" attribute. It cannot be removed and another "mnt-lower:" attribute cannot be added. The same applies to an inet6num object with the status "ALLOCATED-BY-RIR".
inetnum, inet6num Create, Update When submitting a route object that is authorised by a "mnt-routes:" attribute on a matching inet(6)num object, the prefix should be within the same range as the one in the submitted object.
inetnum, inet6num Create, Update On inet(6)num objects for allocations or End User assignments made by the RIPE NCC, the "org:" attribute is mandatory.
inetnum, inet6num Create, Update When creating an inet(6)num object, the "status:" attribute must be set correctly in relation to surrounding objects. For example, the status "ASSIGNED PA" may only be used if the object is a child of an inetnum object with the status "ALLOCATED PA".
inet6num Create, Update When creating or updating an inet6num object for an assignment, all first-level children must have the same prefix size. In addition, the assignment size should not be larger than a /128 and not smaller than the prefix length of the parent object.
inetnum, inet6num, aut-num Update If the object has a RIPE NCC maintainer as one of the maintainers, only the RIPE NCC can change the value of the "org:" attribute.
inetnum, inet6num, aut-num Create, Update Only the RIPE NCC can add, change or remove the "sponsoring-org:" attribute. It must reference an organisation of type "LIR".
organisation Create, Update The "abuse-c:" attribute must reference a role object that has an "abuse-mailbox:" attribute. Once set, the attribute cannot be removed if the organisation is referenced by any object that has a RIPE NCC maintainer present.
organisation Create, Update In an organisation object, only the value "OTHER" can be used for the "org-type:" attribute. Only the RIPE NCC can use other org-types, such as "LIR".
organisation Update If the organisation object has a RIPE NCC maintainer present, only the RIPE NCC can change the value of the "org-name:" attribute after an LIR submits a change request. In addition, LIRs cannot change the "e-mail:", "phone:", and "fax-no:" value; these must be changed in the LIR Portal.
role Create, Update When creating a role object that has an "abuse-mailbox:" attribute specified, or adding this attribute to an existing role object, a warning is displayed that no rate limiting is applied to this attribute.
role Update, Delete The "abuse-mailbox:" attribute cannot be removed from a role object if it's referenced as an "abuse-c:" attribute in any organisation object.
role Create, Update The "admin-c:" and "tech-c:" of a role object cannot refer to itself.
domain Create domain objects of the e164.arpa type need to be authenticated against one of the designated enum maintainers.
domain Create The domain object that is submitted cannot have have an existing parent or child object for the reverse IP.
domain Create, Update The server that is listed in the "nserver:" attribute must have a valid glue record, if required.
mntner Create, Update Maintainer names cannot use reserved names.
key-cert Update It is not allowed to use "AUTO-1" for the primary key value of a key-cert object. A unique value must be explicitly set.
poem Create, Update A poem object must be maintained by LIM-MNT (opens new window) only.
route, route6 Create, Update When using the "holes:" and "pingable:" attributes, the specified IP must lie within the prefix of the route.
peering-set Create, Update A peering-set object must include either a "peering:" or an "mp-peering:" attribute. One of these must exist, but both attributes cannot be present at the same time.
filter-set Create, Update A filter-set object must include either a "filter:" or an "mp-filter:" attribute. One of these must exist, but both attributes cannot be present at the same time.
as-set, filter-set, peering-set Create When creating an as-set, filter-set or peering-set object, a parent object must be present in the RIPE Database and it is required to authenticate against its maintainer.
as-set, route-set, rtr-set Delete An as-set, route-set or rtr-set cannot be deleted if the "member-of:" attribute is referenced.
aut-num, route, route6, inet-rtr Create, Update If the aut-num, route(6) or inet-rtr object is part of an as-set, route-set or rtr-set object that has a "mbrs-by-ref:" attribute set, the maintainers on the objects need to match.
as-block Create, Update Only the RIPE NCC is authorised to create and update as-block objects.

# RIPE Database Security

A collection of documents designed to help with security of whois data stored in the RIPE Database

# Maintainers

Every object in the RIPE Database must be protected, to ensure that only authorised people can make changes. To facilitate this, there is a dedicated object which is used to protect all other objects you manage: the maintainer. This page explains how to set up a maintainer for yourself and your organisation, as well as handling delegation of authorisation to other parties.

The maintainer (mntner) object is used to protect other objects in the RIPE Database. This is done by referring to the maintainer from the object you want to protect, using the "mnt-by:" attribute. The maintainer contains one or more authentication methods that you can use to authorise making changes to your objects.

Maintainers are anonymous. Other than the authentication references they contain, there is nothing that ties them to a specific person, group or organisation. Authentication is handled as a "logical OR", meaning that if you know one of several credentials associated with a maintainer, you can make changes to the objects that refer to it. In the example above, two people can use their RIPE NCC Access (single sing-on) account to make changes to the inet6num object, or the PGP key can be used. Which authentication method is best for your use case is explained in a separate section: Protecting your data in the RIPE Database.

Most commonly, a maintainer object is maintained by itself, meaning that the "mnt-by:" attribute of the maintainer refers to the same object. If you want to edit details, for example add or remove an authentication, you simply need to use one of the existing authentication methods. In the example above, one of the three authentications can be used to add a forth, such as new colleague joining the team.

What makes the maintainer system flexible is the fact that you have a lot of freedom in: * The number of maintainer objects you create * The number of maintainers you refer to from each RIPE Database object * The kind and number of authentication methods you use in each maintainer * Delegation of authorisation to a specific person or group * Controlling what kind of objects a certain group can create (such as route(6), domain and inet(6)num objects)

Given this flexibility, you must ensure you make the right choices when setting up authorisation. There are some important concepts and best practices to keep in mind which are explained in each of the following sections.

# The Default Maintainer

If you are an LIR and you have received Internet Number Resources, several objects are created by the RIPE NCC in the RIPE Database to reflect this. These objects are managed by the RIPE NCC, but you have control over some attributes, such as setting the administrative and technical contact person. In order to allow you to make these changes, an additional maintainer will be present on the object, the so-called "default" maintainer. You have to select this maintainer on the Account Details page and this will be reflected in the "mnt-by:" attribute on all existing and new objects that have joint responsibility: top level allocations for IP resources (inet(6)num and aut-num objects) and the organisation object. If you had a previous default maintainer the new default maintainer will replace your previous one.

After selecting the default maintainer, you can change all of the attributes you could previously modify by using the Object Editors - such as technical, administrative and abuse contact details - Through the RIPE Database itself. You can use any update method you like, e.g. webupdates, syncupdates or email updates.

# Personal Maintainers Versus Shared Maintainers

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. This means when you start using the RIPE Database, you first step would be to create a role and maintainer pair (opens new window) for yourself.

Most other objects, especially the ones that are related to your resources, should be editable by you and your colleagues in the IT department or Network Operations Centre. For these objects you should be using a single maintainer that is shared by a group of people. In most cases, this maintainer was created when you registered as a RIPE NCC member or became a resource holder in another way. If not, it is always possible to create a shared maintainer (opens new window) at a later point.

Keep in mind that sharing a maintainer doesn't mean sharing the credentials as well, such as a password or a key. As explained earlier, a maintainer can contain multiple authentication attributes, so each person that has access to it can use their own set of credentials.

# Delegating Authorisation Using Maintainers

The idea behind delegation of authorisation is that you can authorise a certain group (either within or outside your organisation) to create objects under a certain parent object that you control. For example, your can allow your colleagues who are responsible for the BGP routing configuration to create route(6) objects to register the announcement in the Internet Routing Registry (IRR), and nothing else. Likewise, you can authorise your DNS group to request Reverse Delegation by creating a domain object and nothing else.

For this purpose, three attributes exist:

* "mnt-lower:", for hierarchical control over one level more specific objects
* "mnt-routes:", for the creation of **route(6)** objects in the IRR
* "mnt-domains:", for requesting Reverse Delegation of DNS by creating a **domain** object

The "mnt-lower:" attribute specifies an existing mntner object used for hierarchical authorisation. It controls creation of objects one level more specific in the hierarchy of an object type (this only applies to inetnum, inet6num, as-block, aut-num, route, route6, or domain objects).

The most common occurrence of the "mnt-lower:" attribute is in the IP address allocation(s) that you have received from the RIPE NCC. For example, if you are an LIR and you have an IPv6 allocation, it is represented in the RIPE Database as an inet6num object. Because the allocation is managed by the RIPE NCC, one of the "mnt-by:" attributes is set to RIPE-NCC-HM-MNT and the other is set by you after choosing the default maintainer. These are some of the attributes you would see:

inet6num:   2001:db8::/32
org:        LIR-ORG-RIPE
status:     ALLOCATED
mnt-by:     RIPE-NCC-HM-MNT
mnt-by:     LIR-NOC-MNT

The RIPE-NCC-HM-MNT maintainer prevents you from making changes to some of the attributes that are part of the RIPE NCC's registry management, such as the "netname:". Your LIR's default maintainer allows you to make changes to attributes you manage, such as the "admin-c:" and "tech-c:". In addition, it allows you to create assignments, as well as route(6) and domain objects under this parent block. However, if you wish to delegate the creation of child resource objects to a separate group, you can do so by creating an additional maintainer for them and specify it as "mnt-lower:":

inet6num:   2001:db8::/32
org:        LIR-ORG-RIPE
status:     ALLOCATED
mnt-by:     RIPE-NCC-HM-MNT
mnt-by:     LIR-NOC-MNT
mnt-lower:  LIR-IPMGMT-MNT

Likewise, you can delegate control over the creation of **route(6)**and domain objects by adding a "mnt-routes:" and "mnt-domains:" attribute to the allocation. Keep in mind that you first have to select a default maintainer before you can do this. The resulting allocation object would look something like this:

inet6num:    2001:db8::/32
org:         LIR-ORG-RIPE
status:      ALLOCATED
mnt-by:      RIPE-NCC-HM-MNT
mnt-by:      LIR-NOC-MNT
mnt-lower:   LIR-IPMGMT-MNT
mnt-routes:  LIR-RTRMGMT-MNT
mnt-domains: LIR-DNSMGMT-MNT

After you have done this, you can achieve fine-grained control over the creation of inet(6)num, route(6) and domain objects.

In this example, route and domain objects are managed by separate maintainers: LIR-RTRMGMT-MNT and LIR-DNSMGMT-MNT respectively, as specified in the allocation. IN addition, a "nt-lower:" was specified in the aggregate prefix for the broadband pool (2001:db8::/36). This allows for the creation of more specific objects below it by LIR-BROADBAND-MNT:

In general, keep in mind that when as inet(6)num, route(6) or a domain object is created, authentication is required from the parent object. If the parent has a "mnt-lower:", "mnt-routes:" or "mnt-domains:" attribute, this is the mntner that will need to be authenticated against. Otherwise the parent "mnt-by:" attribute is used.

# Highlighted Values in the RIPE Database

This function highlights values in the RIPE Database that are maintained by the RIPE NCC. These values are subject to an established due diligence process, which is described in the RIPE NCC procedural document Due Diligence for the Quality of the RIPE NCC Registration Data (opens new window).

# Non-highlighted Values

Objects in the RIPE Database are mostly created and updated by users. The RIPE NCC makes every effort possible within its resources to keep the RIPE Database clean of false, obsolete and unnecessary data. However, the RIPE NCC cannot guarantee the accuracy of all data in the RIPE Database.

Inaccurate values in the RIPE Database, whether highlighted or not, should be reported to the RIPE NCC via the contact form (opens new window).

# Data not Published in the RIPE Database

The RIPE NCC keeps a comprehensive record of all Internet number resources registered within the RIPE NCC service region to ensure that each Resource Holder holds unique and legitimate IP address space and ASNs.

The collective of these data is generally referred to as the "RIPE Registry". Information in the RIPE Registry is subject to the specific and rigorous due diligence checks referred to above. As the RIPE Registry contains information that is subject to data protection laws and to confidentiality agreements between the RIPE NCC and its membership, much of this information cannot be made publicly available. Information from the RIPE Registry that appears in the RIPE Database is not restricted by confidentiality agreements.

# Support Overview

# User Manuals

# Security

# Operational

# FAQ

# What is the RIPE Database?

The RIPE Database contains information about:

  • Allocations and assignments of IP address space
  • Routing Registry Information
  • Reverse DNS Delegations
  • Related objects

The data is entered into the RIPE Database mainly by operators of IP networks within the RIPE NCC service region. These are the maintainers of the data. The RIPE NCC supports the operation of the RIPE Database. The maintainers are primarily responsible for the data but the RIPE NCC also has some responsibility as a Database Controller. The responsibilities are explained in more detail in the RIPE Database Terms and Conditions.

The data is accessible by Whois query (whois.ripe.net) and through a web interface (opens new window), subject to the RIPE Database terms and conditions.

# What is acceptable use of the RIPE Database?

The purpose and use of the RIPE Database is defined in the RIPE Database terms and conditions. The purpose of the RIPE Database is to assist the operation of the Internet in the RIPE region. Use of information from the RIPE Database for activities such as marketing, advertising and distributing Unsolicited Commercial E-mail (UCE) is covered by the Terms and Conditions.

# What is a netname?

A netname is a mandatory attribute of an inetnum object which contains a short but meaningful name of the IP allocation or assignment. Two or more inetnum objects can have the same netname. The netname attribute is a look-up key, one can query the RIPE Database supplying the netname as an argument. The result of the query will show all inetnum objects with that netname.

# What is a nic-hdl?

A "nic-handle" is a unique identifier that references RIPE Database objects containing contact details for a specific person or role. Other RIPE Database objects list contact details by their nic-handle. This is a more reliable identifier than an email address or a person's name (which may not be unique).

# Can I use a nic-handle from another Regional Internet Registry Database in the RIPE Database?

Yes, but you must create a person/role object in the RIPE Database to ensure referential integrity. There is no existing distributed database of person/role objects (i.e. contact information). Please note that updating an object in one database does not mean the object will be updated in any other database.

# What is a tech-c and what is an admin-c?

An "admin-c" (administrative contact) and "tech-c" (technical contact) are network contacts, required to be listed by their nic-handles in certain RIPE Database objects. This is done for operational correspondence such as Network troubleshooting. The admin-c must be physically located at the site of the network. The tech-c does not need to be physically located at the site of the network. You can have multiple admin-c, tech-c and zone-c attributes in an object, each of them referencing different person or role objects.

# Why has my 'as-name:' not been accepted?

The 'as-name:' should be a short name associated with the Autonomous System (AS). We recommend that the name reflects the name of the organisation that will use the AS Number. The name should be made up of letters, digits, the character underscore "_", and the character hyphen "-"; the first character of a name must be a letter, and the last character of a name must be a letter or a digit. The following words are reserved by RPSL, and they can not be used as names: any, as-any, rs-any, peers, and, or, not, atomic, from, to, at, action, accept, announce, except, refine, networks, into, inbound, outbound

Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names. Names starting with "irt-" are reserved for irt names.

# Can I register a domain name in the RIPE Database?

No, the RIPE NCC does not register domain names. A decision was made by the RIPE community to remove all forward domain names from the RIPE Database.

# How do I register a PERSON or ROLE object in the RIPE Database?

New RIPE Database users should create a role and maintainer pair (opens new window). If you already have a maintainer object, you can use webupdates (opens new window) to create a additional objects.

Please note that person objects registered in the RIPE Database should be referenced from other objects in the RIPE Database, either directly or through a role object. Unreferenced objects will be deleted after 90 days.

# Someone has created a person object with my personal details in the RIPE Database. Why did they do this?

Some Internet Service Providers (ISPs) put information about their customers in the RIPE Database. This is usually because you have signed an agreement with the ISP to obtain Internet services from them and given your consent to publish your personal details in the RIPE Database. If you are unhappy with this, please contact your ISP. If you cannot resolve this issue with your ISP, please contact the RIPE NCC (opens new window).

# My information in the RIPE Database is not correct, can you please update my object(s)?

The RIPE Database Terms and Conditions detail who is responsible for maintaining data in the RIPE Database. We suggest you contact the maintainer of the data that is incorrect and ask them to change it. If it is personal data that is incorrect and you are not satisfied with the response from the maintainer, please contact the RIPE NCC (opens new window).

# How do I delete an object from the RIPE Database?

If you query for your object in the RIPE Database web interface (opens new window), you will see the option to update it in the top right corner.

After logging in with your RIPE NCC Access account, you may be required to authenticate against the maintainer that protects the object if it is not yet associated with your account.

You will then get to the screen where you can modify the object. The "delete" button is in the bottom left corner.

After selecting "Delete this object", you will be asked for an optional reason. Once you provide this, the object will be removed from the RIPE Database.

# My update failed. Please explain why it failed.

There are many reasons why an update could fail. Usually, the failure reasons listed in the acknowledgement message you received are self-explanatory. The errors and warnings are contained in the "***ERROR:" and "***WARNING:" lines attached to the object which failed. Please read these lines carefully. Often the errors are simple syntax errors in the object. Check your object for typing mistakes.

Another common mistake is to query the RIPE Database for an object without using the -B query flag, then submit the returned object in an update. This results in submitting a filtered object, indicated by the line 'source: RIPE # Filtered' in the query response.

Sometimes, your update fails with this error message: "***Error: Authorisation failed". This means that you haven't supplied the correct credentials to satisfy the authorisation needed for the maintainer that protects the object. The maintainer is notified of a failed attempt to update this object.

Please note that if you send several objects in one message and at least one of them fails, the subject of the acknowledgment message will start with "FAILED:". This does not mean that the whole update failed, only that some updates were unsuccessful. Please check the message carefully to see which objects were not updated.

# I received a message with the subject "Notification of RIPE Database changes", but I didn't do anything and don't understand the message. What is it?

The message you received has been automatically sent to you from the RIPE Database software. The purpose of this notification is to inform you that some objects have been changed in the RIPE Database. You received the message because you were either listed in a "notify:" attribute of the object itself, or in a "mnt-nfy:" attribute of the mntner that protects the object.

If you did not create or update the object yourself, then someone else did this. The e-mail address from which the update came is usually mentioned in the notification message. Please contact that e-mail address for questions and clarifications about the update.

# What are the authorisation rules for route object creation?

Refer to protection of route object space.

# Can I download the RIPE Database software?

Yes you can download the RIPE database Whois server software from GitHub (opens new window).

# Can I download the RIPE Database?

We produce daily snapshots which are available to the public. You can find these files at our FTP site (opens new window) or split by object type (opens new window).

These daily snapshots exclude the person object type and other personal data is dummified. For data protection reasons, personal data is not available in bulk format.

Another way to "download" the RIPE Database is to become a Near-Real-Time Mirror (NRTM). This means that you run a copy of the database at your site that keeps up-to-date with the master server by regularly downloading the most recent updates. All personal data is excluded from the NRTM download and updates. For more information, refer to Access to NRTM.

# I cannot find any information about a network in the RIPE Database. Can I look somewhere else?

Yes: try full text search (opens new window).

# How do I register reverse-delegations in the RIPE Database?

To register reverse-delegations in the RIPE Database, see Reverse Delegations (opens new window).

# I want to have an IP to country conversion table; can I get it?

The inetnum object represents IP address space in the RIPE Database; this object has a 'country' attribute. However, you should not rely on this information to be 100% accurate.

Resource holders can also add a "geofeed:" attribute to associate IP addresses to geographic locales. Refer to RFC9092 (opens new window) for more information.

# I want to peer with an Autonomous System (AS). How do I do this?

Once an AS number has been assigned to you, you are responsible for keeping it up to date. It is important that your aut-num object in the RIPE Database reflects reality. If you have new peers and/or stop peering with one or more Autonomous Systems, please update your aut-num object. You update this object in the same way as any other object in the RIPE Database.

# Can I enter several contacts in one RIPE Database object?

Yes. You can have multiple admin-c, tech-c and zone-c attributes in an object, each of them referencing different contact record, person or role objects.

# How do I update an object in the RIPE Database?

If you query for your object in the RIPE Database web interface (opens new window), you will see the option to update it in the top right corner.

After logging in with your RIPE NCC Access account, you may be required to authenticate against the maintainer that protects the object if it is not yet associated with your account. You will then get to the screen where you can modify the object.

# Where are the RIR Databases, and what do they contain?

There are five Regional Internet Registries (RIRs). Each maintains a database holding details of IP address registrations in their regions. The RIR databases are located at:

AFRINIC (opens new window) (Africa) ARIN (opens new window) (North America, some Caribbean and North Atlantic Islands) APNIC (opens new window) (Asia Pacific region) LACNIC (opens new window) (Southern and Central America and some Caribbean Islands) RIPE NCC (opens new window) (Europe, the Middle East, parts of Central Asia)

# Why did I receive an Error 201: Access Denied?

There are several cases when this might occur. Please see below for the one which applies to your situation:

  • You (or your application) performed too many queries that returned contact information (e.g. person or role objects) from the RIPE Database. There is a daily limit on the amount of personal data returned as described in the Acceptable Use Policy.
  • Even if you queried for other types of objects, the associated contact information is returned by default. To avoid this situation please use the -r flag to prevent any associated contact information from being returned.
  • You used a proxy server to access the RIPE Database (such as a third-party web query interface). In this case, it is likely that the proxy itself was denied access to the database. Please contact then administrators of the server you were using and discuss this situation with them. They may need to contact the RIPE Database administration ripe-dbm@ripe.net team to request further access.
  • If none of the above describes your situation, please contact the RIPE Database administration team ripe-dbm@ripe.net to discuss the problem further.

# How do I generate glue record for a DOMAIN object?

Here is an example:

domain: 8.8.8.e164.arpa
descr: Example domain for the reserved prefix +888
[...]
nserver: ns1.8.8.8.e164.arpa 192.0.2.1
nserver: ns2.8.8.8.e164.arpa 192.0.2.129
nserver: ns1.example.net
nserver: ns2.example.net
[...]

In this example, the first two "nserver:" attributes contain one glue IP address. THe last two "nserver:" attributes do not need glue, as they are in a different domain - example.net.

# How will I know what to fix if the DOMAIN object update failed?

The responses from our server will include diagnostic messages. You can get further help by sending an email to ripe-dbm@ripe.net.

# How long until an update appears in the DNS?

If you see a message saying that your update was successful, it will be visible in the DNS after around an hour.

# Which TTL value is used?

We will use the default value for the e164.arpa zone. If you need a specific TTL (Time to Live) value, send an email to enum-request@ripe.net.

# Glossary

# Attribute Continuation Line

When an attribute value uses more than one line, the extra lines are continuation lines.

# Autonomous System (AS)

A group of IP networks that have a single and clearly defined external routing policy, operated by one or more network operators.

# Autonomous System (AS) Number

A unique, numeric value given to an AS. The range of numbers starts at 0 and extends up to a maximum value held by a 32-bit unsigned number 4,294,967,295.

# Canonical

Standard or typical. For Ipv6 and DNS, it represents a standard textual representation format.

# Child Object

This object is one level down (more specific) in a hierarchy of INETNUM or INET6NUM objects

# Child objects are more specific

Both IPv4 and IPv6 addresses are structured in hierarchies with 0/0 and ::/0 as the roots of the structures. The root objects have child objects forming the next layer in the hierarchical structure. The root objects are therefore the parents of the child objects. This is repeated throughout the structure as more layers are added. Parent objects are considered to be less specific than the child objects. Child objects are considered to be more specific to the parent objects.

# Contact Details

All details relating to name, postal address, phone, fax, email or any other form of electronica communication that is used by a person or an organisation.

# Data Contained Therein

A legal phrase referring to information stored in the RIPE Database.

# Data Controller

A person or organisation that determines the purpose and the manner in which personal data is processed.

# Dictionary Attacks

In computer security, this is a technique for breaking an authorisation mechanism by trying to determine a password, passphrase or an encryption key by trying hundreds or sometimes millions of likely possibilities, such as words in a dictionary.

# Domain Name

A unique name that identifies an Internet location such as a website.

# Domain Name System Security Extensions (DNSSEC)

The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) specifications for security certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

# Dummification

A process that removes personally identifiable information from the RIPE Database output.

# Dummified

When all personally identifiable information has been removed from the data.

# ENUM

The Internet Engineering Task Force (IETF) protocol that maps E.164 telephone numbers to Internet services using the DNS.

# Global Resource Service (GRS)

The RIPE NCC operated mirrors of the others RIR's databases as well as some of the major routing registries. Only operational data is stored based on the published statistics of authoritative resources from each RIR. The RIPE Whois service allows this set of mirrors to be queried as a single logical database and returns authoritative responses from the appropriate source.

# Glue Record

The IP address of a name server held at the Domain Name registry. Glue records are required when you wish to set the name servers of a domain name to a hostname under the domain name itself.

# Heuristic

Using experience-based techniques for problem-solving.

# Hierarchical Address Space

Individual IP addresses are 'flat' addresses. Each address is unique but it does not say anything about where the address is relative to any other address. They are usually allocated and assigned as ranges of addresses. Further sub allocations and assignments can be made from allocations. This builds an administrative hierarchy within the address space, even though the address space itself is not hierarchical.

# IANA

Internet Assigned Numbers Authority.

# in-addr.arpa

A special domain name used to achieve reverse delegation for IPv4 addresses.

# INET(6)NUM

A common abbreviation meaning both INETNUM and INET6NUM objects.

# Internet Number Registry (INR)

A registry that allocated Internet number resources and holds and publishes details of Internet number resource information.

# Internet Number Resources

Globally unique address space (IPv4 and IPv6) and Autonomous System Numbers (ASNs) issued by any Internet Number Registry.

# Internet Protocol Version 4 (IPv4)

IPv4 uses 32-bit (four-byte) addresses, which gives a total pool of 4,294,967,296 (2^32) addresses. These addresses are normally represented in a dotted quad notation. An example of an IPv4 address is: 192.0.2.35.

# Internet Protocol Version 6 (IPv6)

IPv6 uses 128-bit addresses, which gives a total pool of 2^128 addresses. These addresses are normally represented as eight groups of four hexadecimal digits separated by colons. An example of an IPv6 address is:2001:db8:cd0f:421d:2209:bc:80ba:2095.

# Internet Routing Registry (IRR)

A registry that holds and publishes details of Internet routing information.

# IP Address

A unique numerical address used to identify a particular piece of hardware connected to the Internet. An IP address services two principal functions: host or network interface identification and location addressing.

# ip6.arpa

A special domain name used to achieve reverse delegation for IPv6 addresses.

# Latin-1

A character set defined by ISO8859-1.

# Legacy Resource

Internet number resources that we distributed before (or outside of) the current system of hierarchical distribution by the Regional Internet Registries (RIRs).

# Less Specific

Both IPv4 and IPv6 addresses are structured in hierarchies with 0/0 and ::/0 as the roots of the structures. The root objects have child objects forming the next layer in the hierarchical structure. The root objects are therefore the parents of the child objects. This is repeated throughout the structure as more layers are added. Parent objects are considered to be less specific than the child objects. Child objects are considered to be more specific to the parent objects.

# Maintainer

Any Registrant or person to whom the authority to Update has been delegated by a Registrant either directly or indirectly, and who holds an identifier that allows updates to be authenticated and authorised.

# MD5 Password Hash

MD5 is an algorithm for converting a password or passphrase into a hash of characters.

# Nested

A series of objects are nested when one references the next, that references the next, and so on.

# Network Information Centre (NIC) handle

A sequence of characters that form a unique identifying string used to identify contacts in the RIPE Database (people and business roles).

# Object Template

A pattern or guide describing the characteristics of a specific object type.

# Object Type

There are many different RIPE Database objects representing different pieces of information. They are grouped by type, for example a person object type holds contact information for a person.

# Overlap

One address range crosses the boundary of another address range. For example: inetnum: 10.240.89.60 - 10.240.89.67 inetnum: 10.240.89.64 - 10.240.89.79

# Parent Object

This object is one level up (less specific) in a hierarchy of INETNUM or INET6NUM objects.

# Parse / Parsing

Analyse (a string or text) into logical syntactic components, typically in order to test conformance to a logical grammar.

# Personally Identifiable Information

A legal phrase that means information that can be used to identify a person.

# Prefix

IP address prefixes are patterns which match the first n binary bits of an IP address where n is the prefix.

# Prefix Notification

Specifies ranges using two parts: the starting address and its length (or prefix).

# Primary Key

A unique identifier in the RIPE Database within a set of objects of the same type.

# Primary Objects

The set of objects that contain all the operational data in the RIPE Database. All other (secondary) objects are there to support the primary objects.

# Pseudo-attribute

An attribute added to an object, or an update message, that is not part of the RPSL object structure. It is needed for the management of the object(s) in the update message. For example supplying a password for an update using the "password:" pseudo attribute.

# Query the RIPE Database

To request information from the RIPE Database

# Range Notation

Specifies ranges using two parts: the starting address and the end address separated by a hyphen and space characters ('-')

# Registrant

A natural person or legal entity to whom an Internet number resource has been registered or who has registered any other primary object in the RIPE Database by specific or general agreement with the RIPE NCC.

# Required attribute

The syntax rules define this attribute as optional. However, additional business rules require this attribute to be present under some circumstances.

# Resource Holder

A person or organisation to which an Internet resource has been registered.

# Reverse Delegation

Allows mapping to a domain name from an IP address.

# RIPE Community

RIPE (Réseaux IP Européens) is a collaborative forum open to all parties interested in wide are IP networks in Europe and beyond. The objective of RIPE is to ensure the administrative and technical coordination necessary to enable the operation of a pan-European IP network.

# RIPE Database

The publicly available data collection of Internet Number Registry (INR) data, Internet Routing Registry (IRR) data and Reverse Delegation data published by the RIPE NCC. It contains all the primary and secondary objects. There is also some non-public data required for the operation of the RIPE Database and the registries. Its full title is the RIPE Network Management Database. Or sometime it is referred to as the RIPE Whois Database. But for simplicity it is mostly referred to as the RIPE Database. These names are interchangeable and all mean the same thing.

# RIPE Database Attribute

The key name for a formatted element of data in a RIPE Database object. The format may be well defined or free format. An attribute must always have a value associated with it. Unless it is free format, the value cannot be blank. Attributes are sometimes referred to as keys.

# RIPE Database Object

A record in the RIPE Database containing information about an Internet resource or some supporting or administrative details.

# RIPE Internet Number Registry (RIPE INR)

A registry managed by the RIPE NCC that allocated Internet number resources and holds and publishes details of RIPE resources.

# RIPE Internet Routing Registry (RIPE IRR)

A registry managed by the RIPE NCC that holds and publishes details of Internet routing information.

# RIPE NCC Service Region

This defines the geographical area in which the RIPE NCC provides services as an RIR. This includes Europe, the Middle East and parts of Central Asia.

# RIPE Policy Development Process (PDP)

The RIPE community develops and sets policies through a long-established, open, bottom-up process of discussion and consensus-based decision-making.

# ROUTE(6)

A common abbreviation meaning both ROUTE and ROUTE6 objects

# Routing Policy Specification Language (RPSL)

Allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy.

# Routing Policy System Security (RPSS)

The Internet Routing Registry (IRR) is used for purposes that have a strong requirements for data integrity and security. The Routing Policy System Security addresses issues of data integrity and security consistent with the usage of the IRR and which avoids compromising data integrity and security.

# Secondary Objects

A set of objects that exist in the RIPE Database to support the primary objects.

# Uniform Resource identifier (URI)

The generic term for all types of names and addresses that refer to objects on the World Wide Web. A URL (Uniform Resource Locator or web address) is one kind of URI.

# Update the RIPE Database

Submit information for entry into or removal from the RIPE Database.

# UTF8

A character encoding capable of encoding all possible characters.

# whois Database

An interchangeable phrase sometimes used to describe the RIPE Database. It can also be used to describe other types of databases like domain name registries.

# How to Query the RIPE Database

Querying the RIPE Database is the process of reading information from the database. Historically, this was done from the command line using a whois client. Now, there are a number of ways to query the RIPE Database.

We describe the general format of a query and the query flags that you can use to change the default behaviour of a query.

We also describe how the database server automatically tracks query responses and limits how much contact information you can take from the RIPE Database. We do this to reduce the chance that someone will use the database to send spam e-mails to addresses that they find.

Following Acceptable use policy (opens new window), we strive to detect potential attacks. If a DoS attack is detected, we temporarily block the user's IP address.

The RIPE Database Terms and Conditions (opens new window) allow the RIPE NCC to block or suspend access to the RIPE Database services for any suspected abuse. Users exhibiting suspected abusive behavior may be permanently blocked from the system. If a user is permanently blocked, they will receive a notification informing them of the block whenever they attempt to make a query.

If you wish to be unblocked, please contact the RIPE Database administration team ripe-dbm@ripe.net to discuss further.

# Command Line Queries

Queries can be run from almost any computer (connected to the Internet) using standard features built into most operating systems. Some common methods include Netcat, Telnet and a Whois Client.

# Netcat

Netcat is a computer networking service for reading from and writing to network connections, using TCP or UDP. Netcat can be used directly or easily driven by other programs and scripts. Netcat can often be abbreviated to the command ‘nc'. This is an example query using netcat.

$ nc whois.ripe.net 43
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
-rBGTroute 193.0.7.35
route:          193.0.0.0/21
descr:          RIPE-NCC
origin:         AS3333
mnt-by:         RIPE-NCC-MNT
created:        1970-01-01T00:00:00Z
last-modified:  2008-09-10T14:27:53Z
source:         RIPE
% This query was served by the RIPE Database Query Service version 1.75 (DB-3)

# Telnet

Telnet is a network protocol used on the Internet to provide a bidirectional, interactive, text-oriented, communication facility using a virtual, terminal connection. This is an example query using telnet.

$ telnet whois.ripe.net 43
Trying 2001:67c:2e8:22::c100:687...
Connected to whois.ripe.net.
Escape character is '^]'.
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
-rBGTroute 193.0.7.35
route:         193.0.0.0/21
descr:         RIPE-NCC
origin:        AS3333
mnt-by:        RIPE-NCC-MNT
created:       1970-01-01T00:00:00Z
last-modified: 2008-09-10T14:27:53Z
source:        RIPE
% This query was served by the RIPE Database Query Service version 1.75 (DB-3)

# Whois Client

This is a small program that connects to the RIPE Whois Database, passes the search request to the database and prints out the response. Most computer operating systems include a default, basic whois client. However, these default clients often do not recognise all the added query options that the RIPE Database allows.

# Windows

There is no default whois client in Windows. There are some alternatives which allows you to use a simplified version of whois (opens new window).

# Linux

  • Debian-based distributions: You can install Whois on this distribution using apt install whois

This installs the Intelligent WHOIS Client by Marco d'Itri. For more information, refer to https://github.com/rfc1036/whois (opens new window)

To query the RIPE database, use the format: whois <query-string>

$ whois --version
Version 5.5.13.
Report bugs to <md+whois@linux.it>.
$ whois -rBGTroute 193.0.7.35
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
route:          193.0.0.0/21
descr:          RIPE-NCC
origin:         AS3333
mnt-by:         RIPE-NCC-MNT
created:        1970-01-01T00:00:00Z
last-modified:  2008-09-10T14:27:53Z
source:         RIPE
% This query was served by the RIPE Database Query Service version 1.103 (WAGYU)
  • Fedora-based distributions: You can install Whois using yum install whois

This also installs the Intelligent WHOIS Client. To query the RIPE database, use the format: whois -h whois.ripe.net -- <query-string> You can use -- option to separate whois command options from whois server query options. A query containing spaces must be quoted as one argument to the whois command.

$ whois --version
jwhois version 4.0, Copyright (C) 1999-2007 Free Software Foundation, INC.
This program is free software with ABSOLUTELY NO WARRANTY; you may
redistribute it under the terms of the GNU General Publi Licence
$ whois -h whois.ripe.net -- -rBGTroute 193.0.7.35
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
route:          193.0.0.0/21
descr:          RIPE-NCC
origin:         AS3333
mnt-by:         RIPE-NCC-MNT
created:        1970-01-01T00:00:00Z
last-modified:  2008-09-10T14:27:53Z
source:         RIPE
% This query was served by the RIPE Database Query Service version 1.103 (WAGYU)

# OSX

Whois is a command-line tool that is installed by default on this platform. As an alternative, Whois can also be installed using the Homebrew package manager (opens new window).

To query the RIPE database, use the format: whois -h whois.ripe.net -- <query-string> You can use -- option to separate whois command options from whois server query options. A query containing spaces must be quoted as one argument to the whois command.

$ whois -h whois.ripe.net -- '-rBGTroute 193.0.7.35'
route:          193.0.0.0/21
descr:          RIPE-NCC
origin:         AS3333
mnt-by:         RIPE-NCC-MNT
created:        1970-01-01T00:00:00Z
last-modified:  2008-09-10T14:27:53Z
source:         RIPE
% This query was served by the RIPE Database Query Service version 1.103 (BLAARKOP)

# Query Responses

There is a set of general rules that apply to server responses:

  • The same response will be returned from the server for all query methods.
  • Output lines starting with the % sign are either a server response code or server messages (a comment, information message or an error with description).
  • A message contains a white space after the % sign, while a server response code starts right after the % sign. See Appendix C, RIPE Database Query Server Response Codes and Messages for more information.
  • Do not write scripts to parse the messages. The text is subject to change at any time.
  • An empty line terminates a database object in the output. This is a line containing only a newline character (\n).
  • Two empty lines, each containing only a new-line character (\n), mean the end of a server response.

# Registration Data Access Protocol (RDAP)

The Registration Data Access Protocol (RDAP) is an alternative protocol to WHOIS that specifies how to access internet resource registration data. It is specifically designed to address various shortcomings in WHOIS. It makes use of HTTPS and follows a RESTful (representational state transfer) web services model.

# Using RDAP to query the RIPE Database

The contents of RIPE database can be accessed using RDAP via https://rdap.db.ripe.net/{objectType}/{key} where {objectType} must be one of the object types listed below, and the value of {key} depends on the object type.

List of supported object types

Object Type Description
autnum AUT-NUM objects. Example: https://rdap.db.ripe.net/autnum/3333
domain DOMAIN objects. Example: https://rdap.db.ripe.net/domain/193.0.6.139.in-addr.arpa
ip INETNUM and INET6NUM objects. Example: https://rdap.db.ripe.net/ip/193.0.0.0/21 or https://rdap.db.ripe.net/ip/2001:67c:2e8::/48
entity PERSON, ROLE, ORGANISATION and MNTNER objects. Example: https://rdap.db.ripe.net/entity/RIPE-NCC-MNT

For example, a query for IP information:

curl -v https://rdap.db.ripe.net/ip/2001:67c:2e8:9::c100:14e6

and an example query for domain information:

curl -v https://rdap.db.ripe.net/domain/193.0.6.139.in-addr.arpa

If the RIPE Database is not authoritative for the requested resource, the response will redirect to the authoritative RIR with a HTTP 301 response status.

The entities path segment allows searching for matching entities based on a term. The output is an array with objects in RDAP format.

Syntax:

https://rdap.db.ripe.net/entities?fn={fn}&handle={handle}

Where:

  • fn: Returns all the matches for person:, role:, and org-name: attributes.
    • Example: https://rdap.db.ripe.net/entities?fn=RIPE-RIPE
  • handle: Returns all the matches for organisation:, nic-hdl: attributes.
    • Example: https://rdap.db.ripe.net/entities?handle=RIPE-RIPE

The domains path segment allows searching for matches based on a term. The output is an array with objects in RDAP format.

Syntax:

https://rdap.db.ripe.net/domains?name={name}

Where:

  • name: Returns all the matches for the domain: attribute
    • Example: https://rdap.db.ripe.net/domains?name=196.46.95.in-addr.arpa

# Help

The help path segment return a valid RDAP object containing the default set of notices for the service. The rdapConformance element in the response include the extension identifiers for all the extensions implemented.

Syntax:

https://rdap.db.ripe.net/help

# RDAP Specification

The RDAP protocol is specified in the following RFCs:

# RDAP profiles

In addition to the base RDAP specification, we also implement the following profiles:

# Known Issues

Known issues with the RDAP implementation for RIPE Database can be found on GitHub (opens new window).

# RESTful API Queries

Queries are supported by the RESTful API using the GET method. There are two ways of using the API. One way looks up a specific object and only returns a single object. The other searches for objects matching specified criteria. The search may return large numbers of objects.

The possible values that you can specify for the Accept/Content-Type header are:

  • application/xml for XML
  • application/json for JSON
  • text/plain for TEXT

Clients can also append an extension of ".xml", ".json" or ".txt" to the request URL path instead of setting an Accept: header. The server will return a response in the appropriate format for that given extension. XML format is the default one.

# REST API Lookup

This can be done from the command line using a third party software package, from a script or in a browser. It will only return the one specific object requested. For lookups on address space, it will not return the encompassing object if the specified object does not exist. By default objects are filtered as described in Filtering the Query Response.

Returns an object from the RIPE Database.

curl 'https://rest.db.ripe.net/ripe/inetnum/193.0.0.0%20-%20193.0.7.255?unfiltered'

Any spaces in the command must be encoded. The response will be returned by default in XML format. Alternatively JSON or text/plain can be returned:

curl -H 'Accept: application/json'

Additional resources:

# Method: GET

# URI Format: /{source}/{objectType}/{key}

# Path Parameters

name description
source Source name (RIPE, TEST or a GRS source name).
objectType Type of given object.
key Primary key of the given object.

# Query Parameters

name description
password Password for maintainer authentication (one or more values).
unfiltered The returned object should not be filtered ("notify" and "e-mail" attributes will not be removed). The correct password is required for unfiltered results
unformatted Return the resource in its original formatting (including spaces, end-of-lines).

# Headers

name description
Authorization Basic HTTP Authentication (opens new window). The Authorisation request header value contains 'Basic' followed by the base64 encoding of the maintainer name and password separated by a colon.

# HTTP Response Body

A WhoisResource containing the object, which is filtered by default.

# HTTP status Codes

Client applications should use the HTTP status code to detect the result of an operation. Any error messages will be included in the response body (see below).

Possible reasons for various HTTP status codes are as follows:

code description
OK (200) Successful update
Bad request (400) Incorrect value for object type or key. The server is unable to understand and process the request.
Authentication failure (401) Incorrect password
Forbidden (403) Query limit exceeded.
Too Many Request (429) Query limit exceeded.
Not Found (404) No results were found (on a search request), or object specified in URI does not exist.
Method not Allowed (405) No results were found (on a search request), or object specified in URI does not exist.
Conflict (409) Integrity constraint was violated (e.g. when creating, object already exists).
Unsupported Media Type (415) Unsupported/missing value for Accept/Content-Type header.
Internal Server Error (500) The server encountered an unexpected condition which prevented it from fulfilling the request.

# Examples

  • Example request:

    curl 'http://rest.db.ripe.net/ripe/mntner/RIPE-DBM-MNT'

  • Example JSON request:

    curl -H 'Accept: application/json' 'http://rest.db.ripe.net/ripe/mntner/RIPE-DBM-MNT'

  • Example text/plain request:

    curl -H 'Accept: text/plain' 'http://rest.db.ripe.net/ripe/mntner/RIPE-DBM-MNT'

  • Example unfiltered request:

    curl 'http://rest-test.db.ripe.net/test/person/AA1-TEST?unfiltered'

  • Example unfiltered using password parameter request:

    curl 'http://rest-test.db.ripe.net/test/person/AA1-TEST?password=AA1-TEST-PASSWORD&unfiltered'

  • Example unfiltered using Basic authorisation header request (Basic AA1-TEST:AA1-TEST):

    curl -H 'Authorization: Basic QUExLVRFU1Q6QUExLVRFU1QtUEFTU1dPUkQ=' 'http://rest-test.db.ripe.net/test/person/AA1-TEST?unfiltered'

  • Example bad request when source is incorrect:

    curl 'http://rest.db.ripe.net/pez/person/PP1-RIPE'

  • Example request with encoded query parameter:

    curl 'http://rest.db.ripe.net/ripe/inetnum/193.0.0.0%20-%20193.0.7.255.json'

This can be run in the same ways as the REST API Lookup. This search provides the same set of results as a web or command line query will provide.

Offers the well-known whois search via a rest-like interface.

Documentation on the standard RIPE Database query flags.

As with the lookup, any spaces in the command must be encoded. The response will be returned in XML format by default. Alternatively, JSON or text/plain can be returned.

# Locations

Environment endpoint/search

# HTTP Method: GET

# URI Format: /search?source={source}&query-string={query-string}...

# URI Path Parameters

None.

# URI Query Parameters

name description
source Optional, default is RIPE for http://rest.db.ripe.net. Can specify RIPE or GRS source names. It's possible to specify multiple sources (one source per parameter). Use http://rest-test.db.ripe.net to search the TEST datasource.
query-string The search term. Mandatory.
inverse-attribute Optional. If specified the query is an inverse lookup on the given attribute, if not specified the query is a direct lookup search.
include-tag Optional. Only show RPSL objects with given tags. Can be multiple.
exclude-tag Optional. Only show RPSL objects that do not have given tags. Can be multiple.
type-filter Optional. If specified the results will be filtered by object-type, multiple type-filters can be specified.
flags Optional query-flags. Use separate flags parameters for each option (see examples)
unformatted Don't reformat RPSL objects, preserve all spaces, tabs and newlines in attribute values.
managed-attributes Flag which RPSL attributes are managed by the RIPE NCC.
resource-holder Include the resource holder Organisation (id and name).
abuse-contact Include the Abuse contact email address of the resource, if applicable.
limit Maximum number of RPSL objects to return in the response.
offset Return RPSL objects from a specified offset. This allows for paging.
roa-check Validate route(6) objects against RPKI ROAs and report on any conflicts.

# HTTP Response Body

A WhoisResource containing the query result.

# HTTP Status Codes

code description
200 Search successful
400 Illegal input - incorrect value in one or more of the parameters
404 No object(s) found

Note that search response can be enormous. Hence, it is streamed on the server side, which means that if there is any error during processing your search, the HTTP response will still be 200. In this case, there will be the corresponding error messages inside the errormessages element in the response body (see Whois Resources).

# Examples

  • Valid inverse lookup query on an org value, filtering by inetnum:

    http://rest.db.ripe.net/search?inverse-attribute=org&type-filter=inetnum&source=ripe&query-string=ORG-RIEN1-RIPE

  • Search for objects of type organisation on the same query-string and specifying a preference for non recursion:

    http://rest.db.ripe.net/search?inverse-attribute=org&flags=no-referenced&type-filter=inetnum&source=ripe&query-string=ORG-RIEN1-RIPE

  • A search on multiple sources:

    http://rest.db.ripe.net/search?source=ripe&source=apnic-grs&flags=no-referenced&flags=no-irt&query-string=MAINT-APNIC-AP

  • A search on multiple sources and multiple type-filters:

    http://rest.db.ripe.net/search?source=ripe&source=apnic-grs&query-string=google&type-filter=person&type-filter=organisation

  • A search using multiple flags:

    http://rest.db.ripe.net/search?source=ripe&query-string=aardvark-mnt&flags=no-filtering&flags=no-referenced

  • A search request with invalid flag

    http://rest.db.ripe.net/search?source=ripe&query-string=PP1-RIPE&flags=k

# REST API Metadata

# Metadata (list sources)

List available sources.

# Locations

Environment endpoint/metadata/sources

# HTTP Method: GET

# URI Format: /metadata/sources

# URI Path Parameters

None.

# HTTP Response Body

A WhoisResource containing all available sources.

# HTTP Status Codes

code description
200 Request successful

# Examples

http://rest.db.ripe.net/metadata/sources.json

Example XML response:

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <whois-resources xmlns:xlink="http://www.w3.org/1999/xlink">
  <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/metadata/sources"/>
  <service name="getSupportedDataSources"/>
  <sources>
      <source name="RIPE" id="ripe"/>
      <source name="TEST" id="test"/>
  </sources>
  <grs-sources>
      <source name="TEST-GRS" id="test-grs" grs-id="test-grs"/>
  </grs-sources>
  </whois-resources>

Example JSON response:

{
  "link": {
    "xlink:type": "locator",
    "xlink:href": "http://rest.db.ripe.net/metadata/sources"
  }, 
  "service" : {
    "name" : "getSupportedDataSources"
  },
  "sources": {
    "source": [
      {
        "name": "RIPE",
        "id": "ripe"
      },
      {
        "name": "TEST",
        "id": "test"
      }
    ]
  },
  "grs-sources": {
    "source": [
      {
        "name": "TEST-GRS",
        "id": "test-grs",
        "grs-id": "test-grs"
      }
    ]
  }
}

# Metadata (Object Template)

Returns the RPSL template for given object type.

# Resources

Environment endpoint/metadata/templates

# HTTP Method: GET

# URI Format: /metadata/templates/{objectType}

# URI Path Parameters

name description
objectType The object type for which the template is requested

# HTTP Response Body

A WhoisResource containing the template of the specified type.

# HTTP Status Codes

code description
200 Request successful
400 Illegal input - incorrect objectType

# Examples

Example querying for the template of PERSON:

curl http://rest.db.ripe.net/metadata/templates/person.xml

# REST API Geolocation

Lookup geolocation and language attributes for a particular IPv4 or IPv6 address.

Returns geolocation information for the specified address.

For further background information on the Geolocation feature, refer to the RIPE Labs article here: https://labs.ripe.net/Members/denis/geolocation-prototype-for-ripe-database

# Locations

Environment endpoint/geolocation

# HTTP Method: GET

# URI Format: /geolocation?ipkey={key}

# URI Path Parameters

None.

# URI Query Parameters

name description
key IPv4 or IPv6 address

# HTTP Response Body

A WhoisResource containing locator URIs to matching objects.

For non-200 OK responses, the response body will be in plaintext.

# HTTP Status Codes

code description
200 Geolocation and/or language data was found for the specified address
404 No geolocation data found, or the address does not exist

# Examples

curl https://rest.db.ripe.net/geolocation?ipkey=10.0.0.0

# REST API Abuse Contact

Lookup abuse contact email for an internet resource (IPv4 address, range or prefix, IPv6 address or prefix, AS number).

# Locations

Environment endpoint/abuse-contact

# HTTP Method: GET

# URI Format: /abuse-contact/{resource}

# URI Path Parameters

name description
resource IPv4 address, range or prefix, IPv6 address or prefix, AS number

# URI Query Parameters

None.

# HTTP Response Body

An AbuseResources containing locator URIs to matching objects.

# HTTP Status Codes

code description
200 Matching resource found and abuse contact returned correctly
404 Resource specified was not found

# Examples

curl http://rest-test.db.ripe.net/abuse-contact/AS3333

# REST API Version

Show a specific version of a RIPE Database object.

# Resources

Environment endpoint

# Method: GET

# URI Format: /{source}/{objecttype}/{key}/versions/{versionnumber}

# URI Parameters

name description
source RIPE or TEST
objecttype Object type
key RPSL object key
versionnumber Object version

# Response Body

A WhoisResource containing the requested version of the object or the error message in case of Bad request (see GET).

# Status Codes

code description
200 Version was found
400 Bad request - invalid source, key or version
404 Requested object version not found

# Examples

curl 'https://rest-test.db.ripe.net/TEST/aut-num/AS102/versions/2'

# REST API Versions

Lists all versions of RIPE Database object, including the date and operation for each version.

# Resources

Environment endpoint

# Method: GET

# URI Format: /{source}/{objecttype}/{key}/versions

# URI Parameters

name description
source RIPE or TEST
objecttype Object type
key Requested RPSL Object primary key

# Response Body

A WhoisResource containing information about updates for the requested object or the error message in case of Bad request (see GET).

# Status Codes

code description
200 Success (object found)
400 Illegal input - incorrect key syntax
404 Object not found

# Examples

Example Request:

curl 'https://rest-test.db.ripe.net/TEST/aut-num/AS102/versions'

# Authentication

RESTful API queries can be authenticated in order to retrieve the full object details, e.g. maintainers.

RESTful API queries can be authenticated using the following methods:

  • Password: You can choose between using password query parameter or basic authentication.
  • SSO cookie: If you are using the web application you can automatically be authenticated in one mntner if that mntner is associated to your SSO account.
  • Client certificate: You can supply your own certificate, and it is checked against the queried object's mntner key-certs

# The Structure of a Query

The general format of a query is:

[optional query flag [optional query flag argument]] <query argument>

The query flags may be before or after the query argument.

Many query flags have a short and long format. The short format is:

-short_query_flag [optional query flag argument]
for example,  -B dw-ripe

The long format is:

--long_query_flag [optional query flag argument]
for example, --no-filtering dw-ripe

When a query includes many query flags, the short and long format options may be mixed. You may list each query flag separately, for example:

-B –i tech-c --no-grouping DW-RIPE

You can also group short query flags together. The long query flags must always be separated. When short flags are grouped, only the last flag in a group may have a flag argument, as in:

-Bi TECH-c --no-grouping dw-RIPE

The query argument is not case-sensitive. As shown in the examples above, it can be in upper case, lower case or a mixed case. Query flags are case-sensitive. This applies to both short- and long-format flags. However, the arguments to the query flags are not case-sensitive. There can be an optional space between a query flag and its argument. However, if the query flag argument is a list, there can be no spaces between elements of the list.

-rBG –Tinetnum,inet6num –imb ripe-ncc-hm-mnt
-rBG –T inetnum,inet6num –i MB ripe-ncc-hm-mnt

A list of query flags and query flag arguments are available.

If you type an IP range you will get an exact match IP range if it exists. Otherwise smallest IP range containing it. (inetnum/inet6num and route/route6 objects).

If you type a single IP address you will get the smallest IP range containing this IP address. (inetnum/inet6num and route/route6 objects).

# Web Query Form

The web query form is available at: https://apps.db.ripe.net/ (opens new window).

This is part of the RIPE Database web interface that also includes Webupdates.

The query argument is entered into the form. Many of the query flags can be selected with check boxes. The database source can also be selected this way. If you know the query flags you want, you can also type them into the form with the query argument.

# Using Full Text Search

If you are looking for a specific piece of information and you don't know one of the values required to find what you are looking for, you may consider using the Full Text Search (opens new window) instead of doing a standard query. Full Text Search (opens new window) treats the entire database as a flat text file and allows you to search for anything. The search is done on object text without regard for any relationships. As such, results may be very unstructured, but it can provide a good starting point for more specific standard queries later on. Keep in mind that Full Text Search (opens new window) is only available on the RIPE NCC website and not in other methods to query the RIPE Database.

Personal data may be returned by the Full Text search API. You may be blocked if excessive amounts of personal data is returned. For more information refer to blocking access section

# URI Format: /fulltextsearch/select?...

# Query Parameters

name Default description
q This parameter is used to specify the query for requesting documents. This query allows to filter by the attribute type and/or the object type. This parameter is required.
  • Query for "RIPE": q=(RIPE)
  • Query for "RIPE", filtering by attribute type: q=(org:(RIPE))
  • Query for "RIPE", filtering by object type: q=(RIPE)%20AND%20(object-type:mntner)
  • Query for "RIPE", filtering by attribute and object type: q=(org:(RIPE))%20AND%20(object-type:mntner)
  • Logic expressions are allowed to concatenate more than one term:
    • Querying by "RIPE" and "NCC": q=(RIPE%20AND%20NCC)
    • Querying by "RIPE" or "NCC": q=(RIPE%20OR%20NCC)
    • Querying by "RIPE NCC": q=(%22RIPE%20NCC%22)
    • Querying by "RIPE", filtering by multiple attributes and object types: q=(e-mail:(RIPE)%20OR%20org:(RIPE))%20AND%20(object-type:organisation%20OR%20object-type:person)
    • Keywords: Using "AND," "OR," or "NOT" as a query term is not permitted.
rows 10 The amount of documents to return. The maximum value is 10,000
start 0 The starting row. The maximum value is 100,000
hl false Highlight the matching values from the fetching documents.
hl.simple.pre <b> The highlight PRE value.
ht.simple.post </b> The highlight POST value.
wt xml The format of the highlights. If the format is not xml "hl.simple.pre" and "hl.simple.post" will be discarded.
facet true Count the object types.

There a some limitations to take care on:

  • Not allowed to fetch more than 10,000 documents per request.
  • There is a maximum of 100,000 results per query (with paging).
  • The maximum highlight characters is trim to 100,000 characters.

The possible values that you can specify for the Accept/Content-Type header are:

  • application/xml for XML
  • application/json for JSON

Clients can also append an extension of .xml or .json to the request URL instead of setting an Accept: header. The server will return a response in the appropriate format for that given extension. XML format is the default one.

# How to Recover Access to a Maintainer (MNTNER) Object

If you have lost access to your maintainer (mntner) object, you can send us a request to recover this.

Recover now (opens new window)

Depending on the information that you provide, we will process your request automatically or manually.

We will then add a RIPE NCC Access account to the mntner object. This RIPE NCC Access account holder will then be able to authorise updates in the RIPE Database.

If you have any questions about the process, please contact us (opens new window).

# Automated Process

  1. Please check whether you can access the email account listed in the "upd-to:" attribute of the mntner object. If you cannot access this email account, you can ask for the request to be handled manually instead.
  2. We will send an email containing a unique recovery link to this email address. This link will expire after 12 hours.
  3. You will be prompted to log in to RIPE NCC Access. Please log in using the RIPE NCC Access account that you wish to add to the mntner object.
  4. Once logged in, confirm that we should add your RIPE NCC Access account to the mntner object.
  5. From now on you can update the RIPE Database while you are logged in to RIPE NCC Access.

Update now (opens new window)

# Manual Process

  1. In order for us to manually process you request, please send us the following paperwork (you must complete both steps):
    • An auto-generated PDF statement. Please print the PDF on your company's letterhead, sign it and return it to us.
    • A recent copy of your company registration papers.
  2. We will send you an email with a unique recovery link once we've verified your paperwork.
  3. You will be prompted to log in to RIPE NCC Access. Please log in using the account that you wish to add to the mntner object.
  4. Once logged in, confirm that we should add your RIPE NCC Access account to the mntner object.
  5. From now on you can update the RIPE Database while you are logged in to RIPE NCC Access.

Update now (opens new window)

# RIPE Database Terms and Conditions

The RIPE NCC shall make the RIPE Database publicly accessible under these RIPE Database Terms and Conditions (hereinafter: the ‘Terms and Conditions’). The Terms and Conditions shall apply to anyone who accesses and uses the RIPE Database.

# Introduction

The RIPE NCC is authorised by the RIPE community to act as the registration authority for Internet number resources in its service region and to manage the operation of the RIPE Database.

# Article 1 - Definitions

In the Terms and Conditions, the following terms shall be understood to have the meanings assigned to them below:

RIPE NCC - Réseaux IP Européens Network Coordination Centre. A membership association under Dutch law operating its registered office in Amsterdam, the Netherlands.

RIPE community - RIPE (Réseaux IP Européens) is a collaborative forum open to all parties interested in wide area IP networks in Europe and beyond. The objective of RIPE is to ensure the administrative and technical coordination necessary to enable the operation of a pan-European IP network.

Update - submitting information for entry into or removal from the RIPE Database

Query - requesting information from the RIPE Database

Access - Update and Query the RIPE Database

Internet number resources - globally unique address space (IPv4 and IPv6) and Autonomous System Numbers (ASNs) issued by any Internet Number Registry.

Primary objects - Internet number resources and other data object types that are not directly related to any other primary object type and which are defined by Routing Policy Specification Language (RPSL) or which have been agreed by the RIPE Community as acceptable primary data.

Secondary objects - objects that are defined by RPSL or which have been agreed by the RIPE Community as acceptable secondary data and which are related, either directly or indirectly, to primary objects.

RIPE Database - the publicly available data collection of Internet Number Registry (INR) and Internet Routing Registry (IRR) data published by the RIPE NCC. It contains all the primary and secondary objects. There is also some non-public data required for the operation of the RIPE Database and the registries, but this non-public data does not form part of the RIPE Database.

Registrant - a natural person or legal entity to whom an Internet number resource has been registered or who has registered any other primary object in the RIPE Database by specific or general agreement with the RIPE NCC.

Maintainer - any Registrant or person to whom the authority to Update has been delegated by a Registrant either directly or indirectly, and who holds an identifier that allows updates to be authenticated and authorised.

User - anyone who Accesses the RIPE Database. This includes Registrants and Maintainers.

RPSL - Routing Policy Specification Language (opens new window)

Internet Number Registry (INR) - a registry that allocates Internet number resources and holds and publishes details of Internet number resource information.

Internet Routing Registry (IRR) - a registry that holds and publishes details of Internet routing information.

Contact details - all details relating to name, postal address, phone, fax, e-mail or any other form of electronic communication that is used by a natural person or a legal entity.

# Article 2 - General

  1. Access to the RIPE Database is available to anyone provided these Terms and Conditions are followed.
  2. A User may only Access the RIPE Database and the data contained therein to the extent permitted by these Terms and Conditions. A User who Accesses the RIPE Database agrees to these Terms and Conditions.
  3. Only Registrants and the RIPE NCC have the authority to Update the RIPE Database. To Update the RIPE Database, a Registrant has to take on the role of a Maintainer or authorise a third party to act as Maintainer on his behalf.
  4. A Registrant who accepts a registration of an Internet number resource from the RIPE NCC, or who registers any other Primary object in the RIPE Database, or who copies a registration of an Internet number resource from another registry into the RIPE Database, must accept these Terms and Conditions before assuming a Registrant's authority to Update the RIPE Database, even if that authority is then delegated to a Maintainer.
  5. A Maintainer who is not a Registrant must accept these Terms and Conditions before accepting the delegated authority from a Registrant to Update the RIPE Database.
  6. A Maintainer may only Update the RIPE Database with these types of data:
    • Internet number resources for which the Registrant holds a valid registration
    • Primary objects that are not Internet number resources, for which the Registrant has agreement to register
    • Secondary objects related to either of the above
  7. A Secondary object must be related to an existing or intended valid Primary object at the time of the Update to create the Secondary object in the RIPE Database. At any time this relationship becomes no longer valid, or the intended relation is never completed, the Secondary object must be deleted. It may be subject to automatic deletion by the RIPE Database management software at any time if it is invalid.
  8. Registrants and Maintainers will assist the RIPE NCC with security checks and audits as appropriate.

# Article 3 - 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 Registrants
  • Publishing routing policies by network operators (IRR)
  • Facilitating coordination between network operators (network problem resolution, outage notification etc.)
  • Facilitating network operations by publishing geolocation information about the usage of Internet number resources (including country, region, city of the party to which the resources have been distributed by the Registrants)
  • Provisioning of Reverse Domain Name System (DNS) and ENUM delegations
  • Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information.
  • Scientific research into network operations and topology
  • Providing information to parties involved in disputes over Internet number resource registrations to parties who are authorised under the law to receive such information.

# Article 4 - Use of the RIPE Database

  1. A User may only Access the RIPE Database and the data contained therein for any of the purposes as mentioned in Article 3 hereof and provided these Terms and Conditions are followed. The RIPE NCC is not responsible for any use of data retrieved from the RIPE Database directly or indirectly.
  2. A User may only conduct queries or submit updates of a nature, rate or volume permitted by the Acceptable Use Policy.
  3. The RIPE NCC records details about all queries and updates for purposes including detecting and preventing unacceptable use.
  4. A User may not use the RIPE Database or the data contained therein for advertising, direct marketing, marketing research or similar purposes.
  5. A User may not re-package, download, compile, re-distribute or re-use any or all of the RIPE Database or the data contained therein unless they do so only with an insubstantial part of the RIPE Database or the data contained therein or when permission to do so is granted by the RIPE NCC.
  6. A Maintainer can authenticate updates by using a personal or organisation's identifier of a type supported by the RIPE Database authentication scheme.
  7. The RIPE NCC will assume that any action done, or asked for, using that identifier was carried out, or asked for, by the Maintainer who holds that identifier.
  8. The RIPE NCC may at its sole discretion implement procedures for dealing with lost, cancelled or insecure identifiers.

# Article 5 - Control of the RIPE Database

  1. The RIPE NCC may correct or delete RIPE Database data:
    • according to RIPE policies
    • to comply with applicable law
    • if so ordered by any competent court
    • to fulfill any legal obligation
    • when a breach of the Terms and Conditions has occurred
    • for management operations of the RIPE Database
    • if any data is inaccurate
    • if any data is entered by someone who is not authorised to do so
  2. The RIPE NCC may withdraw the service provided hereunder from a User at any time and is entitled, in its sole discretion, to terminate or slow down a User's Access to the RIPE Database for any reason, particularly a failure to adhere to the Terms and Conditions.
  3. The RIPE NCC may suspend Access to the RIPE Database, or part thereof, for maintenance purposes, upgrades, security fixes and deployment of new services subject to notification of the RIPE community.
  4. The RIPE NCC may, in accordance with the Removal of Personal Data procedure, remove the personal data of an individual upon request by this individual. The RIPE NCC will only take such action when convinced that a valid request from the right person is received.

# Article 6 - Responsibilities

  1. The RIPE NCC does not guarantee the accuracy, or completeness or availability of the RIPE Database or of the data contained therein.
  2. The Maintainer is responsible for keeping all data maintained by them accurate and up-to-date, including correct Contact Details. The data must be good enough to allow the RIPE NCC to contact the Maintainer or Registrant within a reasonable time without having to get information from another source.
  3. The Maintainer who enters personal data into the RIPE Database has a responsibility to inform the individual to whom the data pertains and to obtain their explicit consent for the entry in the public RIPE Database if required by law.
  4. The RIPE NCC is not responsible for the use and any issues arising from the use of any registered Internet number resources.

# Article 7 - Liability

  1. Use of the RIPE Database and the data contained therein is at the User's own risk.
  2. With the exception of any wilful damage or gross negligence committed by the RIPE NCC or its managerial staff, neither the RIPE NCC nor any of its officers, directors, employees, agents or other representatives who make the RIPE Database available or provide any other service whatsoever to the User, shall be liable to the User or to any third party, including any governmental agency, for any claims, losses, damages, liabilities or expenses whatsoever relating directly or indirectly to the use of the RIPE Database, and the User agrees to hold harmless, indemnify and defend the RIPE NCC, its officers, directors, employees, agents or other representatives for any such claims, losses, damages, liabilities or expenses, and all costs and expenses that may be incurred in relation to their use of the RIPE Database, including reasonable attorneys' fees.
  3. All rights of legal action and other entitlements on the part of the User towards the RIPE NCC in connection with the (use of) the RIPE Database shall lapse as soon as a one year term has expired since the date on which the User has become aware of or could in all fairness have been aware of the existence of such rights and entitlements.

# Article 8 - Miscellaneous

  1. If any provision in these Terms and Conditions is held to be invalid in a court of law, this shall not in any way affect the validity of the remaining provisions.
  2. The User acknowledges and accepts that the Terms and Conditions may be amended by the RIPE NCC. The RIPE NCC will make an announcement at least one month prior to any such amendment coming into effect, unless a more immediate change is required for legal or operational reasons.
  3. Changes can also be effected through the Policy Development Process (opens new window).

# Article 9 - Intellectual property rights

  1. The User acknowledges that any and all copyright, trade marks, database rights and other intellectual property rights subsisting in or used in connection with the RIPE Database, the data contained therein, the underlying software and any accompanying documents and agreements are and shall remain the property of the RIPE NCC.
  2. Except as provided herein, the RIPE Database, the data contained therein and any accompanying documents and agreements may not be used, reproduced or made available to third parties without prior written authorisation from the RIPE NCC.

# Article 10 - Governing law

These Terms and Conditions shall be exclusively governed by the laws of the Netherlands. The competent court in Amsterdam shall have exclusive jurisdiction with regard to disputes arising from these Terms and Conditions.

# Building whois

git clone git@github.com:RIPE-NCC/whois.git
cd whois
mvn clean install

# Goals

There are multiple goals for different types of tests

  • unit tests: mvn clean install
  • integration tests: mvn clean install -Pintegration
  • unit + integration tests: mvn clean install -Pall
  • functional tests: mvn clean install -Pendtoend

# Release

To make a release: mvn clean install -Prelease

To perform a release: mvn clean release:prepare release:perform -Prelease

Performing a release updates version in pom.xml, commits+pushes to git, tried to push artifacts to repo, etc..., whereas making a release will simply make a shaded jar using the current version in pom.xml, nothing else.

The release jar will be created in whois-db/target/whois-db-<pom-xml-version>.jar

# Configuring your IDE

  • Install IntelliJ IDEA http://www.jetbrains.com/idea/download/
  • Import project
  • Point to local whois git repository
  • Import using Maven pom

If there are compilation errors, make sure to perform a maven build first, since it will generate required sources:

mvn clean install

# Running whois from within Intellij

  • Ensure MariaDB and the needed databases are created and populated

  • Ensure whois/tools directory is populated with hazelcast.xml file.

  • Ensure a local property is available in tools directory. Copy whois/whois-commons/src/test/resources/whois.properties and whois/whois-commons/src/test/resources/log4j2.xml into whois/tools directory and ensure the following properties are updated to allow running locally, for example have the following:

    port.query=1043 port.api=1080 port.nrtm=1081

Also ensure database username and password matches what you have locally. (Normally this should be dbint with no password)

  • In Run/Debug configuration Set VM options to:

    -Dwhois.config=./tools/whois-local.properties -Dhazelcast.config=./tools/hazelcast.xml -Dlog4j.configurationFile=file:./tools/log4j2.xml

  • Run mvn clean install -Prelease to ensure property variables set in whois.version.properties is available.

  • Start whois by running the Main class net.ripe.db.whois.db.WhoisServer

# Importing multiple maven sub-projects under one project

Unlike other IDEs, in IntelliJ you can have only one project. However, you can import multiple projects as modules. If you want to import the whois project with its modules and also another maven project, e.g. whois-related follow the steps:

  • From the terminal use mvn clean install to build both projects.
  • Create a new Java project (e.g. root-project) in IntelliJ using the suggested options from the wizard.
  • Select Import module, and navigate to whois project pom.
  • Check the option to import recursively maven projects.
  • Select root-project from the project explorer and repeat step 3 and 4 to import the whois-related project.

# Upgrading IntelliJ

If you upgrade to a newer version of IntelliJ, it will ask you to upgrade your old projects as well.

If there are problems in the project just remove the IntelliJ files and re-import the projects:

  • Quit IntelliJ
  • Go to the projects folder
  • Delete .idea folders and *.iml files
  • Re-import the projects as described above.

If you want to delete all your IntelliJ project files you can use the following commands:

find . -iname '*.iml' -print0 | xargs -0 rm
find . -type d -name '.idea' -print0 | xargs -0 rm -rf

# Suggested IntelliJ IDE Preferences

  • Appearance -> Show tool window bars [on]
  • Preferences -> Build, Execution, Deployment -> Compiler -> Compile independent modules in parallel [off] (to prevent "Internal AspectJ compiler error")
  • Editor -> General -> Strip spaces on save (All)

# Coding standard

In general, we follow the standard Java Coding Standard: Code Conventions for the Java Programming Language (opens new window), with the following additions.

# Code Format

  • Use modern IDE (import organisation, variable expansion, code generation features are essential). IntelliJ is recommended.
  • Wrap long lines where it makes sense. Disable automatic line wrapping in IDE; break it where you think it improves readability.
  • Don't include unnecessary comments, code should be self-documenting. Remember: comments have to be maintained too, but they are not covered by tests.
  • Use readable variable names, which are descriptive of the purpose. Rely on variable name completion of your IDE.
  • Don't embed tab characters, expand tabs to 4 spaces. No extra/trailing whitespace.
  • When in doubt, look at existing code & follow conventions.
  • Use explicit imports, not .*

# Java Conventions

  • Use the final keyword on variables, so they cannot change unexpectedly (no side-effects).
  • Use static imports when it makes sense. E.g. do not use them when there are more than one libraries providing the methods you are importing.

# Commits

  • You spend hours, days before making a commit. Do spend that 30 seconds to break it into meaningful parts (e.g. using git gui).
  • Commit cosmetic changes separately (e.g. as 'reformatted code') to make code review easier.
  • Add good explanation as a commit message. Focus on why, not the how.
  • Add warnings where you find necessary (e.g. 'will have to apply sql patch before deployment').

# File Naming Conventions

  • Unit Test classes are named <Component>Test.java, located under src/test/java.
  • Java Integration test classes are named <Functionality>TestIntegration.java, also under src/test/java.
  • Groovy Integration tests are named <Functionality>Spec.groovy, under src/test/groovy.

# Testing

  • Use Hamcrest assertions (ie assertThat(..., is(..)) instead of assertEquals(..,..))

# IntelliJ Editor Settings

  • Settings / Code Style / Java / Wrapping / Field Annotations = 'do not wrap'
  • Settings / Code Style / Java / Imports / class count = 999, names count = 999

# Git

  • Please use "git pull --rebase" to merge remote changes.
  • git config --global pull.rebase true

# Configure MariaDB

Installing a MariaDB server is useful for development, or for running your own Whois server.

# Configuration

Set the following variables in the MariaDB configuration (location varies depending on installation, the configuration file is normally called my.cnf).

# Development machine

If MariaDB was installed through brew on an Apple Silicon machine, new configuration files can be added under /opt/homebrew/etc/my.cnf.d/.

Add the following configuration (e.g. in ripedb.cnf):

[server]
default-time-zone=+00:00
innodb_file_per_table = OFF
max_connections=1000

# Running your own Whois server

If you wish to run your own Whois server, you need additional variables to be modified:

  • max_allowed_packet = 20M

    • We need big packet sizes as some objects are very big
    • Default is 1M
    • Ref. https://mariadb.com/kb/en/mariadb/server-system-variables/#max_allowed_packet

  • innodb_buffer_pool_size = 2G

    • as we only have innodb databases, this should be set to use all the remaining memory available
    • leave some memory for the OS, and the Whois Java process, and check for swap activity
    • default is 128MB
    • Ref. https://mariadb.com/kb/en/mariadb/xtradbinnodb-server-system-variables/#innodb_buffer_pool_size

Restart MariaDB once all configuration changes have been made.

# Configure access to the database

  • Check if MariaDB is running mysqladmin -u root -p ping
  • Login to MariaDB using mysql -u root -p (or mysql with the default setup)
  • Create users:
CREATE USER 'dbint'@'localhost' IDENTIFIED BY '';
GRANT ALL PRIVILEGES ON *.* TO 'dbint'@'localhost';
CREATE USER 'rdonly'@'localhost' IDENTIFIED BY '';
GRANT SELECT PRIVILEGES ON *.* TO 'rdonly'@'localhost';

Logout with CTRL+D

# Getting Started on macOS

It is recommended to use Brew (opens new window) for quick installation of required binaries.

# Java

# Installation

Install OpenJDK 17 or higher.

# Using Brew (opens new window)

  • Run brew install openjdk

# Manually

  • Download and manually install OpenJDK from https://adoptium.net/

Make sure after installation that running java -version reports the correct Java version.

# Multiple Java versions

If you have multiple Java versions installed, ensure that you have $JAVA_HOME set, and that the $PATH contains $JAVA_HOME/bin.

# Maven

Maven can be installed through Brew (opens new window): run brew install maven

# Git

Git (opens new window) can be installed via Apple's Xcode Command Line Tools or Brew.

If Brew is installed, Git should already be installed, as it requires Apple's Xcode Command Line Tools.

# Git Bash completion (optional)

Bash can complete Git commands, but it needs additional setup.

# Using Brew (opens new window)

The Git formulae ships Git's bash completion:

  • Run brew install git

bash-completion is required for bash completion to work. Depending on which bash is used, a different formulae must be installed:

  • For Homebrew's bash (>= v4): Run brew install bash-completion@2
  • For macOS's bash (v3.2.57): Run brew install bash-completion

Read the formulae's caveats for instructions on how to activate bash-completion by adding a line in your .bash_profile.

# MariaDB

# Installation

The easiest way of installing MariaDB is through Brew (opens new window): run brew install mariadb

# Configuration

Configure MariaDB

# Getting started on Ubuntu Linux

# Install packages

As root, install a set of packages already available in the Ubuntu Linux repositories:

sudo apt-get install git maven oracle-java8-jdk mariadb-client-5.5 mariadb-server-5.5

# Configure MariaDB

Configure MariaDB

# System

If at one point you see an error from MariaDB like 'too many open files' then update /etc/sysctl.conf

sysctl -w kern.maxfiles=1048600
sysctl -w kern.maxfilesperproc=1048576

# Installation instructions

In this section we show how to make a standard setup of whois.

# Prerequisite

Ensure MariaDB and the needed databases are created and populated

# Requirements

  • A server with 8GB RAM, 8GB swap, and 120GB disk space is recommended to run Whois.
  • Create a role user to run whois server (by default, dbase)
  • Whois root directory, owned by role user
  • MariaDB configured
  • jmxterm-1.0.4-uber.jar (opens new window), downloadable from the GitHub project linked on http://wiki.cyclopsgroup.org/jmxterm.
    • For JDK 17, jmxterm has a problem. As a workaround you can add --add-exports jdk.jconsole/sun.tools.jconsole=ALL-UNNAMED to Java for jmxterm to make use of the jconsole module.
  • pgrep
  • /usr/lib/sendmail-compatible mailer, like exim

# Setup

  • Create a "fat"/shaded jar using mvn clean install -Prelease. If you have issues, check the build page.
  • Copy whois-db/target/whois-db-<version>.jar to whois root directory and rename to whois.jar
  • Copy the files tools/hazelcast.xml, whois-commons/src/test/resources/log4j2.xml from the repo to the whois root directory
  • Copy whois-commons/src/test/resources/whois.properties from the repo to whois root directory and rename to properties
  • Copy downloaded jmxterm jar to the Whois root directory.
  • Adjust properties to match your setup (e.g. JDBC URLs, port numbers, etc...)
    • for the example below we use port.query=1043 and port.api=1080 and port.nrtm=1081
  • Create the databases WHOIS_LOCAL, MAILUPDATES_LOCAL, ACL_LOCAL, INTERNALS_LOCAL.
CREATE DATABASE WHOIS_LOCAL;
CREATE DATABASE MAILUPDATES_LOCAL;
CREATE DATABASE ACL_LOCAL;
CREATE DATABASE INTERNALS_LOCAL;
CREATE DATABASE NRTM_LOCAL;

Explanation: Firstly connect to mysql server with mysql command and then create database one by one with create database DATABASE_NAME command

  • For each of the above databases, run the *_schema.sql scripts found in ./whois/whois-commons/src/main/resources/.
use WHOIS_LOCAL;
source ./whois-commons/src/main/resources/whois_schema.sql
use MAILUPDATES_LOCAL;
source ./whois-commons/src/main/resources/mailupdates_schema.sql
use ACL_LOCAL;
source ./whois-commons/src/main/resources/acl_schema.sql
use INTERNALS_LOCAL;
source ./whois-commons/src/main/resources/internals_schema.sql
use NRTM_LOCAL;
source ./whois-commons/src/main/resources/nrtm_schema.sql

Explanation: Select database with command use DATABASE_NAME to be able to run schema on it with command source PATH_TO_SCHEMA

  • For the ones that match, run their *_data.sql script equivalents found in ./whois/whois-commons/src/main/resources/.
use WHOIS_LOCAL;
source ./whois-commons/src/main/resources/whois_data.sql
use INTERNALS_LOCAL;
source ./whois-commons/src/main/resources/internals_data.sql
use NRTM_LOCAL;
source ./whois-commons/src/main/resources/nrtm_data.sql

  • Start whois by executing the following command. Use -Ddump.total.size.limit to specify the dump size:

    /usr/bin/java -Dwhois -Djsse.enableSNIExtension=false -Dcom.sun.management.jmxremote -Dhazelcast.jmx=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1099 -Xms1024m -Xmx8g -Dwhois.config=properties -Duser.timezone=UTC -Dhazelcast.config=hazelcast.xml -Dlog4j.configurationFile=file:log4j2.xml -jar whois.jar

    • If the test query for 193.0.0.1 does not result in an inetnum returned, the init script will return a failure. If your database is empty for example, this is normal. You might want to adjust the test whois query to match your needs.

      telnet localhost 1043
193.0.0.1

    • Ignore exceptions in the log starting with [DatabaseVersionCheck] Error checking datasource...

  • The logs will be printed in the console, notifying about the progress

  • Kill the process to stop the server

  • Use java --add-exports jdk.jconsole/sun.tools.jconsole=ALL-UNNAMED -jar jmxterm-1.0.4-uber.jar -v verbose to access the administrative interface exported via JMX

# Load local whois with initial test content

  • For testing purposes, use source=TEST in the properties file

  • Make sure that in properties the port.query and port.api are not zero (e.g. 1043, 1080 respectively).

  • Copy the file whois-scheduler/src/test/resources/TEST.db to the whois root directory

    • The file TEST.db contains an initial set of RPSL objects used for testing purposes.

  • While the server is running, use pgrep to find the server's PID (pgrep java)

  • Now knowing the PID, while the server is still running, use JMX to load the database with the content of TEST.db:

    java --add-exports jdk.jconsole/sun.tools.jconsole=ALL-UNNAMED -jar jmxterm-1.0.4-uber.jar -v verbose
open (PID HERE)
bean net.ripe.db.whois:name=Bootstrap
run loadDump comment TEST.db

  • When the import is finished you should see a message in output like 220 succeeded (objects).

  • Exit the JMX console

  • Test that it worked by executing a query using telnet:

    telnet localhost 1043
10.11.11.0

  • Test the REST API with curl:

    curl http://localhost:1080/whois/test/inetnum/10.11.11.0/24

If you want to add content, you can use the TEST-DBM-MNT mntner whose password (emptypassword) is the remarks line.

  curl http://localhost:1080/whois/test/mntner/TEST-DBM-MNT?password=emptypassword

You can check the instructions in WHOIS-REST-API for more info about the REST API

# How to allow unlimited queries

The Whois server can block a client's IP as explained here.

You can allow unlimited queries from a certain IP by running a few queries as follows.

The database ACL_LOCAL contains tables related to access control logic in whois. Let's say that the blocked IP is 192.168.0.1.

  INSERT INTO ACL_LOCAL.acl_limit (prefix, daily_limit, comment, unlimited_connections)
  VALUES
  ('192.168.0.1/32', -1, 'a comment', 10000000);

Also make sure there is no other line with the same prefix (192.168.0.1/32) in this table.

Also run the following, just in case this IP is permanently denied:

  DELETE FROM ACL_LOCAL.acl_denied WHERE prefix = '192.168.0.1/32'
  DELETE FROM ACL_LOCAL.acl_event WHERE prefix = '192.168.0.1/32';

If MariaDB says that no row was affected, it is fine.

If your client has IPv6, use the IPv6/64 prefix.

Commit the changes and in a couple of minutes the Whois server will pick it up and will not block that IP again.

# Conventions Used in the RIPE Database Documentation

The following conventions are used:

  • <label> indicates a placeholder or syntax.
  • [option] indicates optional text or command argument.
  • bold font indicates an object type.
  • "attribute:" indicates an attribute of an object.
  • ‘value' indicates the value of an attribute.

The term "RIPE Database" is used in several ways depending on the context. It may mean the:

  • Entire service
  • Database software
  • Interface
  • Logical database
  • Database contents

Where there is any doubt, we will clarify what is being discussed.

# Intended Audience

This documentation has been written for both casual and experienced users of the RIPE Database. This documentation assumes a basic knowledge of computing. It also covers more technical aspects for users who wish to run their own local instance of the RIPE Database software.

# RIPE Database Documentation Overview

This is the starting point for information about the RIPE Database. Everything that you need to know to use the RIPE Database will be described within these pages. If anything is missing or unclear, please contact us (opens new window) and we will do our best to help.

The format of this documentation is a Master Index with headings and sub-headings. Each of these (sub-)headings links to a separate web page. This web page may be an index page to a series of other web pages. This documentation explains the RIPE Database in a large collection of small documents on specific topics with a comprehensive index so that the information is easy to find.

There is a Glossary of Terms and Definitions that explains the meaning of commonly used terminology, phrases, words and acronyms related to the RIPE Database. There is also a set of references to other articles, standards and agreements relating to the RIPE Database.

There is a strong relationship between the full set of documentation and software releases. With every new release, the whole set of documents will be updated to reflect the changes in the software. The previous sets of documentation will still be available to view online or download as a PDF document.

These documents describe the technical features of the RIPE Database and how to use it. For a full explanation of why the RIPE Database works the way it does you may need to refer to the relevant RIPE Documents (opens new window).

# Notifications

The RIPE Database returns different types of information to various specified users. When a user submits an update, an acknowledgement (ack) message is returned to that user. This may an email message or via some other HTTP connection. By using any of the notification attributes, notification (notif) messages can be sent to specified users who want to know about certain operations on one or more objects. These notif messages are always sent by email.

# Acknowledgment Message

The acknowledgement (ack) message is always returned to the user who submitted the update to the database, however, the ack message is a unique notification because it is returned via the same method that was used to submit the update. So, for an email update, the ack message is returned to the email address that sent the update. For any other update method, the ack message is returned as an HTTP response.

The original style of the ack message was designed for an email update response. The same ack message was later used for both Syncupdates and Webupdates. Now Webupdates has a more customised web style of ack message, but Syncupdates still uses the original email ack message style. The RESTful API response is totally different and returns either XML or JSON.

Regardless of the update method, one ack message is returned for each update. The results of all operations on all objects contained in the update are included in the single ack message. For all updates, an ack message that is in the original email style is always generated by the database software. This is logged in the RIPE NCC's internal log of database changes, along with copies of all notif messages.

# Email Acknowledgement Message

This ack message holds the overall result of the update, which either ‘FAILED' or was a total ‘SUCCESS'. If the update included several objects and the operation on any of those objects failed, then the overall result is ‘FAILED'. If no individual operation failed, then the overall result is ‘SUCCESS'. This includes any individual ‘NOOP' results where no operation was carried out, as the submitted object was identical to the object already in the database. This overall result is stated at the start of the subject line of the ack email sent to the user. Any user comment on the Subject line of the submitted update follows this result.

Subject: SUCCESS: some user comment
Date:    Thu, 11 Sep 2014 10:42:15 +0200 (CEST)
From:    RIPE Database Administration local <unread@ripe.net>
To:      denis@ripe.net

The acknowledgement message content is split into sections. The first section shows from where the update was sent. This could be a copy of the update email header or the IP address for a synchronous connection. This section also includes a summary of the update results, explaining how many objects were recognised by the database software, how many operations were successful and how many failed.

An example first section of an acknowledgment message would look like this:

>  From:       Denis Walker <denis@ripe.net>
>  Subject:    some user comment
>  Date:       Thu, 11 Sep 2014 10:42:14 +0200
>  Reply-To:   Denis Walker <denis@ripe.net>
>  Message-ID: <54116066.7030403@ripe.net>
SUMMARY OF UPDATE:
Number of objects found:                   5
Number of objects processed successfully:  4
Create:         1
Modify:         2
Delete:         0
No Operation:   1
Number of objects processed with errors:   1
Create:         0
Modify:         1
Delete:         0

The next section is the "DETAILED EXPLANATION" of the acknowledgement message. This is split into three parts.

  • The first part lists all the objects where the operation failed. This will include "***Error:" messages as well as possible "***Info:" and "***Warning:" messages.
  • The next part shows all the operations that were successful. This may include additional "***Info:" and "***Warning:" messages with each operation listed.
  • The third part lists all the paragraphs from the update message that were not recognised as objects.

Each part is separated in the ACK by a line containing several '~' characters. Within each part, the objects and paragraphs are listed in the order that they were processed. This is generally the order that they appear in the update message unless ‘AUTO-n' NIC Handles are referenced. The line before each object contains three hyphen characters (-) . This allows for easy parsing by script.

Below is an example of this section of the acknowledgement message:

DETAILED EXPLANATION: 
***Warning: Invalid keyword(s) found: some user comment
***Warning: All keywords were ignored
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following object(s) were found to have ERRORS:      
---
Update FAILED: [person] dn1172-ripe          de nis
***Error: Syntax error in object
person:          de nis
address:         here
phone:           1
***Error: Syntax error in "1"
nic-hdl:          dn1172-ripe
mnt-by:         TEST-MNT
source:          ripe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following object(s) were processed SUCCESSFULLY:
---
Modify SUCCEEDED: [person] dn1172-ripe          de nis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following paragraph(s) do not look like objects
and were NOT PROCESSED:
This is a private email.
It is intended only for the named recipient.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are many reasons why the operation may fail for an object, including syntax error, authorisation failure and failed business rules check.

~

# Syncupdates Acknowledgement Message

There are only two differences between an ack message returned from a Syncupdate update and an ack message returned from an email update. The ‘SUCCESS' or ‘FAILED' result shown in the email's subject line is now shown as a code in the first line of a Syncupdates response. However, this response code does not provide the same information. An update that fails with an authorisation error will return response code 403. Any other object update failure,or success, will return response code 200. This indicates that the update was successfully processed. It does not mean that all the objects in the update message were successful operations. This must be determined from the numbers of successes and failures in the SUMMARY part of the message output.

If you use Syncupdates via the web form (see the section 'Syncupdates') there is no response code. All information has to be interpreted using the content of the ack message.

The second difference is also in the first section of the ack message. Whereas the email ack message gives details of the received email, the Syncupdates ack message gives details of the IP address sending in the update.

- From-Host: 2001:67c:2e8:13:198e:207d:6a7:47c5
- Date/Time: Fri Sep 12 11:39:37 2014

# Webupdates Acknowledgement Message

The Webupdates ack message is very different to both the email and Syncupdates ack message. Only a single object is allowed in a Webupdates update message. If the update is successful one of the following messages is added to the top of the output:

  • Object successfully created
  • Object successfully updated!
  • PERSON object DI1432-RIPE successfully deleted

If the update fails, the errors are shown in different ways depending on the web format that you are using. If you are using the field format, a general error message may be displayed at the top of the form:

A specific error will be added, immediately after the attribute that contains the actual error:

If it is a general error that does not relate to a specific attribute, but rather to the whole update, this error message will be shown at the top of the output:

If you are using the single text area, error messages cannot be added after the attribute that contains the error. Therefore, in this case, all error messages will appear at the top of the output:

# RESTful API Acknowledgement Message

The ack message for an API update is returned as either an XML or JSON response. The response includes the object that was submitted in the update. If there was an error, an error message section is included at the end of the response. For example an XML error response would include this section:

<errormessages>
    <errormessage severity="Error" text="Syntax error in %s">
        <attribute name="phone" value="31 20 535 4444"/>
        <args value="31 20 535 4444"/>
    </errormessage>
</errormessages>

For a creation, using the API, that returns an error message, the output is the same as for an API update. If creation is successful, the version of the object that has been added to the database is returned. This may be different to the version that was submitted in the update if it has any generated attributes.

# Notification Messages

There are a number of attributes that may cause notification (notif) messages to be generated:

  • "notify:"
  • "mnt-nfy:"
  • "upd-to:"
  • "irt-nfy:"
  • "ref-nfy:"

Where there are multiple instances of any notification attribute, all email values will be sent an individual notif message email. Where the notification attribute is contained in a referenced object (for example, in a mntner) and there are multiple references, all the referenced objects will be taken to form a list of email addresses. All these addresses will be sent an individual notif message email. Updates can contain multiple objects. These objects can contain different sets of notification email addresses. Some of the notification email addresses may appear in more than one set. Each email address to be sent a notif message has its own individual message generated that only contains details of the objects that reference that email address. So each notif message that is sent may contain different information.

There are many attributes related to notifications. These may be contained in many related objects. All the notification attributes can take multiple values and all appropriate email addresses will be used. It is not always obvious why you have received a notification. You can find out why you received a notification by following all references from the object(s) listed in the notification message and looking at the notification attributes that all of these objects contain.

# Notification Attributes

The "notify:" attribute is an optional attribute in all object types. It is used when an object is successfully created or updated. The "notify:" attribute of the old version of the object is used if the object is being modified. If the update fails for any reason then no notifications will be sent to any "notify:" email addresses.

The optional "mnt-nfy:" and mandatory "upd-to:" attributes can only be included in mntner objects.

When a maintained object is updated successfully, a notification message will be sent to email addresses contained in all "mnt-nfy:" attributes of all mntner objects that are referenced by the updated object.

Sometimes an update fails one or more of the required authentications. This is considered a security issue. It could mean that someone is attempting to gain control of or change your data. In this case, notifications are sent to all the email addresses contained in all the "upd-to:" attributes of all the mntner objects that are referenced by the object in the update. This is sometimes the only attribute holding an email address that is associated with an object. The RIPE NCC may occasionally use this email address to contact someone related to an object in the RIPE Database for any security-related issue. More general issues may also be raised addressed using this email address if this is the only contact point for an object.

The optional "irt-nfy:" attribute is only allowed in an irt object. This is used when a reference to an irt object is added to, or removed from, an inetnum or inet6num object (by means of the "mnt-irt:" attribute).

The optional "ref-nfy:" attribute is only allowed in an organisation object. This is used when a reference to an organisation object is added to an object (using the "org:" attribute).

# Format of the Notification Message

The format of a notification message is similar to the ack message for an email update. The first section of the message explains why you are being sent this notification. The next section of the notification message has the email header or IP address details showing where the update came from. The final section shows the changes that were contained in the update message, if it was successful. For a creation it shows the newly created object. For a deletion, it shows the object that was deleted. For a modification, it shows the new version of the object. In this case, a ‘diff' is also included to show the difference between the original object and the new object. If the modification update failed, the current version of the object is shown and the diff shows the change that was being attempted.

If using passwords in an update message, be cautious when entering this. If you mistype the password pseudo-attribute (eg "password: clear_password") the notification will include your clear text password.

The "upd-to:" attribute in a MNTNER object should only include the email address of a person or team in your organisation who deals with security issues. If this team receives a notification containing a clear text password, they should advise the user to change their password.

Each notification message is only sent to a single email address. There is no email address copied (via CC) in any notification. When multiple email addresses need to be notified of the same update, each address will receive its own email. This email will contain all notification details of objects that are contained in the update message that relates to that email address. For an update with multiple objects, referencing several mntner objects, where several objects have a variety of notification attributes, the software builds a matrix of email addresses and updated objects. This ensures that only the appropriate details are sent to each email address.

# Related Software and Tools

# RIPE Database Tools

The RIPE Database is a BSD licensed open source project on Github (opens new window). You can read, verify and contribute to the source code. If you find a bug in the RIPE Database, please ket us know (opens new window). On this page you can find an overview of all tools to help you manage your RIPE Database objects.

# Reset a lost MD5 maintainer password

If you lost your MD5 password, you can use this form to request a reset. It requires you to log in with your RIPE NCC Access (SSO) account (opens new window), which you can create if you don't have one yet. If possible, the process should be completely automated, but in some cases it may require intervention from a Customer Services representative. Please note that our policy is to replace a lost MD5 password with a RIPE NCC Access (SSO) account, as this is more secure and allows you to reset a lost password seamlessly in the future.

# My Resources

My Resources (opens new window) offers an overview of all IPv4, IPv6 and ASN resources you hold or sponsor at a glance. It displays allocation usage, as well as an overview of all more specific ranges that have been created under each allocation. An inline editor allows for intuitive updates.

# Geolocation in the RIPE Database

The RIPE NCC is not a geolocation provider. Following a unanimous decision by the RIPE NCC Executive Board not to support resource expenditure in the area of geolocation services, the RIPE NCC has no plans to become a provider.

A number of companies provide geolocation services, including:

If you are a geolocation provider and would like to be added to this list, please contact us.

The RIPE Database offers the "geoloc:" attribute on ORGANISATION and INET(6)NUM objects that may or may not be used as an additional source of information by these providers.

If you want to update the geolocation on your inet(6)num object you can do so using webupdates. Just search for your object (opens new window) and update it. To add a "geoloc:" attribute, click the "+" icon and select the "geoloc:" attribute. The value can be entered as two floating point numbers if you know the longitude and latitude. Please be aware that this information may not be picked up by geolocation providers.

If you want to find the geolocation of an IP Resource, you can use the RIPEstat geolocation widget (opens new window).

Please be aware that geolocation information is added by the resource holders in the RIPE Database and the RIPE NCC does not verify this information.

# RIPE Database Release Notes

This page will be updated with every release of the RIPE Database software. The version number of the production software is visible at the end of each query as a comment and is also presented at the end of each update acknowledgement.

You can test an upcoming Release Candidate (RC) in the Release Candidate environment

Upcoming Release

Current Release

Previous Releases

Archive of Older Releases (opens new window)

# Release Candidate Environment

The Release Candidate environment contains the upcoming release of the database software with a dummified snapshot of the production data. The dummification is only applied to personal data. This environment makes it possible for you to test your software with upcoming versions of the RIPE Database.

# Information About Services

Service Location
command line whois-rc.ripe.net, port 43
syncupdates https://syncupdates-rc.db.ripe.net
REST API https://rest-rc.db.ripe.net
RDAP API https://rdap-rc.db.ripe.net
web application https://rc.db.ripe.net
mailupdates rc-dbm@ripe.net

# Differences From Live RIPE Database

  • For each mntner object in the Release Candidate database, the passwords have been set to the object id. For example, the object:

inetnum: 193.0.0.0 - 103.0.7.255 ... mnt-by: ninja-mnt ... can be changed by supplying the password: ninja-mnt. Regardless of the passwords used in the live RIPE Database, in the Release Candidate database they have been adjusted to reflect the mntner id.

  • The databases are snapshots of live RIPE Database data, dummified in the beginning of each new testing period. Personal data is replaced during the dummification process.
  • No emails are sent from the Release Candidate system. This means no response from mailupdates submissions to the Release Candidate database, no ack or notify emails are sent by the Release Candidate database.

# Notes

As in the live RIPE Database, Access Control Lists (ACLs) are active. Even though the personal data in the Release Candidate database is dummified, ACLs are active to ensure it operates in the same way as the production system.

Even though the Release Candidate database contains snapshot of the live data from the start of the testing period, no changes made to the Release Candidate database will have any impact on the live RIPE Database data. The two are completely separated.

Any scripts or automated processes you use to maintain your data in the RIPE Database can be used with the Release Candidate database - simple adjust the URLs accordingly. The whole purpose is to allow you to test your processes as closely as possible to the action RIPE Database using newly developed and released software.

# RIPE Database Release 1.100

# Date of Deployment

Release Candidate (RC) environment: 8 April 2021 Production environment: 22 April 2021

# New or Improved Features

Whois Release 1.100 includes the following main changes:

  • Separate email address and leading/trailing space during Punycode conversion (#782)
  • Use status index during update validation (#725)
  • Fixed aut-num attribute managed flag in lookup and search response (#749)
  • Added client flag to API for proxying requests (#728)
  • RDAP nameserver not implemented (#711)
  • Fixed delete object bug (#723)
  • Java 11 support (#673)
  • Update dependencies

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.101

# Date of Deployment

Release Candidate (RC) environment: 17 June 2021 Production environment: 1 July 2021

# New or Improved Features

Whois Release 1.101 includes the following main changes:

  • Switch RIPE database to UTC timezone
  • Display an error on NRTM if client is blocked by ACL limit (#812)
  • Added rewrite rules to embedded jetty (#801)
  • RDAP nameserver queries always return Not Implemented (#811)
  • Updated dependencies

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# Operational Changes

Some operational changes will also de made to the production environment on 1 July 2021:

  • Remove support for TLS versions 1.0 and 1.1 on HTTPS connections
  • Remove unsecure TLS cipher algorithms
    • TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
    • TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
    • TLS_DHE_RSA_WITH_SEED_CBC_SHA
    • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SH
  • Remove HTTP redirects for whois.ripe.net and www.db.ripe.net
    • HTTP requests to these hosts will no longer redirect to https://apps.db.ripe.net but will return 400 Bad Request.
  • Remove HTTP redirects for the legacy Whois REST API
    • The legacy Whois REST API was retired in 2015, a temporary redirect is now being removed.
    • HTTP requests to http://apps.db.ripe.net/whois/lookup/ripe will return 400 Bad Request.

Please check your Whois client in case you are affected by these changes.

# RIPE Database Release 1.102

# Date of Deployment

Release Candidate (RC) environment: 23 November 2021 Production environment: 7 December 2021

# New or Improved Features

Whois Release 1.102 includes the following main changes:

  • NWI-13: Geofeed (#937)
  • Support base64 encoded signed update messages (sent by Thunderbird 78+)(#942)
  • Updated "geoloc:" help text (#929)
  • Support IDN in outgoing mail update notifications (#888)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.102.1

# Date of Deployment

Release Candidate (RC) environment: 13 December 2021 Production environment: 13 December 2021

# New or Improved Features

Whois Release 1.102.1 includes the following main changes:

  • Updated Log4j to 2.15.0 to fix the Log4Shell vulnerability: https://www.lunasec.io/docs/blog/log4j-zero-day/

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.102.2

# Date of Deployment

Release Candidate (RC) environment: 20 December 2021 Production environment: 20 December 2021

# New or Improved Features

Whois Release 1.102.2 includes the following main change:

  • Update the Log4j library from 2.15.0 to 2.17.0 to fix vulnerabilities

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.102.3

# Date of Deployment

Release Candidate (RC) environment: 31 March 2022 Production environment: 31 March 2022

# New or Improved Features

Whois Release 1.102.3 includes the following main change:

  • Update of the Spring Framework library from 5.3.13 to 5.3.18 to address Spring4Shell vulnerability.

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.103

# Date of Deployment

Release Candidate (RC) environment: 25 April 2022 Production environment: 9 May 2022

# New or Improved Features

Whois Release 1.103 includes the following main changes:

  • Fixed "geofeed:" validation when reading object containing multiple remarks: attributes (#975)
  • Removed WHITEPAGES org type. (#1003)
  • Better Error Message when Changing "mnt-by:" on Allocations (#988)
  • Allow user "mnt-by:" when creating inet6num allocations (already allowed for inetnums) (#982)
  • Disallow weak keys and hash algorithms (#642, #974)
  • Abuse-c is Required for End User Organisations With Resources (#955, #969)
  • Domain overlap validator (#956)
  • Increase HTTP idle timeout from 30s to 60s (#998)
  • Lacnic GRS import was incorrectly treated as UTF-8 (should have been latin-1). (#958)
  • Updated Zonemaster client to match API Changes (#1005)
  • Implemented Elasticsearch (#944, #989, #993, #997)
  • Updated dependencies

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.104

# Date of Deployment

Release Candidate (RC) environment: 26th September 2022 Production environment: 10 October 2022

# New or Improved Features

Whois Release 1.104 includes the following main changes:

  • Allow Grouping (-G) flag in Whois Search API (#1077)
  • cidr0 notation for RDAP response (#1068)
  • Remove whois tags (#1059)
  • Added text/plain to Search and REST APIs (#1054)
  • Add comment not NOOP (#1052)
  • Do not allow comments in managed attributes (#1045)
  • Use documentation prefix 192.0.2.0/24 (#1044)
  • Organisation country: is modifiable for end-user orgs without RIPE NCC resources (#1041)
  • Do not return deleted versions (#1015)
  • Redirect empty requests to syncupdates help (#1011)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.105

# Date of Deployment

Release Candidate (RC) environment: 29th November 2022 Production environment: 13th December 2022

# New or Improved Features

Whois Release 1.105 includes the following main change:

  • NWI-19: Change to AS-SET object naming rules

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.106

# Date of Deployment

Release Candidate (RC) environment: 6th February 2023 Production environment: 20th February 2023

# New or Improved Features

Whois Release 1.106 includes the following main change:

  • NWI-19 Implement AS_SET NONAUTH (#1169)
  • Implement RDAP "networks" and "autnums" elements in RDAP entity response (#1103)
  • RDAP Flat model, don't return as-block (#1125)
  • RDAP Refactor rdap errors (#1124)
  • RDAP Events and notices (#1112)
  • NRTMv4 changes (#1166, #1156, #1099)
  • Improve AS-SET documentation (#1147)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.106.1

# Date of Deployment

Release Candidate (RC) environment: 6th February 2023 Production environment: 5th April 2023

# New or Improved Features

Whois Release 1.106.1 includes the following main change:

  • NWI-12 NRTMv4 changes
  • Updated Zonemaster client to match API Changes (#1206, #1207)
  • Add all warnings to update with override response (#1189)
  • Handle expected servlet exceptions in RDAP exception mapper (#1193)
  • Redirect Inverse Domain queries to the Authoritative Source (#1213)
  • Fix highlight issue with dot in Elasticsearch (#1194)
  • UnmappedType warning for Elasticsearch (#1191)
  • Updated dependencies

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.107

# Date of Deployment

Release Candidate (RC) environment: 5th June 2023 Production environment: 19th June 2023

# New or Improved Features

Whois Release 1.107 includes the following main changes:

  • NWI-14 add mnt-ref to additional object types (#1243)
  • Sign NRTMv4 notifications (#1241)
  • Separate job for NRTMv4 snapshot file (#1219)
  • Truncate long fields while indexing in Elasticsearch (#1236)
  • Elasticsearch filters inconsistency (#1231)
  • Limit resource lookups in RDAP organisation entity requests (#1220)
  • Allow any characters in local part of SSO auth email addresses (#1237)
  • LIR country attribute bug (#1245)
  • Include country: in Organisation Split File (#1251)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.108

# Date of Deployment

Release Candidate (RC) environment: 13th September 2023 Production environment: 27th September 2023

# New or Improved Features

Whois Release 1.108 includes the following main changes:

  • NRTMv4 Use base64 instead of Hex (#1302)
  • NRTMv4 JSON Text Sequences (#1304)
  • RDAP Add multi mnt-by error (#1301)
  • RDAP Add remarks (#1278)
  • Syncupdates Warn when http (#1292)
  • Remove Lucene support (#1285)
  • Elasticsearch do not rebuild from scratch (#1294)
  • Elasticsearch use phrase without prefix due to bug (#1298)
  • Elasticsearch scape colons (#1299)
  • Jakarta / EE9 (#744)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.109

# Date of Deployment

Release Candidate (RC) environment: 20th November 2023 Production environment: 4th December 2023

# New or Improved Features

Whois Release 1.109 includes the following main changes:

  • RDAP redaction (#1317)
  • Removed organisation "e-mail" from RDAP to match Whois and added to redaction list (#1333)
  • Removed geofeed prefix validation (#1326)
  • Added HTTPS Support to Whois Backend (#1329)
  • Support HTTP Basic authentication (#1342)
  • Support HTTPS Client Certificate Authentication (#1343)
  • Initialize NRTMv4 from command-line (JMX) (#1310)
  • Use parallel stream to generate NRTMv4 snapshots more quickly (#1309)
  • Include AS-SET in RIPE-NONAUTH dump (#1352)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.109.1

# Date of Deployment

Release Candidate (RC) environment: 6th December 2023 Production environment: 20th December 2023

# New or Improved Features

Whois Release 1.109.1 includes the following change:

  • [rdap] Organisation RDAP Object is Assumed to be an IP on Country Attribute (#1362)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.110

# Date of Deployment

(Deployed together with 1.111)

# New or Improved Features

Whois Release 1.110 includes the following changes:

  • [rdap] Implemented RDAP Extension for Geofeed Data (draft-ietf-regext-rdap-geofeed-01) (#1366)
  • [rdap] Improve RDAP documentation (#1373, #1388)
  • [rdap] Implement RDAP RIR Search - Basic Search Features (#1379)
  • [rdap] Enable e-mail in RDAP entity responses (in top level vcard) (#1384)
  • [rdap] Add geofeed as a link to conform with v1 draft (#1374)
  • [api] Separate secure connector for Client Certificate authentication (#1390)
  • [api] Use clientip flag as remote address from trusted source (#1391)
  • [api] Redirect HTTP(S) requests to whois.ripe.net to the DB web application query page (#1396)
  • [api] Elasticsearch refreshed after update/create (#1367)
  • [api] Document inet6num assignment-size maximum prefix (#1375)
  • [all] Daily limit is configurable (#1401)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.111

# Date of Deployment

Release Candidate (RC) environment: 14th March 2024 Production environment: 28th March 2024

# New or Improved Features

Whois Release 1.111 includes the following changes:

  • [update] Don't send email to undeliverable addresses (#1404)
  • [update] Add email unsubscribe support (#1404)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.112

# Date of Deployment

Release Candidate (RC) environment: 2nd May 2024 Production environment: 16th May 2024

# New or Improved Features

Whois Release 1.112 includes the following changes:

  • [all] NWI-4: Add ALLOCATED-ASSIGNED PA inetnum status (#1432)
  • [query] Set Charset Flag (#1450)
  • [update] Don't allow "mnt-lower" on assignments (#1452)
  • [api] Fixed Syncupdates HELP Bug (#1453)
  • [rdap] RDAP Link Title is a String not List (#1445)
  • [mail] Remove Message If Bounce Detection Or Unsubscribe Fails (#1418)
  • [mail] Handle Multiple Delivery Status Notification Failure Responses for the Same Email Address (#1417)
  • [mail] Final-Recipient: RFC822 is case insensitive (#1423)
  • [mail] Refactor Mail Sender to allow multiple recipients (#1411)
  • [all] Route ROA checker (#1416)
  • [all] Schedule ROA load each 15 minutes (#1444)
  • [query] Allow inverse query for e-mail from trusted addresses (#1435)
  • [query] Allow inverse query for sponsoring-org from all addresses (#1431)
  • [nrtm] Return 404 on invalid NRTMv4 notification file path (#1422)

The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.112.1

# Date of Deployment

Production environment: 24th June 2024

# New or Improved Features

Whois Release 1.112.1 includes the following changes:

  • [update] Validate max references (#1486)

# RIPE Database Release 1.113

# Date of Deployment

Not deployed to production (superceded by 1.113.1)

# New or Improved Features

Whois Release 1.113 includes the following changes:

  • Inetnum AGGREGATED-BY-LIR status (#1467)

  • Enable Client Auth Certificate for Lookup (#1475)

  • ROA Overlapping INVALID ROA and VALID ROA fix (#1470)

  • Java 21 Support (#1440)

  • The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.113.1

# Date of Deployment

Not deployed to production (superceded by 1.113.2)

# New or Improved Features

Whois Release 1.113.1 includes the following changes:

  • Validate max references (#1486)

  • The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.113.2

# Date of Deployment

Production environment: 1st July 2024

# New or Improved Features

Whois Release 1.113.2 includes the following changes:

  • Handle Multipart/mixed Bounces and Auto-submitted Messages (#1490)

  • The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# RIPE Database Release 1.114

# Date of Deployment

Release Candidate (RC) environment: 5th September 2024 Production environment: 19th September 2024

# New or Improved Features

Whois Release 1.114 includes the following changes:

  • NRTMv4 Key Rotation (#1484)

  • HTTP DoS Filter for Update Requests (#1495)

  • HTTP block IP Filter (#1498)

  • Add Warning When Password Authentication is used in Mailupdates (#1511)

  • The full list of changes can be found in the source repository: https://github.com/RIPE-NCC/whois/blob/master/changes.txt

# Procedure for the Removal of Personal Contact Details

# Introduction

The RIPE NCC is authorised by the RIPE community to act as the registration authority and keep an accurate register of Internet number resources in its service region and to manage the operation of the RIPE Database. Many of the operational responsibilities for data handling are delegated to the individuals who have mntner objects in the database. These individuals, or Maintainers, maintain sets of data related to their IP network operations.

If one of these Maintainers fails to fulfill their Data Protection responsibilities, the RIPE NCC could have a legal obligation to intervene. This may require the RIPE NCC to modify or delete personal Contact Details. The procedure outlined in this document balances maintaining accountability with the privacy rights of individuals.

# Definitions

In this document, the following terms shall be understood to have the meanings assigned to them below:

RIPE NCC – Réseaux IP Européens Network Coordination Centre. A membership association under Dutch law operating its registered office in Amsterdam, the Netherlands.

RIPE Community – RIPE (Réseaux IP Européens) is a collaborative forum open to all parties interested in wide area IP networks in Europe and beyond. The objective of RIPE is to ensure the administrative and technical coordination necessary to enable the operation of a pan-European IP network.

Update – submitting information for entry into or removal from the RIPE Database.

Internet number resource – globally unique address space (IPv4 and IPv6) and Autonomous System Numbers (ASNs) issued by any Internet Number Registry.

Primary objects – Internet number resources and other data object types that are not directly related to any other Primary object type and which are defined by Routing Policy Specification Language (RPSL) or which have been agreed by the RIPE Community as acceptable primary data.

RIPE Database – the publicly available data collection of Internet Number Registry (INR) and Internet Routing Registry (IRR) data published by the RIPE NCC. It contains all the Primary and Secondary objects. There is also some non-public data required for the operation of the RIPE Database and the registries, but this non-public data does not form part of the RIPE Database.

Registrant – a natural person or legal entity to whom an Internet number resource has been registered or who has registered any other Primary object in the RIPE Database by specific or general agreement with the RIPE NCC.

Maintainer – any Registrant or person to whom the authority to Update has been delegated by a Registrant, either directly or indirectly, and who holds an identifier that allows updates to be authenticated and authorised.

End User – a person for whom an Internet number resource has been registered for their use.

Data Subject – a natural person whose personal Contact Details or other personal data are recorded in the RIPE Database.

Contact Details – all details relating to name, postal address, phone, fax, e-mail or any other form of electronic communication that is used by a natural person or a legal entity.

Personal Contact Details – Contact Details pertaining to a natural person.

Internet Registry – Any registry that makes Internet number resources available to other people and records information in a database about the Registrant.

# General

Personal Contact Details are held in several object types (see Appendix G) The person object is the starting point for all data sets in the RIPE Database and this procedure will focus on these objects.

Changes to Personal Contact Details can have significant consequences. To change or remove Personal Contact Details may require:

  • References to be removed from other objects.
  • Some other objects to be deleted.
  • Internet number resources to be returned to the appropriate Internet Registry.
  • Registrant/Maintainer to lose control and/or right of usage of the Internet number resource.

The precise course of action depends on the type of object in which the person object is referenced. The RIPE NCC has a legal obligation to remove Personal Contact Details on request from the Data Subject in some situations.

If the Data Subject is the Registrant of an Internet number resource and wishes to remain the Registrant of that resource, the following options are available:

  • Insert Personal Contact Details for some other person from the Data Subject’s organisation.
  • Insert Contact Details related to the Maintainer of the resource if this is not the Data Subject. This option is only available if the Maintainer agrees or if the Maintainer is also the Registrant.
  • Insert Contact Details related to the organisation responsible for the parent resource (provided that this is not the RIPE NCC). In this case, responsibility for maintaining the data should also pass to this parent resource organisation if they are not already the Maintainer. This option is only available if the parent resource organisation agrees.
  • Deny the request to remove Personal Contact Details if the Data Subject is the Registrant and does not wish to return the Internet number resource, or the Data Subject is the Maintainer and does not wish to release control over the resource and none of the above options are available.

The Data Subject needs to be aware of the consequences of removing Personal Contact Details where the options above are not possible or acceptable. The Data Subject cannot maintain an Internet number resource and be anonymous. Where accountability for registrations of global resources conflicts with an individual’s right to privacy, drastic action may be required. This may involve returning Internet number resources to the Internet Registry that issued them and removing all associated data from the RIPE Database.

# Procedure

The RIPE NCC has tried to clearly identify a series of steps that can be taken at different stages. The aim is to resolve the issue to the satisfaction of all parties and protect everyone’s interests while maintaining the RIPE NCC’s responsibility as a public registry of Internet number resources. The RIPE NCC will always inform the Data Subject within four weeks in writing whether a request for change or removal of Personal Contact Details will be granted. If the request is denied, the RIPE NCC will duly motivate this decision. This procedure refers only to person objects for clarity, but other objects may be involved (see Appendix G).

The steps that will be taken are as follows:

  1. The RIPE NCC is contacted by a Data Subject asking for their Personal Contact Details to be removed from the RIPE Database. The Data Subject must clearly identify the details they are referring to by sending a copy of the Personal Contact Details to the RIPE NCC.
  2. The RIPE NCC forwards the request to the Maintainer of the person object and copies the Data Subject on the
    e-mail. The Maintainer is asked to resolve the issue within ten working days and send confirmation to both the RIPE NCC and the Data Subject.
  3. a. If the RIPE NCC receives confirmation from the Maintainer that action has been taken, the RIPE NCC notifies both the Maintainer and the Data Subject that the case is closed.
    b. If no confirmation is received from the Maintainer, but the person object has been deleted or substantially changed, the RIPE NCC notifies both the Maintainer and the Data Subject that the issue has been resolved and the case is closed.
    c. If no confirmation is received from the Maintainer, and nothing has changed, the RIPE NCC contacts the Data Subject and copies the message to the Maintainer. The Data Subject is asked to confirm that they still want the personal Contact Details removed. If they confirm this, the RIPE NCC moves to Step 4 (below).

The following steps are the actions the RIPE NCC will take when the Maintainer does not respond to or does not comply with the request to change or remove Contact Details:

  1. The RIPE NCC asks the Data Subject for a copy of a legal identification document. This document must match the personal Contact Details to be removed. This should be faxed to the RIPE NCC together with a formal request for the removal of the personal Contact Details.
  2. The RIPE NCC receives the signed request and identification document from the Data Subject.
  3. If it is a simple case where:
    • The person object is unreferenced.
    • Each object referencing the person object references more than one person object.
  4. For a simple case, the RIPE NCC sends an acknowledgement to the Data Subject and the Maintainer informing them that the personal Contact Details have been removed and the case is closed.

For anything other than one of the simple cases, the RIPE NCC continues with the following steps:

  1. The RIPE NCC sends a statement to the Data Subject of actions to be taken, which includes a list of any other data that may be affected which is directly related to the person object and the changes that need to be made to this data. This list will highlight any resources that will need to be returned to an Internet Registry or transferred to another Maintainer and the possible consequences of this action. These consequences may include the removal of some data from the RIPE Database.

  2. Because of the referential integrity rules, when any data is removed from the RIPE Database, there can be a chain reaction. This may result in more data being changed or removed. The Maintainers of any such data will be informed and requested to make the appropriate changes. These changes will have to be made before the Data Subject's details can be removed because no object can be deleted from the RIPE Database while it is still referenced.

  3. If there is an option for data to be transferred to another Maintainer but the latter Maintainer is not willing to be the Maintainer of this data, then there are only two options available:

    • The User must return the resource to the appropriate Internet registry and their personal Contact Details will be removed.
    • The User’s personal Contact Details cannot be removed but can be corrected if there is an error.

    In the former case, if the Data Subject confirms the action, the RIPE NCC moves into the clean-up phase. In the latter case, any corrections will be applied and the case is closed.

  4. a. If the Data Subject confirms the action in the statement, the RIPE NCC moves into the clean-up phase.
    b. If the Data Subject does not confirm this action, no further action is possible and the case is closed.

# Clean-up Phase

This is the procedure taken by the RIPE NCC when the removal of personal Contact Details is not a simple case. The actual implementation is very technical and requires some recursive searching for references.

The goal is to remove the person object containing the Data Subject’s personal Contact Details. All reference chains must be followed and appropriate changes made as close in the chain as possible to the person object to maintain the referential integrity of the RIPE Database.

If an object needs to be deleted, special considerations may apply, depending on the object type (see Appendix F). This may involve returning some resources to the appropriate Internet Registries. If these resources are registered to the Data Subject requesting the removal of personal Contact Details, the resources will be listed in the statement to the Data Subject together with the consequences. If the resources are managed by other Maintainers, the Maintainers will be notified and given an opportunity to change the references and take their resources off the list of affected objects. This must be done before the Data Subject’s personal Contact Details can be removed.

# Conclusion

It is easier for all concerned if the Maintainers make any necessary changes to the personal Contact Details. The Maintainers are closer to the people involved and have a better understanding of how to replace references to the Data Subject. If the RIPE NCC has to make changes it is because the Maintainer of the data has not responded in a timely manner. In this case, the drastic actions detailed in this procedure, including requiring resources to be returned, are necessary.

Because the procedure requires drastic actions in some cases, it is important that the RIPE NCC can contact the right people to inform them of the actions in advance. Currently, the RIPE NCC has no authoritative contact details for the Maintainer of many sets of data objects. The RIPE NCC only has the set of e-mail addresses listed in the objects in the RIPE Database. Few of these have been verified and some may prove to be invalid. The RIPE NCC will consider the Maintainer to have been informed by sending an e-mail to the address listed in the RIPE Database.

# RIPE Database Acceptable Use Policy

# Definitions

In the Acceptable Use Policy (AUP), the following terms shall be understood to have the meanings assigned to them below:

RIPE NCC – Réseaux IP Européens Network Coordination Centre. A membership association under Dutch law operating its registered office in Amsterdam, the Netherlands.

Update – submitting information for entry into or removal from the RIPE Database

Query – requesting information from the RIPE Database Access – Update and Query the RIPE Database

RIPE Database – the publicly available data collection of Internet Number Registry (INR) and Internet Routing Registry (IRR) data published by the RIPE NCC. It contains all the primary and secondary objects. There is also some non-public data required for the operation of the RIPE Database and the registries, but this non-public data does not form part of the RIPE Database.

User – anyone who Accesses the RIPE Database or causes Access to be made. This includes Registrants and Maintainers, as defined in the RIPE Database Terms and Conditions.

Abuse-c – an attribute referencing a role object holding abuse contact information, to be included in inetnum, inet6num and aut-num objects, intended for receiving automatic and manual reports about abusive behaviour originating in resource holder's networks.

SSO Account – the RIPE NCC access (Single Sign-On) account Users can access RIPE NCC services through.

# Introduction

The following principles define the purpose of this policy. Without prejudice to the applicability of the RIPE Database Terms and Conditions, this policy is to ensure that:

  • The usage of the RIPE Database is in line with the purpose of the RIPE Database as defined in the RIPE Database Terms and Conditions.
  • No copy of a significant part of the RIPE Database is made without the consent of the RIPE NCC.
  • We protect the personal data held within the RIPE Database. The RIPE Database service is only used as intended and defined in documents and manuals associated with the service.
  • All Users comply with the limits set on their Access to the RIPE Database services.
  • We do not put the RIPE Database services at risk.
  • Our general policies (e.g., on pricing, fees, privacy, data protection and Access) are not compromised.
  • Users do not act in a way that disrupts the RIPE Database services for other Users.

The RIPE Database Terms and Conditions permit the RIPE NCC to block Access to the RIPE Database services by any User for abuse, or suspend Access for suspected abuse.

Please note that we have a standard clause on anti-avoidance and connected persons that forms part of this policy (see below).

We may reject queries originated by Users who have exceeded their limit or who are subject to sanctions for abuse without regard to their limit.

# Limits

These are the limits currently set by the RIPE NCC for using the RIPE Database services.

Query service

  • Number of queries from an IP address – Unlimited [1]
  • Number of queries passed by a proxy – Unlimited [1]
  • Number of personal data sets returned in queries from an IP address – 1,000 per 24 hours [3][4]
  • Number of personal data sets returned in queries from a proxy IP address – 20,000 per 24 hours [3][4]
  • Number of personal data sets returned in queries from an SSO Account – 1,000 per 24 hours [3][4]

Update service

  • Number of update e-mails sent to auto-dbm@ripe.net – Unlimited [1]
  • Number of updates submitted through the syncupdates interface – Unlimited [1]
  • Number of updates submitted through the webupdates interface – Unlimited [1]
  • Number of objects contained in a single update message – 5,000
  • Size of a single update message – 500Kb
  • Number of queued e-mail update messages from any one e-mail address – 100

General

  • Number of simultaneous connections to the RIPE Database server – 3 [2]

# Anti-avoidance and Connected Persons

One way that the principles of this policy can be compromised is if Users try to give the impression that they are separate, or claim to be separate, when in fact they are acting together to pool their limits, for example. If the RIPE NCC believes Users are acting in a coordinated way to bypass the above limits, we will consider the situation and act on a case-by-case basis. References

# References

[1] Where no limits are set, or a limit is set as Unlimited, we work on the basis of reasonable use. This means that we expect Users not to do anything that could abuse or damage the RIPE Database service or cause service disruption for other Users. If we detect any User causing problems we may, at our sole discretion, slow down or temporarily or permanently block Access to the RIPE Database services for that User.

[2] Queries can be sent to the RIPE Database without the need to wait for the previous query to return.

[3] If the number of personal data sets limit is exceeded, the User will be temporarily blocked from making any queries to the RIPE Database from the IP address, or SSO Account, submitting the queries for personal data. The number of queries accepted from the temporarily blocked IP address or SSO Account will recover exponentially over time. This will allow a slower query rate for some time. However, if a User is temporarily blocked several times, or continues to submit queries excessively even while blocked, they will be permanently blocked from querying the RIPE Database from that IP address or SSO Account, as the case may be. Despite the set limits for queries by the RIPE Database User, the email contacts which are included in the ”abuse-c” attribute are meant to be available with no restrictions to bulk access. Because this attribute can potentially be filled in with email addresses that could be considered to be personal, it is the maintainer's responsibility to inform the individual whose personal details will be referenced in the RIPE Database and obtain their consent for use of their data.

[4] Queries which are made to the RIPE Database by a User logged into their SSO Account will be accounted for separately from the IP address of that User. This means that if a User is logged in to their SSO Account, any query for objects containing personal data will be counted against their SSO Account and not their IP address. If a User is not logged into their SSO Account any queries for objects containing personal data will be counted against their IP address.

# Access to NRTM

# Abstract

This document describes show to access a RIPE Near Real Time Mirror (NRTM) Database data stream from the RIPE NCC.

# Introduction

Near Real Time Mirroring (NRTM) is a mechanism that allows any client to receive a stream of available data from a database on a server operated by the RIPE NCC. The client can receive this stream of data modification from the server in near real time. The server will determine what data is made available to the client. Some data will be excluded from the stream or modified before sending. This is described below. The client pulls available data from the server by submitting requests. These requests can be periodic or continuous. The client can be initialised to a known state and the data stream can then be requested to continue with updates from that point onwards. However, updates are only available from the server as a data stream for two weeks. If the client has requested no updates for this period, then the client will need to be reinitialised.

The NRTM database made available by the RIPE NCC does not include any custom software or proprietary database engine with which to utilise the data.

NOTE that it is not possible for users to mirror any of the RIPE NCC mirrored databases (for instance, other RIR databases). If you need a NRTM data stream from any other source you must contact that source directly.

# NRTM Protocols

Currently there are two versions of the NRTM protocols available, Version 2 and Version 3. There is backwards compatibility between the two versions.

The RIPE Database server generates a serial number every time it processes an update in the database. When generating these serial numbers, the server describes all modifications to the database in terms of two atomic operations: deletion and addition.

Version 2 sends some data from every serial in the data stream. Where the real data is excluded, dummy data must be sent to maintain the sequence of serials.

Version 3 adds the serial number after the operation command for each update in the data stream. This eliminates the need to send dummy objects to keep serials in sync.

Currently, either version can be used. It is possible to switch between the versions. We would recommend using version 3. This allows you to process a more condensed data stream, leading to a cleaner database without the clutter of excessive dummy objects.

# Excluded Data

The RIPE NRTM Database made available by this service does not include the full set of data contained in the RIPE Database. It specifically excludes:

  • Personal data (person and role objects)
  • Organisation details (organisation object)
  • Security data (mntner object)
  • References to personal data (NIC Handles)

For both Version 2 and 3 of the NRTM protocol the mntner and organisation objects are replaced in the data stream by dummy data. These are placeholder objects. They still contain the primary key and other objects make references to these objects.

In Version 2 of the NRTM protocol, the person and role objects are also replaced in the data stream by dummy data. However, the same dummy person object replaces all person and role objects. All references in other objects to person and role objects will refer to this single dummy person object.

In Version 3 of the NRTM protocol, the person and role objects are completely omitted from the data stream. Because the serials are included with each object in the data stream, it is not necessary to maintain placeholders.

If a client is blocked from Whois for excessive querying of personal data, they will also be blocked from NRTM.

# Initial Setup

An initial data set is available from our ftp site. It is available in two formats:

  • Individual data files
  • Single data file

The individual data files contain data for each object type in separate text files. The excluded data (described above) is not available from these files. The set of files can be accessed here: ftp://ftp.ripe.net/ripe/dbase/split

All the data from the "optional" attributes has been removed from the files for the organisation and mntner objects. All of the data from the "mandatory" attributes has been replaced with standard dummy data, except for the primary key value. So, for a mntner object, only the "mntner:" attribute will contain any real data. The files for person and role objects contain only a single dummy person object with the NIC Handle 'DUMY-RIPE'.

The single file is a merged data set of all the individual data files in a single text file. It contains the excluded organisation and mntner objects as dummy objects and a single person and role dummy object. This can be accessed here: ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz

All of these files are produced on a daily basis. Only the most recent file is available from the dtp site. Each database update has a serial number and these serials define the data pulled from an NRTM data stream. The latest update serial included in the data files is held in a separate text file on the FTP site: ftp://ftp.ripe.net/ripe/dbase/RIPE.CURRENTSERIAL

You will need this serial number to know which serial to start pulling from the NRTM data stream. Note that only update serials from the previous 14 days can be pulled from the RIPE NRTM Database server. If you have not pulled any data from the NRTM stream for more than 14 days, you will need to download the above text files again, reinitialise your database and start from the new serial number. You may want to keep track of the serials that you pull from the NRTM data stream. If you have any gaps that are older than 14 days, then you will need to download all the text files again.

# Accessing the Data Stream

To receive data from the NRTM data stream you must first connect to the host server and then pull selected data from it.

The client must connect to the host whois.ripe.net at port 4444.

When sending data to a client using the Version 2 protocol, the server will send one of two strings ("ADD" or "DEL") followed by two line-break characters (\n\n) and then the corresponding object. This will either be the object as it was before deletion or the object as it should appear after being created or modified. If an object already existing in the database follows the "ADD" string, the client software should treat this as a modification.

With the Version 3 protocol the serial follows the operation string ("ADD" or "DEL") on the same line. All other returned data is the same as for Version 2.

After connecting to the server, the client can request data by using the -g query flag. The arguments to this query flag are: -g <source> :<NRTM_Protocol_version_#>:<first>-<last>

where

  • <source> is the string that identifies the server database that is being mirrored (only RIPE is available).
  • <NRTM_protocol_version_#> is the version of the mirroring protocol that the <source> supports (this should be 2 or 3 for the source RIPE).
  • <first> is the lowest serial number requested.
  • <last> is the most recent serial number requested. If the keyword "LAST" is used, this tells the server to send all updates up to the most recent one available at the time of the request.

This is an example of accessing the NRTM data stream using telnet and pulling the serials from 11012700 to the latest available.

$ telnet whois.ripe.net 4444
Trying 193.0.0.135...
Connected to whois.ripe.net.
Escape character is '^]'.
-g RIPE:3:11012700-LAST
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html
%START Version: 3 RIPE 11012700-11012701
DEL 11012701
inetnum: 193.0.0.0 - 193.0.7.255
netname: RIPE-NCC
descr: RIPE Network Coordination Centre
country: NL
admin-c: RIPE124-RIPE
tech-c: RIPE124-RIPE
status: ALLOCATED PA
notify: bit-bucket@ripe.net
mnt-by: NAGIOS-MNT
created: 2003-03-17T12:15:57Z
last-modified: 2017-12-04T14:42:31Z
source: RIPE

A client may request a persistent connection by including the -k query flag with a mirroring request (-g query flag). In this case, the last argument is ignored and the server supplies the new object as soon as they are processed. The client is responsible for closing the connection. A persistent connection for mirroring does not time out, but the connection may break if there is a server error.

A client can use the -q sources flag with the mirror server to retrieve information regarding available mirroring possibilities. Please see this section for more details.

At the beginning of the data stream, the server will send the following string:

%START Version: NRTM_Protocol_version_# source first-last

For example:

%START Version: 3 RIPE:1539595-1539597

After the last piece of data is sent to the client, the server will send to string:

%END *source*

to signal the end of transmission. For example:

%END RIPE

# Near Real Time Mirroring v3

The RIPE NCC NRTM is a publicly available service that allows users to receive a stream of available data from the RIPE Database on a server. The user will receive a stream of data from the server with near real time updates. This service does not include any personal data.

# Pre-conditions:

# Steps

  • Stop whois using kill <PID>

      # NRTM server
  nrtm.enabled=false
  nrtm.update.interval=15
  # NRTM client
  nrtm.import.enabled=true
  nrtm.import.sources=RIPE-GRS
  nrtm.import.RIPE-GRS.source=RIPE
  nrtm.import.RIPE-GRS.host=whois.ripe.net
  nrtm.import.RIPE-GRS.port=4444

  • Update the last serial number in the mirrored database with RIPE.CURRENTSERIAL the using the following commands:

      mysql -udbint -p
  USE WHOIS_MIRROR_RIPE_GRS;
  SELECT max(serial_id) AS max_serial_id FROM serials;
  ## copy the result of the previous query and use it to the following query:
  UPDATE serials SET serial_id = RIPE.CURRENTSERIAL WHERE serial_id = max_serial_id;
  ALTER TABLE serials AUTO_INCREMENT = RIPE.CURRENTSERIAL;

  • Start whois using using the following command and check the output. Use -Ddump.total.size.limit to specify the dump size:

    /usr/bin/java -Dwhois -Djsse.enableSNIExtension=false -Dcom.sun.management.jmxremote -Dhazelcast.jmx=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1099 -Xms1024m -Xmx8g -Dwhois.config=properties -Duser.timezone=UTC -Dhazelcast.config=hazelcast.xml -Dlog4j.configurationFile=file:log4j2.xml -jar whois.jar

you should see a log line like this:

2015-08-21 15:47:14,908 INFO  [NrtmClientFactory] Connected to whois.ripe.net:4444

if the above line is repeated multiple times, something is wrong. please stop the whois server.

  • Test that it worked by executing a query on the mirrored source using telnet:

      telnet localhost 1043
  -s RIPE-GRS 193.0.0.1 - 193.0.7.255

or by checking that the max(serial_id) in the database is bigger than RIPE.CURRENTSERIAL

mysql -udbint -p
select max(serial_id) from WHOIS_MIRROR_RIPE_GRS.serials

# NRTM and Keepalive

There is no support in the NRTM protocol for polling, so a client or server may not detect a socket disconnection for some time. Clients should set the TCP socket option SO_KEEPALIVE to enable the standard TCP keepalive mechanism. Clients should also set the keepalive interval option on every connection, as the system-wide default is very long. This option is platform-specific.

  • Linux

    • set SO_KEEPALIVE socket option.
    • System-wide default is 2 hours. Read the current value in seconds using: cat /proc/sys/net/ipv4/tcp_keepalive_time
    • The defaults can be changed on a per-socket basis
      • TCP_KEEPIDLE (the time to wait on an idle connection, before sending a keepalive probe).
      • TCP_KEEPINTVL (the time in seconds, between keepalive probes).
      • TCP_KEEPCNT (the maximum amount of probes to send, before dropping the connection).
    • Ref: http://www.manpages.info/linux/tcp.7.html
    • Ref: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html

  • OSX

    • set SO_KEEPALIVE socket option.
    • System-wide default is 2 hours. Read the current value in ms using: /usr/sbin/sysctl net.inet.tcp.keepidle
    • The defaults can be changed on a per-socket basis
      • TCP_KEEPALIVE (the time to wait on an idle connection, before sending a keepalive probe).
    • Ref: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man4/tcp.4.html

  • Windows

    • Set the SIO_KEEPALIVE_VALS control code.
    • Ref: https://msdn.microsoft.com/en-us/library/windows/desktop/ee470551(v=vs.85).aspx

# How to access the NRTM stream

You will find all technical requirements to access the stream and more information about NRTM in this document.

The RIPE NCC NRTM Service and its use is regulated by the RIPE Database Terms and Conditions and RIPE Database Acceptable Use Policy.

# Transferring To A Third Party

Transferring and/or making available of the NRTM Service and/or the data downloaded therefrom to a third party is only allowed, provided the following conditions are met:

  • The user obtains prior written permission from the RIPE NCC
  • The user ensures that third party accepts the RIPE Database Terms and Conditions for this purpose.
  • The user identifies the RIPE NCC as the source of the data and will explicitly state that this data is near-real time and may not reflect the latest data contained in the RIPE Database.
  • The user maintains the overall integrity of the data (e.g. will not misrepresent, falsify or exclude any data).

The RIPE NCC reserves the right to revoke this permission at any time if the user fails to meet any of these conditions.

# Contact

If you have any more questions, please contact us (opens new window).

# Near Real Time Mirroring v4

NRTMv4 is a protocol for database mirroring that improves upon existing protocols by publishing records via an HTTPS endpoint, using periodic Snapshots Files and regular Delta Files. It includes integrity checks through signing and enhances scalability by generating files once and distributing them over HTTPS. For more information, refer to draft-ietf-grow-nrtm-v4.html (opens new window).

This protocol has draft RFC status and is subject to change.

# Snapshot Initialization

We initialise the Snapshot during the first export for the Database or if there is a history lost and cannot produce continuous deltas. The server notifies to the user when this happens, to ensure that the client have a complete view or need to reinitialise.

  1. A session ID (random v4 UUID) is generated. This token is unique for RIPE Database.
  2. A new Snapshot is generated for version one, this Snapshot may be empty if the database is empty.
  3. A new Update Notification File is generated with the same session ID created in the first step. The session ID is referencing the Update Notification File with the Snapshot. This first snapshot doesn't have any Delta.
  4. We update the Update Notification File with the new contents.

Each Database (i.e: RIPE and RIPE-NONAUTH) has separate session IDs, snapshots, deltas and Update Notification Files, even if published by the same server instance.

# Publishing updates

# Update Notification File

The Update Notification File is essential for mirror clients to determine changes between their local Database state and the RIPE Database. It provides:

The Update Notification File ensure efficient and accurate synchronisation between the RIPE database and the client's database by providing clear metadata, previse change details, and robust validation mechanisms. Clients must rely on this file to maintain up-to-date copies of the RIPE Database.

  1. nrtm_version: must be 4
  2. timestamp: is adhered to RFC3339 (opens new window) format, providing an accurate timestamp of when the Update Notification File was generated.
  3. type: must be "notification".
  4. next_signing_key: (optional) if present, denotes that public key for future key rotation.
  5. source: identifies the source (i.e: RIPE, RIPE-NONAUTH), ensuring consistency with the RIPE Database data.
  6. session_id: It is a unique v4 UUID assigned to this session and source, crucial for synchronisation and tracking.
  7. version: represents the latest version number, aligning with the highest version of the included snapshot and deltas.
  8. snapshot: contains the details of the Snapshot File, including the version, URL foe retrieval, and SHA-256 hash for integrity verification.
  9. deltas: List all Delta Files with their respective version numbers, URLs, and hashes ensuring sequential continuity and data integrity checks.

More information here.

  • Example:
{
  "nrtm_version": 4,
  "timestamp": "2022-01-01T15:00:00Z",
  "type": "notification",
  "next_signing_key": "bnJ0..bXY0",
  "source": "RIPE",
  "session_id": "ca128382-78d9-41d1-8927-1ecef15275be",
  "version": 4,
  "snapshot": {
    "version": 3,
    "url": "https://nrtm.db.ripe.net/nrtmv4/RIPE/nrtm-snapshot.2.047595d0fae972fbed0c51b4a41c7a349e0c47bb.json.gz",
    "hash": "9a..86"
  },
  "deltas": [
    {
      "version": 2,
      "url": "https://nrtm.db.ripe.net/nrtmv4/RIPE/nrtm-delta.1.784a2a65aba22e001fd25a1b9e8544e058fbc703.json",
      "hash": "62..a2"
    },
    {
      "version": 3,
      "url": "https://nrtm.db.ripe.net/nrtmv4/RIPE/nrtm-delta.2.0f681f07cfab5611f3681bf030ec9f6fa3442fb0.json",
      "hash": "25..9a"
    },
    {
      "version": 4,
      "url": "https://nrtm.db.ripe.net/nrtmv4/RIPE/nrtm-delta.3.d9c194acbb2cb0d4088c9d8a25d5871cdd802c79.json",
      "hash": "b4..13"
    }
  ]
}
  • URL:
Environment Public key URL
PROD https://nrtm.db.ripe.net/nrtmv4/RIPE/update-notification-file.json
RC https://nrtm-rc.db.ripe.net/nrtmv4/RIPE/update-notification-file.json

# Snapshot File

The Snapshot File contains the complete and current contents of the RIPE Database, and clients should use it to initialise or reinitialise their local Database copies.

To avoid issues where a client retrieves an Update Notification File just before it is updated, servers should retain old Snapshot Files for at least 5 minutes after a new Update Notification File is published. This allows clients to complete the retrieval of the snapshot without encountering inconsistencies.

The Snapshot File is formatted as JSON Text Sequences (opens new window). It contains one or more records. The first record is the header, followed by the RPSL records.

  1. A new Snapshot File will be generated every day between 1 am and 2 am.
  2. nrtm_version: must be set to 4.
  3. version: must be an unsigned positive integer and match the version field in the Update Notification File.
  4. type: must be "snapshot".
  5. source: must match the source field in the Update Notification File.
  6. session_id: must match the session_id in the Update Notification File.
  7. It is cached for 1 week. It is an immutable file.

More information here.

  • Example:
{
  "nrtm_version": 4,
  "type": "snapshot",
  "source": "RIPE",
  "session_id": "ca128382-78d9-41d1-8927-1ecef15275be",
  "version": 3
}
{"object": "route: 192.0.2.0/24\norigin: AS65530\nsource: RIPE"}
{"object": "route: 2001:db8::/32\norigin: AS65530\nsource: RIPE"}

# Delta File

Delta files are used for keeping track of the changes done to the Database. The delta file is always compared with the previous delta file, so there will never be a version 1. The first delta will be compared with the initialized snapshot and will have the version number 2.

Delta Files are used to record changes to RPSL objects between snapshots. They ensure that clients can keep their databases synchronized with the source by applying only the changes that occurred since the last synchronization.

  1. If there have been changes, a Delta File is published each minute.
  2. All the changes are included, even if some cancel each other out, like an addition and deletion of the same object.
  3. Each Delta File have a version number one greater than the last Delta File or Snapshot File Version.
  4. All the changes are in order they occurred during the time frame.
  5. Deltas older than 24 hours will be removed, after generating a new one.
  6. Update Notification File will include the new Delta File and the updated database version.
  7. Must match the session_id of the Update Notification File.
  8. Must match the source of the Update Notification File.
  9. nrtm_version: must be set to 4.
  10. type: must be delta.
  11. It is cached for one week. It is an immutable file.

More information here

  • Example:
{
  "nrtm_version": 4,
  "type": "delta",
  "source": "RIPE",
  "session_id": "ca128382-78d9-41d1-8927-1ecef15275be",
  "version": 3
}
{
  "action": "delete",
  "object_class": "person",
  "primary_key": "PRSN1-RIPE"
}
{
  "action": "delete",
  "object_class": "route",
  "primary_key": "192.0.2.0/24AS65530"
}
{
  "action": "add_modify",
  "object": "route: 2001:db8::/32\norigin: AS65530\nsource: RIPE"
}

# Key Configuration

To enable NRTMv4 we generate and configure a private Ed25519 key and provide the corresponding public key, the IRR Database name, and the publication URL of the Update Notification File. The public key is base64 encoded. The key is available in the next_signing_key attribute in the notification file.

We provide the public key file on a separate server.

Environment Public key URL
PROD https://ftp.ripe.net/ripe/dbase/nrtmv4/nrtmv4_public_key.txt
RC https://ftp.ripe.net/ripe/dbase/nrtmv4/nrtmv4_public_key_rc.txt

# Key Rotation

The public key will rotate approximately once a year for security reasons. The process for in-band key rotation involves:

  1. Generating and configuring a new key as the upcoming signing key.
  2. Including this key in the next_signing_key field of the Update Notification File, which propagates to mirror clients within 24 hours.
  3. Optionally refreshing the Notification Update File earlier.
  4. Mirror clients store the new key from the next_signing_key field upon retrieving the Update Notification File.
  5. After a week, the server operator makes the new key active and removes the old key. Future Notification Files will be signed with the new key and will not include a next_signing_key field.
  6. If a client's signature validation fails, it must attempt to verify using the previously encountered next_signing_key and update its configuration if successful.

# Setup RIPE Database Mirror

There are three ways to set up a mirror of the RIPE database.

  1. Using GRS import.

    The GRS Import method is updated once per day.

    • First follow the whois installation instructions, to have a working whois installation.

    • Create a LOCAL database, and a WHOIS_MIRROR_RIPE_GRS database, and create tables in both using the whois_schema.sql script.

    • The LOCAL database will be used for any local changes.

    • The WHOIS_MIRROR_RIPE_GRS database will be used for the mirror data.

    • Configure the properties file as follows (you will need to customise the example whois.properties):

      whois.source=LOCAL
  ...
  grs.sources=RIPE-GRS
  grs.sources.dummify=
  ...
  grs.import.sources=RIPE-GRS
  grs.import.enabled=true
  ...
  grs.import.ripe.resourceDataUrl=ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest
  grs.import.ripe.download=ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz
  grs.import.ripe.source=RIPE-GRS
  ...
  whois.db.master.url=jdbc:mariadb://localhost/LOCAL;driver=org.mariadb.jdbc.Driver
  ...
  whois.db.slave.url=jdbc:mariadb://localhost/LOCAL
  ...
  whois.db.grs.master.baseurl=jdbc:mariadb://localhost/WHOIS_MIRROR
  whois.db.grs.slave.baseurl=jdbc:mariadb://localhost/WHOIS_MIRROR
  ...

    Start whois, using the next command. Use -Ddump.total.size.limit to specify the dump size:

    /usr/bin/java -Dwhois -Djsse.enableSNIExtension=false -Dcom.sun.management.jmxremote -Dhazelcast.jmx=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1099 -Xms1024m -Xmx8g -Dwhois.config=properties -Duser.timezone=UTC -Dhazelcast.config=hazelcast.xml -Dlog4j.configurationFile=file:log4j2.xml -jar whois.jar
    • The GRS import will run automatically every midnight. Or, connect to the process using JMX, and start the GRS import.
      $ java --add-exports jdk.jconsole/sun.tools.jconsole=ALL-UNNAMED -jar jmxterm-<version>-uber.jar -v verbose
  >    open <pid>
  >    bean net.ripe.db.whois:name=GrsImport
  >    run grsImport "RIPE-GRS" "test"
  #calling operation grsImport of mbean net.ripe.db.whois:name=GrsImport
  #operation returns:
  GRS import started

    • Monitor progress by checking the log4j console output, the import will take around 2 hours to complete.

    • You can query for objects in the mirror using for example:

        -s RIPE-GRS 82.185.158.240 - 82.185.158.247
  --resource 82.185.158.240 - 82.185.158.247

  2. Using Bootstrap and NRTMv3.

    With this method the mirror database gets updated in near real time.

    This page describes the process of loading the empty mirror database with a nightly export of the RIPE database.

    • First follow the whois installation instructions here, to have a working whois installation.

    • Create a LOCAL database, and a WHOIS_MIRROR_RIPE_GRS database, and create tables in both using the whois_schema.sql script.

    • Download a snapshot of the RIPE DB here: ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz

    • Save the serial number that corresponds to the above snapshot from here: ftp://ftp.ripe.net/ripe/dbase/RIPE.CURRENTSERIAL

    • Both snapshot and RIPE.CURRENTSERIAL are updated every night.

    • If you want to use automatic updates using NRTM, the dump should be at most 2 weeks old.

    • Configure the properties file as follows (you will need to customise the example whois.properties):

        whois.source=LOCAL
  …
  grs.sources=RIPE-GRS
  grs.sources.dummify=
  …
  # GRS source-specific properties to acquire dumps
  grs.import.enabled=false
  grs.import.sources=
  # NRTM client
  nrtm.import.enabled=false
  nrtm.import.sources=
  ...
  whois.db.master.url=jdbc:log:mariadb://localhost/LOCAL;driver=org.mariadb.jdbc.Driver
  ...
  whois.db.slave.url=jdbc:mariadb://localhost/LOCAL
  …
  whois.db.grs.master.baseurl=jdbc:mariadb://localhost/WHOIS_MIRROR
  whois.db.grs.slave.baseurl=jdbc:mariadb://localhost/WHOIS_MIRROR

    • Start the whois server using the following command. Use -Ddump.total.size.limit to specify the dump size:

        /usr/bin/java -Dwhois -Djsse.enableSNIExtension=false -Dcom.sun.management.jmxremote -Dhazelcast.jmx=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1099 -Xms1024m -Xmx8g -Dwhois.config=properties -Duser.timezone=UTC -Dhazelcast.config=hazelcast.xml -Dlog4j.configurationFile=file:log4j2.xml -jar whois.jar

    • Initiate the loading of the dump file using the Bootstrap command from JMX. The import could take several hours.

        % java --add-exports jdk.jconsole/sun.tools.jconsole=ALL-UNNAMED -jar jmxterm-<version>-uber.jar -v verbose
  > bean net.ripe.db.whois:name=Bootstrap
  > run loadDump initialimport <path to ripe.db.gz>

    • When the import is finished exit the jmx console, and test that it worked by executing a query using telnet:

        % telnet localhost 1043
  > 193.0.0.1 - 193.0.7.255

    The above jmx call will load the LOCAL database with the snapshot of the objects from the FTP dump.

    • Now you need to stop the server and copy the LOCAL database to WHOIS_MIRROR_RIPE_GRS.

        % kill <PID>
  % mysqldump -udbint -p  LOCAL > LOCAL.sql
  % mysql -udbint -p WHOIS_MIRROR_RIPE_GRS < LOCAL.sql

    • The above steps are important because you cannot mirror a remote database directly to the main source (LOCAL), and also you cannot load directly with the JMX call an FTP dump to the mirrored database.

    • The mirrored content has to be persisted to WHOIS_MIRROR_grs.source, in our case WHOIS_MIRROR_RIPE_GRS.

    • Note that the properties:

        whois.db.grs.master.baseurl=jdbc:mariadb://localhost/WHOIS_MIRROR
  whois.db.grs.slave.baseurl=jdbc:mariadb://localhost/WHOIS_MIRROR

    have to be like that, because they are dynamically suffixed by the grs.sources (RIPE-GRS)

    • Start the server and check that the mirrored source is working:
       % /usr/bin/java -Dwhois -Djsse.enableSNIExtension=false -Dcom.sun.management.jmxremote -Dhazelcast.jmx=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1099 -Xms1024m -Xmx8g -Dwhois.config=properties -Duser.timezone=UTC -Dhazelcast.config=hazelcast.xml -Dlog4j.configurationFile=file:log4j2.xml -jar whois.jar
   <wait>
   % telnet localhost 1043
   > -s RIPE-GRS 193.0.0.1 - 193.0.7.255

A server with 16GB RAM, 8 GB swap, and 160GB disk space is recommended for mirroring. Please note that running your own mirror is not supported!

  1. Using IRRd (opens new window) with NRTMv4.

    This feature is in development and is subject to change.

    With this method the mirror database gets updated in near real time.

    This section outline the essential steps for configuring, initializing, and maintaining synchronisation using Snapshot Files and Delta Files. By following these protocols, mirror clients ensure accurate and timely updates of RIPE Database information, while maintaining security and integrity through cryptographic verification processes.

    # NRTMv4 specific settings for the RIPE database
nrtm:
   version: 4  # NRTMv4 version
   url:
      snapshot: https://nrtm.db.ripe.net/nrtmv4/RIPE/nrtm-snapshot  # URL for Snapshot Files
      deltas: https://nrtm.db.ripe.net/nrtmv4/RIPE/nrtm-deltas      # URL for Delta Files
      update_notification: https://nrtm.db.ripe.net/nrtmv4/RIPE/update-notification-file.json  # URL for Update Notification File
   keys:
      public: https://nrtm.db.ripe.net/nrtmv4/RIPE/update-notification-file.json.sig  # Path to the public key for signature verification
    • Initialise IRRd: Initialise IRRd with the necessary IRR database that supports NRTMv4. This involves loading the initial dataset and setting up the necessary configurations.
    # IRR database configuration
databases:
   - name: RIPE # RIPE database settings
import_sources:
   - https://nrtm.db.ripe.net/nrtmv4/RIPE/nrtm-snapshot.1.RIPE.x.y.json.gz  #Import initial data from an HTTPS source
    • Querying Data: Use the IRRd command-line tools or APIs to query data from the NRTMv4 database. For example:
      • Use irrd-clientand irrd-shell to query objects and updates.
      • Fetch and view the Snapshot Files and Delta Files to understand the current state and changes in the database.
    • Update Notifications: Monitor the Update Notification File and Delta Files to stay updated with changes in the database. Configure IRRd to regularly publish these files according to the NRTMv4 specifications.
    • Handling Updates: Process Delta Files to apply incremental updates to your local instance of IRRd, ensuring synchronisation with the latest changes in the database.

    For more detailed explanations about how to use IRRd client please refer to their documentation (opens new window)

# Attribute Names

Attribute names have a precisely defined syntax and only use alphanumeric and characters and hyphens (-). They are not case-sensitive, but the software converts them all to lower case. The attribute name must start at column 0 and must immediately be followed by a colon (:). No spaces or tabs are allowed anywhere within the name, before the name, or in-between the attribute name and the colon. For example, the below notation is correct: mntner: TEST-DBM-MNT This is correct because there is no space between the colon (:) and the attribute name (mntner).

The software is very strict on these points, but they are common user mistakes. There are many aspects to the formatting of attributes and values and the relationship between them. It is not easy to change just one element of this formatting.

# Attribute Properties

Attributes can be used in different ways in different objects. Currently, there are three properties that apply to all attributes:

  • Presence
  • Repeat
  • Indexed

The allowed attributes for any object type are shown in the object templates (see the section 'RPSL Object Types').

# Presence

Not all allowed attributes need to be present in every instance of the object type. The table below shows how presence is defined for an attribute. The same attribute name may have a different presence defined in different object types. For example "status:" is mandatory in an inetnum object, but generated in an aut-num object.

Types of ‘presence' of an Attribute

Type Description
[mandatory] You must include at least one instance of this attribute in all objects of this type.
[optional] This attribute is optional in the objects of this type and you can leave it out. If you choose to include this attribute then the value must also be included.
[required] The syntax rules define this attribute as optional. However, additional business rules require this attribute under some circumstances.
[generated] These attributes are generated if you leave them out. If you include the attribute and provide the value, it may be replaced by a value determined by the software.

# Repeat

Attributes can have single or multiple values. Note that it is the value that matters more than the attribute here. An attribute can only take a comma-separated list of values if it is defined as multiple.

For an attribute defined as single in an object template, there can only be one instance of this attribute in an object of that type and it can only have a single value (even if this attribute is defined as being able to have a list of values).

For an attribute defined as multiple in an object template, there can be many instances of this attribute in an object of that type. If any of these attributes can have a list of values then it is allowed for multiple attributes.

There is no limit on the number of times a multiple attribute can be added to an object. But there is an overall limit on the size of an object.

Type Description
[single] Objects can only contain one instance of this ‘attribute–value' pair.
[multiple] Objects may contain more than one instance of this attribute. For some attributes, an instance may contain a list of values, separated by commas.

# Indexed

Many attribute values are indexed within the database. This is necessary to provide fast, efficient lookups of data. All objects' primary keys are indexed. These and any other indexed value may be used to do standard lookups or reverse lookups.

A standard lookup is where you look for an object that contains the specified value. Where this value can be found in an object depends on the index tables built with that attribute value.

An inverse lookup is where you look for objects that contain the specified value in the list of specified attribute types. (See more about indexed searches in the section on Querying the RIPE Database.)

whois –i mnt-by,mnt-lower,mnt-routes: AARDVARK-MNT

Indexes are built internally within the database. This property does not affect nor put any restrictions on the data entered by a user.

Table 3.5 Types of ‘indexes' of an Attribute

Type Description
[lookup key] This attribute is indexed.
[inverse key] This attribute is in the "reverse" index.
[primary key] This attribute is (part of) the primary key for this object type.

# Attribute Values

The value part of the attribute-value pair starts after the colon (:). It can immediately follow the colon, or spaces or tabs may be used to separate them. The format and content of a value is determined by the syntax definition for that attribute within that object type. The same attribute name may be used in more than one object type. Often, the syntax definition will be the same for an attribute regardless of which object type it is used in. For example, the "admin-c:" attribute appears in most object types with the same definition of its syntax. But sometimes the attribute may be defined in a different way in different object types. For example "status:" is used in inetnum, inet6num and aut-num objects. For each of these object types, "status:" has a different meaning with a different pre-defined set of values.

The value can contain some pre-defined keywords at any place within the value as determined by the syntax definition for that attribute within that object type. It can also contain references to other objects and free text. You can refer to other objects by using their primary key values. These references and the keywords have a precisely defined syntax. If the objects you refer to do not already exist in the database, you will see error messages and your update will fail. The free text has no syntax, but may only contain Latin-1 recognisable characters.

Some attribute values may contain spaces and tab characters to help make the information easier to read, as long as the syntax definition allows it. Note that spaces work better than tabs, as tabs can display differently on different machines.

If an attribute is included in an object, it must have a value unless the value is defined as free text. Even generated attributes, if included in the object, must have a syntactically valid value. The software may change this value, however, if the value is missing there will be a syntax error.

# Split Values

In most cases, a value can be split over multiple lines. Each continuation line must start with a space, tab or plus (+) in column zero. Continuation lines do not include the attribute name.

An object cannot have a blank line inside it because this would mark the end of the object. A blank continuation line must start with the ‘+' sign in column zero.

An example of a correct continuation line:

address:  Singel 258
+
      Amsterdam

Note the ‘+' in column zero on the second, blank line.

Values cannot be split in the first attribute, which defines the object type, or in the primary key attribute(s). If this is done, the software will re-combine these attributes into a single-line value. The update will not fail.

When parsing an object, the software will internally recombine continuation line values into a single value for processing. The values from multiple lines are joined with a single space in-between them. Therefore, it is also not possible to split a value in the middle of a word or within any text string. The object is stored in the database with any valid split values.

# End-of-line Comments

In most cases, an end of line comment can be added at the end of a value. These start with a hash (#) and continue until the end of the physical line (a newline character ‘\n'). If a value is split over several lines, any or all of the lines may include an end of line comment. You cannot continue the comment on another line- these comments always stop at the end of the line in which they start. An end of line comment cannot start at column 0. It is possible to add end of line comments on several consecutive lines, which together form a block of text. However, for long comments, it is better to use the "remarks:" attribute.

admin-c: dw-ripe  # these NIC Handles
tech-c:  dw-ripe  # form a set of contacts
zone-c:  dw-ripe  # for this object

Any free form value cannot contain a hash (#) character, as this would be recognised as the start of a comment. Although the software does not process comments, in some situations it does strip off the comments before using the values.

If split values and end of line comments are used together, the software strips off the end of line comments before the split values are combined.

End of line comments cannot be added to the first attribute value, which defines the object type, or to the primary key attribute(s) value. If this is done the software will strip them off. The update will not fail. These comments are also not allowed on the "source:" attribute value. If one is added here, the update will fail.

Long, end of line comments or long, free form attribute values can cause problems. Some email clients automatically break lines at certain points. If your email client does this on an update message then your update will fail. It may not be obvious at first sight that this has happened. Fortunately, there are many other options for submitting updates if this problem occurs.

# List Values

Some attributes allow the value to be a list. This must be a comma-separated list with no spaces allowed. These attributes can be viewed in the Appendix.

# Attributes in an Object

The first attribute must have the same name as the object type. This identifies the object type. The currently available object types are shown in the sub-sections, 'List of Primary Objects' and 'List of Secondary Objects'. If the type is not recognised, that part of an update message will be seen as a paragraph of text and will be disregarded with an appropriate error message. If the unrecognised type is in a query, it will be rejected with an error.

Other attributes can appear in any order, but most people stick to the order as shown in the object templates (see the section 'RPSL Object Types'). Each object type is defined to have a set of possible attributes. The set for each object type is defined within the software and shown in the template.

Each instance of an object type is uniquely defined by a primary key. For most object types, the primary key is normally the value of the first attribute. In some cases, it is a different attribute value or a composite of more than one attribute value. The primary key only has to be unique within an object type. Objects of different types can sometimes have the same primary key, as long as the key fits the syntax for both object types. For example ‘FRED' is a valid name for a mntner object. ‘FRED' is also a valid "nic-hdl:" value, which is the primary key for a person or role object.

Each attribute name must start on a separate line. However, not every line needs an attribute as values can continue over several lines. A blank line marks the end of an object . Technically this is two consecutive newline characters, \n\n. For this reason, you cannot include a completely blank line in the middle of an object.

# Database Objects

The RIPE Database contains records of:

  • Allocations and assignments of IP address space (the IP address registry or INR);
  • Reverse domain registrations;
  • Routing policy information (the Internet Routing Registry or IRR);
  • Contact information (details of people who are registered as contacts for the Internet resources used in the operation of networks or routers, and their organisations).

The records in the RIPE Database are known as ‘objects'. Routing Policy Specification Language (RPSL) defines the basic syntax of database objects. For further information see RFC 2622 (opens new window). But, over the years, practical operations have resulted in a number of deviations from the basic RPSL definition. Many extensions have also been made to the RIPE implementation of RPSL for the RIPE Database. Some features of RPSL were never implemented and others have been removed as requirements changed. For engineering-minded people, these database objects (records) should not be confused with the objects used in object-orientated programming languages that are used to write the software.

There are many types of objects in the database. These are described in the section: 'RPSL Object Types'. Objects contain a piece of information relating to an Internet resource or a supporting or administrative function. Objects can reference other objects and these references must be followed to obtain the full description of an Internet resource. Inheritance is not used, which means that some references must be duplicated across large numbers of objects.

# How to Organize Your Data

There are many different types of objects in the RIPE Database. Some of them can be used in different ways. How you use them makes a big difference to the workload needed to maintain the data.

The RIPE Database is intended for those who have, or will soon have Internet resources. This database is a public registry with a well-defined purpose. See 'Purpose of the RIPE Database' for more details. You can create many objects in the RIPE Database without any resources. But if these objects are not referenced by any resource object within a specified time period they will all be deleted. See the section on Garbage Collection for more details.

Resource holders using the RIPE Database need a basic set of objects:

  • organisation
  • role
  • person
  • mntner

For new members, this set of objects will be set up by the RIPE NCC as part of the new LIR process (opens new window). How you use these objects will affect how much maintenance you need to perform later.

# Using the Organisation Object

The organisation object was introduced in 2004, long after the RIPE Database data model was designed. The organisation object can make life easier in some situations.

Consider all users as organisations, whether they are multinational companies, universities or individuals. To use the RIPE Database, each of these organisations needs a set of data objects that represent their business model. The organisation must have:

  1. People who can be contacted
  2. These people have defined roles in the business
  3. These roles include responsibility for Internet resources
  4. These resources need authorisation tokens to protect them
  5. These tokens may need public keys.

This set of objects represents your organisation. When the organisation is an individual who has been assigned some PI space, they may need several objects in the database. Multinational companies may have many hundreds of thousands of objects.

The organisation object was introduced as a way of keeping track of these sets of objects. The idea is to put the organisational identity of the entity at the centre by defining its organisation object. The organisation's business model can then be mapped out by creating the objects from the list above as appropriate. Each of these objects can be directly linked to the organisation object using the "org:" attribute. Or for a simplified model, link the mntner objects using the "org:" attribute in each mntner object. All objects must be maintained, so there is an indirect reference back to the organisation object through the mntner objects.

Some multinational companies may have a distributed business model with different parts of the organisation responsible for different parts of their network. In this situation additional organisation objects can be created. These objects can reference the main organisation object through their own "org:" attribute. This allows users to keep track of the entire company's data or the parts delegated to different sections of the company.

By using these "org:" references, bulk changes to data are very much simplified. Tools can be written and deployed more easily. New ideas can be rolled out quickly across an entire data set. The more structured you make your data, the more easily it is to automate processes.

When the organisation object was first introduced there was some resistance to make references to it for fear of the public or competitors being able to map out their business. But now that there are so many ways to (inverse) query the data, it is not difficult to find all resources or customers of any organisation. If you don't set up your data in a structured way, the management of the data becomes more complicated.

Basically the organisation object should be the centre of your presence in the RIPE Database. All your human resources and Internet resources and authentication tokens should hang off this central point.

# Using the Role Object

The person and role objects are often said to be interchangeable:

  • They share the same name space in the RIPE Database, but names can be duplicated.
  • The NIC Handles are only unique across the two object types combined, so both object types can't exist with the same NIC Handle.
  • Either a role or person object can be used everywhere that requires a reference to a contact, with only a couple of exceptions where it must be one type or the other.

However, these two objects have very different functions. A person object holds personal details about an individual. A role object should describe a business function or operational unit and may reference the individual people responsible for this activity. References to person objects are optional in the role object.

Using role objects makes large-scale changes easier. The principle is the same if you have ten objects or 10,000 objects in the database. However, problems most commonly occur when dealing with a very large number of objects.

Many organisations create a large number of objects that directly reference a person object, and experience difficulties if this person leaves the company. The organisation may be responsible for many objects of different types, possibly with several different mntner objects protecting them, and finding them and getting all the authorisations right to change the references can easily become a problem.

Working within certain guidelines can help avoid this situation:

Only use a person object as a holder of personal information Only reference a person object in role objects Reference the role objects in all the other places where contact data is required If the person responsible for a business role or function changes, then it is only necessary to modify a few role objects to reference a different person object. All references to the role objects remain valid. The scale of the changes you need to make is very much reduced.

Even if you have only a handful of objects in the database, it is good practice to do this. Your business may grow, and time restraints mean that you may not go back and change things until you absolutely have to do so. This is how these objects were designed for use, but as this practice was never enforced by software business rules, much of the database still makes direct references to person objects.

# Abuse Details

The irt object (Internet Response Team) was introduced to identify a Computer Security Incident Response Team (CSIRT) for handling serious network problems like DOS attacks. It was later modified to make it usable for more general abuse. But all the old ways of documenting abuse were also still available. Now with the introduction of "abuse-c:" this general abuse is moving away from the irt object again. After a data cleanup, the irt object will only be used for CSIRT teams again and should not be used to handle general abuse complaints.

General abuse is now handled by the organisation object. This should reference an abuse handling role object with an "abuse-c:" attribute. This role object must include an "abuse-mailbox:" attribute. All RIPE NCC allocated address space and direct end user assignments, represented by inet(6)num and aut-num objects, should reference an organisation object directly. All more specific address space objects inherit this reference. The abuse handler for this address space and all the more specific address space to that specified by the inet(6)num object is determined by the referenced organisation object.

There is a query flag (-c) which will return the irt object, if one exists, for any specified inet(6)num object. There is also another query flag (-b) that will find the indirectly referenced role object, extract the "abuse-mailbox:" attribute and return brief details including the email address from the role object.

# Who Maintains the Data?

This is one of those areas that some users don't pay much attention to, but it is one of the most important questions regarding the use of the RIPE Database. Anyone authorised to maintain your data can cause serious damage to your network, your business and the business of your customers if they make a mistake. Authorisation is an all or nothing concept. You cannot authorise someone to create and modify customer's details but not delete it, for example.

For details of the technical workings of authorisation see the section, 'Authorisation'. This section is about how to set up who can authorise what.

The authorisation model is based on the mntner object. This is a box that holds credentials. There are different types of credentials with passwords, PGP certificates and single sign-on (SSO) usernames being the main ones. At the time of writing, these credentials don't need to match anyone who is registered in the RIPE Database with a person object. They are simply lists of credentials that can belong to anyone. It is therefore not possible for the database software to identify ‘who' authorised an update. The introduction of SSO as a credential is a step in this direction.

Every object in the RIPE Database must now be protected by a mntner object referenced by a "mnt-by:" attribute. The mntner object is also protected by a "mnt-by:" attribute. Normally, this references itself.

For a small organisation with only a few objects in the database you may decide that you only need one mntner object. This is created with one or more credentials and maintains itself. Every object you create in the RIPE Database is maintained by this mntner object. The people whose credentials are in the mntner object all have equal and full control over all of your database objects. They can create, modify and delete anything. Because of the anonymous way credentials are used in the mntner object, the software cannot identify which credential made the update, only that a specific mntner object was used.

For larger organisations with potentially hundreds of thousands of objects in the database you may want to distribute authority to maintain data. How you distribute it depends on your business model. One example could be for a multi-national organisation with customers in different countries to partition your address space allocations by country. You could have a separate team managing the network in each country, each with their own mntner object. The "mnt-lower:" attribute on the partitioned allocations restricts control to those teams.

Another possibility is to have separate teams handling address space, reverse delegations and routing. This can be set up using the appropriate "mnt-xxx:" attributes. For example "mnt-routes:".

You may also want to control who can grant authority to manage your data. Normally a mntner object maintains itself. This means anyone who has a credential in that mntner object can also change the mntner object. So they can add another password so that another person can make changes. In a large organisation, you may want a security team to control the mntner objects. In this case you can create a mntner object for the security team. All other mntner objects are maintained by this security team mntner. Only the security team can then allow someone else authority to maintain some data by adding their credential to the appropriate mntner object.

# How do I keep an audit trail of changes to my data?

You can use notifications to keep track of changes to your data. This section details how to set up who gets notified of what.

The 'Notifications' section details the technical workings of notifications and how to set up who gets notified of what.

There are many ways to set up notifications. If you want to know everything, you should use the mntner objects. All of your data is maintained by one or more mntner objects. These objects have a mandatory attribute "upd-to:". This lets you know if someone is trying to hack into your data. Any update to objects maintained by this mntner object that fails on authorisation gets notified to this email address. There is also an optional attribute "mnt-nfy" in the mntner object. This notifies you of every successful update to any object maintained by this mntner object.

Most people direct notifications to individuals in the organisation, which is adequate if those individuals want to know about changes to objects they have some responsibility for, or interest in. However, these emails are often missed, ignored or simply deleted. If there is an issue that results from a change made some time ago, the information you received about the change may have been lost.

One way to keep an audit trail of changes is to set up a specific email address that you can reference in all of your mntner objects, in both email attribute types. You can set up a script that monitors that email address and archives all emails to a log file or database. You then have an audit trail of changes made to your objects. One thing that is missing is the acknowledgement message. For email updates, this is only returned to the address that submits the update. For web form updates or RESTful API updates, there is no acknowledgement message sent anywhere. The response is returned to the web session. However, for all updates, the software still generates the human-readable acknowledgement message that is returned in response to an email update. This is logged internally in the RIPE NCC's update logs, but only sent to the user if the update was submitted by email. Without a copy of this acknowledgement message, it is not possible to have a complete audit trail of who did what and when they did it.

# List of Primary Objects

These are the currently supported objects in the RIPE Database that are considered to be primary data.

Object Type Short name Description
aut-num an Holds information about an Autonomous System (AS) Number. If it has "status: ASSIGNED" it is an authoritative resource assigned by the RIPE NCC and is part of the number registry (INR). It can also describe the external routing policy of the AS and is then part of the routing registry (IRR).
domain dn Reverse domain registrations. Any changes made to domain objects in the RIPE Database are reflected in the DNS zone files.
inet6num i6 Allocations and assignments of IPv6 address space.
inetnum in Allocations and assignments of IPv4 address space.
route rt IPv4 route advertised on the Internet.
route6 r6 IPv6 route advertised on the Internet.
as-set as Set of aut-num objects.
filter-set fs Set of routes matched by its filter.
inet-rtr ir Internet router.
peering-set ps Set of peerings.
route-set rs Set of routes.
rtr-set is Set of routers.

# List of Secondary Objects

These are the currently supported objects in the RIPE Database that are considered to be secondary data.

Object Type Short name Description
as-block ak Delegation of a range of Autonomous System (AS) Numbers to a given Regional Internet Registry or marked as reserved.
irt it Contact and authentication information about a Computer Security Incident Response Team (CSIRT).
key-cert kc Public key certificate that is stored on the server, to be used with a mntner object for authentication when performing updates.
mntner mt Authentication information needed to authorise creation, deletion or modification of the objects protected by the mntner.
organisation oa Details of an organisation that hold some resources.
person pn Technical, administrative and DNS zone contacts. Also sometimes used to show an End User of a resource who has no involvement in the management of the resource. Contains personal information.
poem po Humorous poem to keep network engineers happy.
poetic-form pf Type of humour for a poem object.
role ro Technical, administrative, DNS zone and abuse contacts - describes a role performed by one or more people. Should contain business information only.

# Primary and Secondary Objects

Objects in the RIPE Database naturally fall into two categories, primary and secondary.

Primary objects contain operational data. For example inetnum and aut-num objects hold Internet resource information. Also, route and domain objects hold details of routing agreements and reverse delegations.

Secondary objects provide supporting and administrative details for primary objects. For example, person objects hold contact information for someone related to an Internet resource. Or organisation objects hold details of resource holders.

# REST API Data model

# WhoisResources

# Description

The RIPE Database REST API uses a uniform format for transferring structured data. The root object type is called whoisResources.

# XML

Example structure

<?xml version="1.0" encoding="UTF-8"?>
<whois-resources>
    <link xlink:type="..." xlink:href="..."/>
    <parameters>...</parameters>
    <objects>
        <object>...</object>
        <object>...</object>
        <!--...more "object" elements...-->
    </objects>
    <sources>
        <source name="..." id="...">...</source>
        <source name="..." id="...">...</source>
        <!--...more "source" elements...-->
    </sources>
    <errormessages>
        <errormessage severity="..." text="…">...</errormessage>
        <!--...more "errormessage" elements...-->
    </errormessages>
    <grs-sources>
        <source name="..." id="..." grs-id="..."/>
        <source name="..." id="..." grs-id="..."> <!--...--> </source>
        <!--...more "source" elements...-->
    </grs-sources>
    <geolocation-attributes>...</geolocation-attributes>
    <versions>...</versions>
    <errormessages>...</errormessages>
    <terms-and-conditions xlink:type="locator" xlink:href="http://www.ripe.net/db/support/db-terms-conditions.pdf"/>
</whois-resources>

Example request

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<whois-resources>
    <objects>
        <object type="person">
            <source id="RIPE"/>
            <attributes>
                <attribute name="person" value="Pauleth Palthen"/>
                <attribute name="address" value="Singel 258"/>
                <attribute name="phone" value="+31-1234567890"/>
                <attribute name="e-mail" value="noreply@ripe.net"/>
                <attribute name="mnt-by" value="OWNER-MNT"/>
                <attribute name="nic-hdl" value="AUTO-1"/>
                <attribute name="source" value="RIPE"/>
            </attributes>
        </object>
    </objects>
</whois-resources>

Example response

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<whois-resources xmlns:xlink="http://www.w3.org/1999/xlink">
    <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe"/>
    <objects>
        <object type="person">
            <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/person/PP1-RIPE"/>
            <source id="ripe"/>
            <primary-key>
                <attribute name="nic-hdl" value="PP1-RIPE"/>
            </primary-key>
            <attributes>
                <attribute name="person" value="Pauleth Palthen"/>
                <attribute name="address" value="Singel 258"/>
                <attribute name="phone" value="+31-1234567890"/>
                <attribute name="e-mail" value="noreply@ripe.net"/>
                <attribute name="mnt-by" value="OWNER-MNT" referenced-type="mntner">
                    <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/mntner/OWNER-MNT"/>
                </attribute>
                <attribute name="nic-hdl" value="PP1-RIPE"/>
                <attribute name="remarks" value="remark"/>
                <attribute name="source" value="RIPE"/>
            </attributes>
        </object>
    </objects>
    <terms-and-conditions xlink:type="locator" xlink:href="http://www.ripe.net/db/support/db-terms-conditions.pdf"/>
</whois-resources>

Example request body with error in source and in admin-c attribute:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<whois-resources>
<objects>
    <object type="person">
        <source id="INVALID_SOURCE"/>
        <attributes>
            <attribute name="person" value="Pauleth Palthen"/>
            <attribute name="address" value="Singel 258"/>
            <attribute name="phone" value="+31-1234567890"/>
            <attribute name="e-mail" value="noreply@ripe.net"/>
            <attribute name="admin-c" value="INVALID"/>
            <attribute name="mnt-by" value="OWNER-MNT"/>
            <attribute name="nic-hdl" value="PP1-RIPE"/>
            <attribute name="source" value="INVALID_SOURCE"/>
        </attributes>
    </object>
</objects>
</whois-resources>

Example XML response with error in source and in admin-c attribute:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<whois-resources xmlns:xlink="http://www.w3.org/1999/xlink">
<link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/person"/>
<objects>
    <object type="person">
        <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/invalid_source/person/PP1-RIPE"/>
        <source id="invalid_source"/>
        <primary-key>
            <attribute name="nic-hdl" value="PP1-RIPE"/>
        </primary-key>
        <attributes>
            <attribute name="person" value="Pauleth Palthen"/>
            <attribute name="address" value="Singel 258"/>
            <attribute name="phone" value="+31-1234567890"/>
            <attribute name="e-mail" value="noreply@ripe.net"/>
            <attribute name="admin-c" value="INVALID"/>
            <attribute name="mnt-by" value="OWNER-MNT" referenced-type="mntner">
                <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/invalid_source/mntner/OWNER-MNT"/>
            </attribute>
            <attribute name="nic-hdl" value="PP1-RIPE"/>
            <attribute name="source" value="INVALID_SOURCE"/>
        </attributes>
    </object>
</objects>
<errormessages>
    <errormessage severity="Error" text="Unrecognized source: %s">
        <args value="INVALID_SOURCE"/>
    </errormessage>
    <errormessage severity="Error" text="&quot;%s&quot; is not valid for this object type">
        <attribute name="admin-c" value="INVALID"/>
        <args value="admin-c"/>
    </errormessage>
</errormessages>
<terms-and-conditions xlink:type="locator" xlink:href="http://www.ripe.net/db/support/db-terms-conditions.pdf"/>
</whois-resources>

Example XML Response for bad request when trying to delete an object that is referenced by other objects:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<whois-resources xmlns:xlink="http://www.w3.org/1999/xlink">
    <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/person/PP1-RIPE"/>
    <objects>
        <object type="person">
            <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/person/PP1-RIPE"/>
            <source id="ripe"/>
            <primary-key>
                <attribute name="nic-hdl" value="PP1-RIPE"/>
            </primary-key>
            <attributes>
                <attribute name="person" value="Test Person"/>
                <attribute name="address" value="Singel 258"/>
                <attribute name="phone" value="+31 6 12345678"/>
                <attribute name="nic-hdl" value="PP1-RIPE"/>
                <attribute name="mnt-by" value="OWNER-MNT" referenced-type="mntner">
                    <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/mntner/OWNER-MNT"/>
                </attribute>
                <attribute name="source" value="RIPE"/>
            </attributes>
        </object>
    </objects>
    <errormessages>
        <errormessage severity="Error" text="Object [%s] %s is referenced from other objects">
            <args value="person"/>
            <args value="PP1-RIPE"/>
        </errormessage>
    </errormessages>
    <terms-and-conditions xlink:type="locator" xlink:href="http://www.ripe.net/db/support/db-terms-conditions.pdf"/>
</whois-resources>

Example XML Response for incorrect password

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<whois-resources xmlns:xlink="http://www.w3.org/1999/xlink">
    <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/person/PP1-RIPE"/>
    <objects>
        <object type="person">
            <link xlink:type="locator" xlink:href="rest.db.ripe.net/ripe/person/PP1-RIPE"/>
            <source id="ripe"/>
            <primary-key>
                <attribute name="nic-hdl" value="PP1-RIPE"/>
            </primary-key>
            <attributes>
                <attribute name="person" value="Pauleth Palthen"/>
                <attribute name="address" value="Singel 258"/>
                <attribute name="phone" value="+31-1234567890"/>
                <attribute name="e-mail" value="noreply@ripe.net"/>
                <attribute name="mnt-by" value="OWNER-MNT" referenced-type="mntner">
                    <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/mntner/OWNER-MNT"/>
                </attribute>
                <attribute name="nic-hdl" value="PP1-RIPE"/>
                <attribute name="remarks" value="remark"/>
                <attribute name="source" value="RIPE"/>
            </attributes>
        </object>
    </objects>
    <errormessages>
        <errormessage severity="Error"
                    text="Authorisation for [%s] %s failed&#xA;using &quot;%s:&quot;&#xA;not authenticated by: %s">
            <args value="person"/>
            <args value="PP1-RIPE"/>
            <args value="mnt-by"/>
            <args value="OWNER-MNT"/>
        </errormessage>
    </errormessages>
    <terms-and-conditions xlink:type="locator" xlink:href="http://www.ripe.net/db/support/db-terms-conditions.pdf"/>
</whois-resources>

Example XML with Object type error:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<whois-resources xmlns:xlink="http://www.w3.org/1999/xlink">
    <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/mntner/PP1-RIPE"/>
    <errormessages>
        <errormessage severity="Error"
                    text="Object type and key specified in URI (%s: %s) do not match the WhoisResources contents">
            <args value="mntner"/>
            <args value="PP1-RIPE"/>
        </errormessage>
    </errormessages>
    <terms-and-conditions xlink:type="locator" xlink:href="http://www.ripe.net/db/support/db-terms-conditions.pdf"/>
</whois-resources>

# JSON structure

Example structure

{
    "link": {
        "type": "...",
        "href": "..."
    },
    "parameters": { },
    "objects": {
        "object": [
            { },
            { }
        ]
    },
    "sources": {
        "source": [
            { },
            { }
        ]
    },
    "errormessages" : {
        "errormessage" : [ 
            { },
            { } 
        ]
    },
    "grs-sources": {
        "source": [
            { },
            { }
        ]
    },
    "geolocation-attributes": { },
    "versions": { },
    "errormessages": {},
    "terms-and-conditions": {
        "xlink:type": "locator",
        "xlink:href": "http://www.ripe.net/db/support/db-terms-conditions.pdf"
    },
}

Example request

{
"objects": {
    "object": [
    {
        "source": {
        "id": "RIPE"
        },
        "attributes": {
        "attribute": [
            {
            "name": "person",
            "value": "Pauleth Palthen"
            },
            {
            "name": "address",
            "value": "Singel 258"
            },
            {
            "name": "phone",
            "value": "+31-1234567890"
            },
            {
            "name": "mnt-by",
            "value": "OWNER-MNT"
            },
            {
            "name": "nic-hdl",
            "value": "AUTO-1"
            },
            {
            "name": "remarks",
            "value": "remark"
            },
            {
            "name": "source",
            "value": "RIPE"
            }
        ]
        }
    }
    ]
}
}

Example response

{
    "link": {
        "xlink:type": "locator",
        "xlink:href": "http://rest.db.ripe.net/ripe"
    },
    "objects": {
        "object": [
            {
                "type": "person",
                "link": {
                    "xlink:type": "locator",
                    "xlink:href": "http://rest.db.ripe.net/ripe/person/PP1-RIPE"
                },
                "source": {
                    "id": "ripe"
                },
                "primary-key": {
                    "attribute": [
                        {
                            "name": "nic-hdl",
                            "value": "PP1-RIPE"
                        }
                    ]
                },
                "attributes": {
                    "attribute": [
                        {
                            "name": "person",
                            "value": "Pauleth Palthen"
                        },
                        {
                            "name": "address",
                            "value": "Singel 258"
                        },
                        {
                            "name": "phone",
                            "value": "+31-1234567890"
                        },
                        {
                            "name": "e-mail",
                            "value": "noreply@ripe.net"
                        },
                        {
                            "link": {
                                "xlink:type": "locator",
                                "xlink:href": "http://rest.db.ripe.net/ripe/mntner/OWNER-MNT"
                            },
                            "name": "mnt-by",
                            "value": "OWNER-MNT",
                            "referenced-type": "mntner"
                        },
                        {
                            "name": "nic-hdl",
                            "value": "PP1-RIPE"
                        },
                        {
                            "name": "remarks",
                            "value": "remark"
                        },
                        {
                            "name": "source",
                            "value": "RIPE"
                        }
                    ]
                }
            }
        ]
    }, 
    "terms-and-conditions": {
        "xlink:type": "locator",
        "xlink:href": "http://www.ripe.net/db/support/db-terms-conditions.pdf"
    }  
}

Example JSON response with error in source and in admin-c attribute:

{
"link" : {
    "type" : "locator",
    "href" : "http://rest.db.ripe.net/ripe/person"
},
"objects" : {
    "object" : [ {
    "type" : "person",
    "link" : {
        "type" : "locator",
        "href" : "http://rest.db.ripe.net/invalid_source/person/PP1-RIPE"
    },
    "source" : {
        "id" : "invalid_source"
    },
    "primary-key" : {
        "attribute" : [ {
        "name" : "nic-hdl",
        "value" : "PP1-RIPE"
        } ]
    },
    "attributes" : {
        "attribute" : [ {
        "name" : "person",
        "value" : "Pauleth Palthen"
        }, {
        "name" : "address",
        "value" : "Singel 258"
        }, {
        "name" : "phone",
        "value" : "+31-1234567890"
        }, {
        "name" : "e-mail",
        "value" : "noreply@ripe.net"
        }, {
        "name" : "admin-c",
        "value" : "INVALID"
        }, {
        "link" : {
            "type" : "locator",
            "href" : "http://rest.db.ripe.net/invalid_source/mntner/OWNER-MNT"
        },
        "name" : "mnt-by",
        "value" : "OWNER-MNT",
        "referenced-type" : "mntner"
        }, {
        "name" : "nic-hdl",
        "value" : "PP1-RIPE"
        }, {
        "name" : "source",
        "value" : "INVALID_SOURCE"
        } ]
    }
    } ]
    },
"errormessages" : {
    "errormessage" : [ {
    "severity" : "Error",
    "text" : "Unrecognized source: %s",
    "args" : [ {
        "value" : "INVALID_SOURCE"
    } ]
    }, {
    "severity" : "Error",
    "attribute" : {
        "name" : "admin-c",
        "value" : "INVALID"
    },
    "text" : "\"%s\" is not valid for this object type",
    "args" : [ {
        "value" : "admin-c"
    } ]
    } ]
},
"terms-and-conditions" : {
    "type" : "locator",
    "href" : "http://www.ripe.net/db/support/db-terms-conditions.pdf"
}
}

Example JSON Response for bad request when trying to delete an object that is referenced by other objects:

{
"link" : {
    "type" : "locator",
    "href" : "http://rest.db.ripe.net/ripe/person/PP1-RIPE"
},
"objects" : {
    "object" : [ {
    "type" : "person",
    "link" : {
        "type" : "locator",
        "href" : "http://rest.db.ripe.net/ripe/person/PP1-RIPE"
    },
    "source" : {
        "id" : "ripe"
    },
    "primary-key" : {
        "attribute" : [ {
        "name" : "nic-hdl",
        "value" : "PP1-RIPE"
        } ]
    },
    "attributes" : {
        "attribute" : [ {
        "name" : "person",
        "value" : "Test Person"
        }, {
        "name" : "address",
        "value" : "Singel 258"
        }, {
        "name" : "phone",
        "value" : "+31 6 12345678"
        }, {
        "name" : "nic-hdl",
        "value" : "PP1-RIPE"
        }, {
        "link" : {
            "type" : "locator",
            "href" : "http://rest.db.ripe.net/ripe/mntner/OWNER-MNT"
        },
        "name" : "mnt-by",
        "value" : "OWNER-MNT",
        "referenced-type" : "mntner"
        }, {
        "name" : "source",
        "value" : "RIPE"
        } ]
    }
    } ]
},
"errormessages" : {
    "errormessage" : [ {
    "severity" : "Error",
    "text" : "Object [%s] %s is referenced from other objects",
    "args" : [ {
        "value" : "person"
    }, {
        "value" : "PP1-RIPE"
    } ]
    } ]
},
"terms-and-conditions" : {
    "type" : "locator",
    "href" : "http://www.ripe.net/db/support/db-terms-conditions.pdf"
}
}

Example JSON Response for incorrect password

{
"link" : {
    "type" : "locator",
    "href" : "http://rest.db.ripe.net/ripe/person/PP1-RIPE"
},
"objects" : {
    "object" : [ {
    "type" : "person",
    "link" : {
        "type" : "locator",
        "href" : "http://rest.db.ripe.net/ripe/person/PP1-RIPE"
    },
    "source" : {
        "id" : "ripe"
    },
    "primary-key" : {
        "attribute" : [ {
        "name" : "nic-hdl",
        "value" : "PP1-RIPE"
        } ]
    },
    "attributes" : {
        "attribute" : [ {
        "name" : "person",
        "value" : "Pauleth Palthen"
        }, {
        "name" : "address",
        "value" : "Singel 258"
        }, {
        "name" : "phone",
        "value" : "+31-1234567890"
        }, {
        "name" : "e-mail",
        "value" : "noreply@ripe.net"
        }, {
        "link" : {
            "type" : "locator",
            "href" : "http://rest.db.ripe.net/ripe/mntner/OWNER-MNT"
        },
        "name" : "mnt-by",
        "value" : "OWNER-MNT",
        "referenced-type" : "mntner"
        }, {
        "name" : "nic-hdl",
        "value" : "PP1-RIPE"
        }, {
        "name" : "remarks",
        "value" : "remark"
        }, {
        "name" : "source",
        "value" : "RIPE"
        } ]
    }
    } ]
},
"errormessages" : {
    "errormessage" : [ {
    "severity" : "Error",
    "text" : "Authorisation for [%s] %s failed\nusing \"%s:\"\nnot authenticated by: %s",
    "args" : [ {
        "value" : "person"
    }, {
        "value" : "PP1-RIPE"
    }, {
        "value" : "mnt-by"
    }, {
        "value" : "OWNER-MNT"
    } ]
    } ]
},
"terms-and-conditions" : {
    "type" : "locator",
    "href" : "http://www.ripe.net/db/support/db-terms-conditions.pdf"
}
}

Example JSON Object Type error:

{
"link" : {
    "type" : "locator",
    "href" : "http://rest.db.ripe.net/ripe/mntner/PP1-RIPE"
},
"errormessages" : {
    "errormessage" : [ {
    "severity" : "Error",
    "text" : "Object type and key specified in URI (%s: %s) do not match the WhoisResources contents",
    "args" : [ {
        "value" : "mntner"
    }, {
        "value" : "PP1-RIPE"
    } ]
    } ]
},
"terms-and-conditions" : {
    "type" : "locator",
    "href" : "http://www.ripe.net/db/support/db-terms-conditions.pdf"
}
}

# Text/Plain

Example response

mntner:         RIPE-DBM-MNT
descr:          Mntner for RIPE DBM objects.
admin-c:        RD132-RIPE
tech-c:         RD132-RIPE
org:            ORG-NCC1-RIPE
auth:           PGPKEY-1290F9D2
auth:           MD5-PW # Filtered
mnt-by:         RIPE-DBM-MNT
created:        2002-09-17T10:24:30Z
last-modified:  2015-07-22T09:34:26Z
source:         RIPE # Filtered

# Elements

Pointer to the resource.

  • The XLink format is used for the links (ref: http://en.wikipedia.org/wiki/XLink).

      <link xlink:type="locator" xlink:href="http://rest-test.db.ripe.net/test/person/TP1-TEST"/>
  "link": {
      "xlink:type": "locator",
      "xlink:href": "http://rest-test.db.ripe.net/test/person/TP1-TEST"
  }

# Parameters:

part of a search response, indicating which query flags were used.

  • Inverse-lookup: wraps a set of inverse-attribute

  • Inverse-attribute: value of an inverse query flag

  • Type-filters: wraps a set of type-filter

  • Type-filter: id = the RPSL object type to limit the search to

  • Flags: wraps a set of flag

  • Flag: the value of a query flag

  • Query-strings: wraps a set of query-string

  • Query-string: the value of the query string

  • Sources: wraps a set of source

  • Source: id of RIPE database source

      <parameters>
      <inverse-lookup/>
      <type-filters/>
      <flags>
          <flag value="r"/>
          ...
      </flags>
      <query-strings>
          <query-string value="LP1-TEST"/>
      </query-strings>
      <sources>
          <source id="TEST"/>
      </sources>
  </parameters>
  "parameters": {
      "inverse-lookup": {"inverse-attribute": []},
      "type-filters": {"type-filter": []},
      "flags": {
          "flag": [{"value": "r"}, ...]
      },
      "query-strings": {
          "query-string": [{"value": "LP1-TEST"}]
      },
      "sources": {
          "source": [{"id": "TEST"}]
      }
  }

# Objects:

A set of (RPSL-) object representations.

  • Type: the RPSL object type

  • Link: see above

  • Source: indication of which RIPE source object is registered in

  • Primary-key: searchable key in the RIPE database

  • Attributes: set of attribute describing the RPSL object

  • Attribute:

    • can be divided by mandatory:
      • name, value
    • and non-mandatory:
      • link (see Link), referenced-type: used to describe pointer to resource where referenced-type is the RIPE object type.

  • comment

          <objects>
          <object>...</object>
          ...
      </objects>
      "objects": {
          "object": [ ... ]
      }

# Object:

Representation of a RPSL object. Contained within Objects.

    <object type="person">
        <link xlink:type="locator" xlink:href="http://rest-test.db.ripe.net/test/person/LP1-TEST"/>
        <source id="test"/>
        <primary-key>
            <attribute name="nic-hdl" value="LP1-TEST"/>
        </primary-key>
        <attributes>
            <attribute .../>
            ...
        </attributes>
        <tags/>
    </object>
    "object": [
        {"type": "person",
        "link": {
                    "xlink:type": "locator",
                    "xlink:href": "http://rest-test.db.ripe.net/test/person/LP1-TEST"
                },
        "source": {"id": "test"},
        "primary-key": { "attribute": [{ "name": "nic-hdl", "value": "LP1-TEST" }] },
        "attributes": { "attribute": [ ... ] },
        "tags": { "tag": [] }
    }
    ]

# Tags:

Set of tag

  • Tag: extra data about a particular object in the RIPE database. Consists of id - the name of the tag, and data

      <tags>
      <tag id="..." data="..."/>
      ...
  </tags>
  "tags": {
      "tag": [ {"id": "...", "data": "..."}, ...]
  }

# Geolocation-attributes:

Extra information for inetnum / inet6num RPSL objects.

  • Location: a link (see Link) to the inet(6)num and a longitude latitude value

  • Language: a link (see Link) to the inet(6)num and an ISO 639-1 language code

      <geolocation-attributes>
      <location value="52.375599 4.899902">
          <link xlink:type="locator" xlink:href="..."/>
      </location>
  </geolocation-attributes>
  "geolocation-attributes": {
      "location": [{"value": "52.375599 4.899902", "link": {"xlink:type": "locator", "xlink:href": "..."}}]
  }

# Sources:

A set of available source for the RIPE database

  • Source: name, id

  • Valid values: RIPE, TEST

      <sources>
      <source name="RIPE" id="ripe"/>
      <source name="TEST" id="test"/>
  </sources>
  "sources" : {
      "source" : [ {"name" : "RIPE", "id" : "ripe"}, {"name" : "TEST","id" : "test"} ]
  }

# Grs-sources:

A set of available grs-source for the RIPE database

  • Source: name, id and grs-id

  • Valid Values: AFRINIC-GRS, APNIC-GRS, ARIN-GRS, JPIRR-GRS, LACNIC-GRS, RADB-GRS

      <grs-sources>
      <source name="APNIC-GRS" id="apnic-grs" grs-id="apnic-grs"/>
  </grs-sources>
  "grs-sources" : {
      "source" : [ {"name" : "APNIC-GRS", "id" : "apnic-grs", "grs-id" : "apnic-grs"} ]
  }

# Versions:

Enumeration of the changes of a particular object. Will only be in the versions response payload. Consists of type (see Type), key (see Primary key) and version.

  • Version: information about a particular version of the object. It can either be deleted, in which case there's only a date, or show information about the revision.

      <versions type="aut-num" key="...">
      <version>
          <revision>1</revision>
          <date>2013-08-27 11:23</date>
          <operation>ADD/UPD</operation>
      </version>
  </versions>
  "versions" : {
      "type" : "aut-num",
      "key" : "...",
      "version" : [ {
          "deleted" : null,
          "revision" : 1,
          "date" : "2013-08-27 11:26",
          "operation" : "ADD/UPD"
      } ]
  }

# Error messages:

A set of errormessage containing information about the performed operation. A message concerns the operation, an object of the operation, or an attribute of an object. It has a severity (Error, Warning, Info), a text description and a set of arguments supplied to the operation.

    <errormessages>
        <errormessage severity="..." text="...">
        <args value="..."/>
        <!--...more "args" elements...-->
        </errormessage>
        <!--...more "errormessage" elements...-->
    </errormessages>
    "errormessages" : {
        "errormessage" : [ {
            "severity" : "...",
            "text" : "...",
            "args" : [ ]
            } ]
    }

Example XML error response:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<whois-resources xmlns:xlink="http://www.w3.org/1999/xlink">
<link xlink:type="locator" xlink:href="http://rest.db.ripe.net/invalid/person/TP1-RIPE"/>
<errormessages>
    <errormessage severity="Error" text="Invalid source '%s'">
        <args value="invalid"/>
    </errormessage>
</errormessages>
<terms-and-conditions xlink:type="locator" xlink:href="http://www.ripe.net/db/support/db-terms-conditions.pdf"/>
</whois-resources>

Example JSON error response:

{
"link" : {
    "type" : "locator",
    "href" : "http://rest.db.ripe.net/invalid/person/TP1-RIPE"
},
"errormessages" : {
    "errormessage" : [ {
    "severity" : "Error",
    "text" : "Invalid source '%s'",
    "args" : [ {
        "value" : "invalid"
    } ]
    } ]
},
"terms-and-conditions" : {
    "type" : "locator",
    "href" : "http://www.ripe.net/db/support/db-terms-conditions.pdf"
}
}

# Data Types

  • Inverse Attribute
  • One of: abuse-c, abuse-mailbox, admin-c, auth, author, ds-rdata, fingerprint, form, ifaddr, irt-nfy, local-as, mbrs-by-ref, member-of, mnt-by, mnt-domains, mnt-irt, mnt-lower, mnt-nfy, mnt-ref, mnt-routes, notify, nserver, org, origin, person, ping-hdl, ref-nfy, tech-c, upd-to, zone-c.
  • Object Type
  • One of: as-block, as-set, aut-num, domain, filter-set, inet6num, inetnum, inet-rtr, irt, key-cert, mntner, organisation, peering-set, person, poem, poetic-form, role, route, route6, route-set, rtr-set.
  • Severity
  • One of: Error, Warning, Info.
  • Source
  • One of: RIPE, TEST, or a GRS source (AFRINIC-GRS, APNIC-GRS, ARIN-GRS, JPIRR-GRS, LACNIC-GRS, RADB-GRS, RIPE-GRS).

# Template Resources

# Description

RPSL templates object type.

# XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<template-resources xmlns:xlink="http://www.w3.org/1999/xlink">
<link xlink:type="locator" xlink:href="http://rest.db.ripe.net/metadata/templates/person"/>
<service name="getObjectTemplate"/>
<templates>
    <template type="person">
        <source id="ripe"/>
        <attributes>
            <attribute name="person" requirement="MANDATORY" cardinality="SINGLE" keys="LOOKUP_KEY"/>
            <attribute name="address" requirement="MANDATORY" cardinality="MULTIPLE" keys=""/>
            <attribute name="phone" requirement="MANDATORY" cardinality="MULTIPLE" keys=""/>
            <attribute name="fax-no" requirement="OPTIONAL" cardinality="MULTIPLE" keys=""/>
            <attribute name="e-mail" requirement="OPTIONAL" cardinality="MULTIPLE" keys="LOOKUP_KEY"/>
            <attribute name="org" requirement="OPTIONAL" cardinality="MULTIPLE" keys="INVERSE_KEY"/>
            <attribute name="nic-hdl" requirement="MANDATORY" cardinality="SINGLE" keys="PRIMARY_KEY LOOKUP_KEY"/>
            <attribute name="remarks" requirement="OPTIONAL" cardinality="MULTIPLE" keys=""/>
            <attribute name="notify" requirement="OPTIONAL" cardinality="MULTIPLE" keys="INVERSE_KEY"/>
            <attribute name="abuse-mailbox" requirement="OPTIONAL" cardinality="MULTIPLE" keys="INVERSE_KEY"/>
            <attribute name="mnt-by" requirement="MANDATORY" cardinality="MULTIPLE" keys="INVERSE_KEY"/>
            <attribute name="source" requirement="MANDATORY" cardinality="SINGLE" keys=""/>
        </attributes>
    </template>
</templates>
</template-resources>

# JSON

{
    "service": "getObjectTemplate",
    "link": {
    "xlink:type": "locator",
    "xlink:href": "http://rest.db.ripe.net/metadata/templates/peering-set"
    },
    "service" : {
    "name" : "getObjectTemplate"
    },
    "templates": {
    "template": [
        {
        "type": "peering-set",
        "source": {
            "id": "ripe"
        },
        "attributes": {
            "attribute": [
            {
                "name": "peering-set",
                "requirement": "MANDATORY",
                "cardinality": "SINGLE",
                "keys": ["PRIMARY_KEY","LOOKUP_KEY"]
            },
            {
                "name": "descr",
                "requirement": "MANDATORY",
                "cardinality": "MULTIPLE",
                "keys": []
            },
            {
                "name": "peering",
                "requirement": "OPTIONAL",
                "cardinality": "MULTIPLE",
                "keys": []
            },
            {
                "name": "mp-peering",
                "requirement": "OPTIONAL",
                "cardinality": "MULTIPLE",
                "keys": []
            },
            {
                "name": "remarks",
                "requirement": "OPTIONAL",
                "cardinality": "MULTIPLE",
                "keys": []
            },
            {
                "name": "org",
                "requirement": "OPTIONAL",
                "cardinality": "MULTIPLE",
                "keys": ["INVERSE_KEY"]
            },
            {
                "name": "tech-c",
                "requirement": "MANDATORY",
                "cardinality": "MULTIPLE",
                "keys": ["INVERSE_KEY"]
            },
            {
                "name": "admin-c",
                "requirement": "MANDATORY",
                "cardinality": "MULTIPLE",
                "keys": ["INVERSE_KEY"]
            },
            {
                "name": "notify",
                "requirement": "OPTIONAL",
                "cardinality": "MULTIPLE",
                "keys": ["INVERSE_KEY"]
            },
            {
                "name": "mnt-by",
                "requirement": "MANDATORY",
                "cardinality": "MULTIPLE",
                "keys": ["INVERSE_KEY"]
            },
            {
                "name": "mnt-lower",
                "requirement": "OPTIONAL",
                "cardinality": "MULTIPLE",
                "keys": ["INVERSE_KEY"]
            },
            {
                "name": "source",
                "requirement": "MANDATORY",
                "cardinality": "SINGLE",
                "keys": []
            }
            ]
        }
        }
    ]
    }
}

# The Attributes in Database Objects

All objects in the RIPE Database have the same structure. They contain a set of ‘attribute-value' pairs in plain text. These ‘attribute-value' pairs can take different forms. Attributes are sometimes referred to as ‘keys'.

All the database content is currently in Latin-1 encoding. Any characters not in Latin-1 is automatically converted to Latin-1. Any characters without an equivalent in Latin-1 are substituted with a question mark character. One exception is that IDN domain names in email address attributes are automatically converted to Punycode.

When an object is stored in the database, the full text supplied by the user is stored as a single item as close as possible to what the user supplied. This means that the attributes and values are almost unchanged and the order is maintained. The spacing between the attributes and values may be adjusted to align the values and make them easier to read. Parts of the object are also extracted from the text and stored in separate tables and indexes along with some generated metadata to help with database functionality.

This is a list of changes that are made to the data supplied by the user:

  • Generate or change supplied values for generated attributes
  • Add missing "status:" to an aut-num object with generated value
  • Set/reset "status:" to 'LEGACY' on more specific objects to a legacy object
  • Change all attribute names to lower case
  • Change source value to upper case
  • Remove a trailing dot on reverse domain keys
  • Remove tabs and excess spaces from inetnum ranges and inet(6)num status values
  • Remove leading zeroes from inetnum ranges
  • Convert inetnum prefix value to a range
  • Convert inet6num values to canonical format
  • Remove end of line comments from primary and type attributes
  • Join up split values in primary and type attributes

In some cases an information message is added to the acknowledgement sent back to the user making the update. For example:

***Info:    Value 193.in-addr.arpa. converted to 193.in-addr.arpa

# RPSL Object Types

In this section, the many types of objects in the RIPE Database are described. Objects contain a piece of information relating to an Internet resource or a supporting or administrative function.

For each object, a template shows which attributes are allowed for this type. The properties of the attributes are also shown, as they apply to the attributes within this object type. Following the template, some description is included about the definition and use of the included attributes.

In the object templates, required attributes are shown as ‘optional*'. This is because the concept of ‘required' was added long after the data model and syntax mechanism was designed. It is handled at a later stage by applying business rules built into the software. These templates are used by the software to apply syntax checks. We don't want to document them in a way that is significantly different to the way the software applies them. We want to make it clear that there is a difference between purely ‘optional' and ‘required'.

# Description of Attributes Common to all Objects

  • "org:" – this optional attribute references the primary key, or id, of an organisation object that currently exists in the database. The referenced object contains details of the organisation that holds Internet resources or secondary objects to help manage resources in the RIPE Database or specifies business relations. This attribute is required on the inet(6)num objects with the following status values:

    • ALLOCATED-BY-RIR
    • ALLOCATED PA
    • ALLOCATED-ASSIGNED PA
    • ALLOCATED PI
    • ALLOCATED UNESPECIFIED

  • "admin-c:" – this attribute is optional in some objects and mandatory in others. It references the primary key, or NIC Handle, of either a role or person object. It should always reference a role object, except in the role object where it optionally references nested role objects or a person object. The reference must be the contact details of an on-site administrative contact. This contact may be a single person, or it may be a role within the organisation that more than one person takes on. These people may or may not be listed in the role object.

  • "tech-c:" – this attribute is optional in some objects and mandatory in others. It references the primary key, or Nic Handle, of either a role or person object. It should always reference a role object, except in the role object where it optionally references nested role objects or a person object. The reference must be the contact details of a technical contact. This contact may be a single person, or it may be a role within the organisation that more than one person takes on. These people may or may not be listed in the role object.

  • "remarks:" – this optional attribute can be any free format text, within the allowable encoding. This attribute can even have a blank value and be used as a spacer to separate different parts of the information in an object. Some objects have very complex arrangements in their remarks with lots of formatting and style to create a layout that almost personalises their data. Keep in mind that it is data and the RIPE Database is not the best place to display ASCII art. The best advice on using remarks is to ‘keep it simple'.

  • "notify:" – this optional attribute specifies an email address to which notifications of changes to an object will be sent. Only the email addresses from the "notify:" attribute values contained in ‘this' object will be notified of changes to ‘this' object. Only successful changes will be notified. Within the RIPE NCC, we can override this notification mechanism. For example, if the community agrees on a syntax change that affects many objects in the database, this change may be done as a bulk update by the RIPE NCC. In some cases, the RIPE NCC does not want to trigger hundreds of thousands or even millions of emails to be sent as part of the implementation of an agreed change.

  • "mnt-by:" – this mandatory attribute references the primary key, or name, of a mntner object that currently exists in the database. This mntner object's credentials must authorise any operations performed on the object that contains this attribute. The mntner object must exist in the database before it can be referenced in other objects. In some objects, the mntner object referenced in a "mnt-by:" attribute can have a range of additional powers. This is explained in more detail in the section 'Authorisation'. When this applies, it will be stated in the object template descriptions.

  • "created:" – This attribute reflects when the object was created in the RIPE Database. Because a large number of objects were imported in bulk from a previous incarnation of the RIPE Database on 21 September 2001, the actual "created" time for these objects can be very difficult or impossible to find. Because ISO 8601 does not support an "undefined" notation, the following date and time is used: 1970-01-01T00:00:00Z

  • "last-modified:" – This attribute reflects when it was last changed. If an object has never been changed, the value of this attribute will be the same as the "created:" attribute. If an object was part of the bulk import on 21 September 2001 and has never been modified, the original import date and time was used for this attribute. This attribute will not be modified as a result of bulk changes, applied to the database by the RIPE NCC, that have no semantic meaning. An example of this is when an attribute is deprecated and removed from all objects containing it.

  • "source:" – The "source:" attribute should specify the authoritative registry where the object is registered. In the RIPE Database, all source values are set to ‘RIPE'. The same value is used even when the object is a copy of a resource from another registry. The source may be appended with a software-generated end-of-line comment ‘# Filtered'. This is not part of the stored data. It may be generated when the object is displayed, depending on the query flags used. (Note that users cannot add end-of-line comments to a source attribute. Please see 'End of Line Comments' for more information.) For the RIPE TEST Database the source value is ‘TEST' for all objects. This may also be appended with ‘# Filtered'. For the Global Resource Service (GRS), the RIPE NCC mirrors several other resource databases. The source value reflects which of the mirrored databases returned the query result. For example ‘APNIC-GRS' if the queried resource was found in the mirror of the APNIC Database.

# Descriptions of Primary Objects

# Description of the AUT-NUM Object

Below is the object template for the aut-num object. It lists all possible attributes that are allowed in this object type. Required attributes are shown as ‘mandatory'.

Attribute Name   Presence   Repeat     Indexed 
aut-num:         mandatory  single     primary/lookup
as-name:         mandatory  single    
descr:           optional   multiple  
member-of:       optional   multiple   inverse
import-via:      optional   multiple  
import:          optional   multiple  
mp-import:       optional   multiple  
export-via:      optional   multiple  
export:          optional   multiple  
mp-export:       optional   multiple  
default:         optional   multiple  
mp-default:      optional   multiple  
remarks:         optional   multiple  
org:             optional   single     inverse
sponsoring-org:  optional   single     inverse
admin-c:         mandatory  multiple   inverse
tech-c:          mandatory  multiple   inverse
abuse-c:         optional   single     inverse
status:          generated  single    
notify:          optional   multiple   inverse
mnt-by:          mandatory  multiple   inverse
created:         generated  single
last-modified:   generated  single
source:          mandatory  single

The aut-num object serves a dual purpose in the database. As part of the RIPE Internet Number Registry, it contains the registration details of an Autonomous System Number (ASN) resource assigned by the RIPE NCC. As part of an Internet Routing Registry, it allows routing policies to be published. It refers to a group of IP networks that have a single and clearly defined external routing policy, operated by one or more network operators – an Autonomous System (AS). This is the only primary object that crosses over between these two registries in the RIPE Database.

Because of this crossover between the two registries contained within the RIPE Database, authorisation for creation of route(6) objects can and must be provided by both the address space holder and the holder of the AS number. For more details, see the section 'Authorisation'.

The number part of an ASN is a 32-bit number. Historically, these were 16-bit numbers. But when the pool of available numbers was running low, they were extended to 32 bits. In theory, there is no difference between a 16-bit ASN and a 32-bit ASN, except perhaps the size of the number. One is just a subset of the other. For technical reasons, some users still prefer a 16-bit ASN.

The primary key value will be in this format:

‘ASn' where ‘n' is a 32-bit unsigned, number in the range 0: 4,294,967,295.

Leading zeroes (AS065536) are not allowed and will be removed (AS65536) by the database software.

Description of Attributes Specific to the AUT-NUM Object

  • "aut-num:" – the registered AS Number of the Autonomous System (AS) that this object describes. It must start with the two letters ‘AS'.
  • "as-name:" – a symbolic name of the AS. Must be a single word of letters, numbers and the characters ‘-‘ and ‘_'.
  • "descr:" - A short description related to the object.
  • "member-of:" - references a set object that this AS wants to be a member of. This membership claim must be acknowledged by a respective "mbrs-by-ref:" attribute in the referenced set object.
  • "import:", "export:" and "default:" - specify the IPv4 routing policies of the AS.
  • "import-via:" and "export-via:" - specify routing policies regarding non-adjacent networks. These attributes help participants of Multi-Lateral Peering services to inform the intermediate autonomous system what routing policy should be applied towards other participants.
  • "mp-import:", "mp-export:" and "mp-default:" - specify IPv4, IPv6 and multicast routing policies.
  • "org:" – single-valued to make sure that only one organisation is responsible for this resource. This is a required attribute in the aut-num object. If the "status:" value is ‘ASSIGNED' then the object must have an "org:" attribute.
  • "sponsoring-org:" – references an organisation object representing the sponsoring organisation that is administratively responsible for the resource. This value is generated by the software and synchronised with the registry information. If a resource is no longer subject to a contract with the sponsoring organisation, or a contract is signed with a new sponsoring organisation, this will be updated in the registry information for this resource. The aut-num object in the RIPE Database will then be synchronised with the changes. A user cannot set, remove or change this value. An aut-num object can be created without this attribute. But the RIPE NCC can remove the attribute during a period in-between the ending of a contract with one sponsoring organisation and the signing of a contract with a new sponsoring organisation.
  • "status:" – There are three different categories of aut-num objects in the RIPE Database. This generated "status:" attribute clearly shows which category an aut-num object belongs to. The categories are:
    • ‘ASSIGNED', - all AS Number resources assigned by the RIPE NCC
    • ‘LEGACY' - all legacy AS Numbers used within the RIPE region but not assigned by the RIPE NCC
    • ‘OTHER' – any aut-num that is not one of the above, typically a non-authoritative copy of an aut-num from another RIR region used for routing authentication in the RIPE Database A user cannot set, remove or change this value. It is determined from the status noted for this resource in the registry information and set by the software when the object is updated. An update to an aut-num object will never fail because of a missing "status:" attribute or incorrect value. The software will add or correct it. The status of an aut-num is only administrative. It does not affect the usage of an aut-num for any routing purpose or impact certification in any way.
  • “abuse-c:” – This attribute references an abuse contact object. If present, this overrides any existing reference on a referenced organisation object. This can only be a role object that contains an "abuse-mailbox:" attribute. Making this reference will remove any query limits for that role object, which must only include business data (no personal information).
  • “mnt-by:” – This attribute may have extra powers in addition to its default behaviour. In the absence of any “mnt-routes:” attributes, the mntner objects listed in the “mnt-by:” attributes can authorise the creation of route(6) objects originated by this AS number. For more details, see the section 'Authorisation'.

# Description of the DOMAIN Object

Below is the object template for the domain object. It lists all possible attributes allowed in this object type.

Attribute Name    Presence       Repeat       Indexed
domain:           mandatory      single       primary/lookup
descr:            optional       multiple
org:              optional       multiple     inverse
admin-c:          mandatory      multiple     inverse
tech-c:           mandatory      multiple     inverse
zone-c:           mandatory      multiple     inverse
nserver:          mandatory      multiple     inverse
ds-rdata:         optional       multiple     inverse
remarks:          optional       multiple
notify:           optional       multiple     inverse
mnt-by:           mandatory      multiple     inverse
created:          generated      single
last-modified:    generated      single
source:           mandatory      single

The domain object is mainly for registering reverse delegations (number-to-name translations) in both the RIPE Database and the DNS zone files. The RIPE Database is used as the management database for producing the DNS zones. No forward domain names are stored in the RIPE Database. IANA (opens new window) provides information about forward domains.

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).

The domain object is also used for registering ENUM delegations using the domain name e164.arpa.

For IPv4 addresses, a dash is allowed in the fourth octet of the reverse address. This allows for reverse DNS delegations for address space that doesn't fall on octet boundaries as specified in RFC 2317 (opens new window). A dash is not allowed in any other octet. For example:

IPv4 address range
10.2.1.6 - 10.2.1.25
reverse delegation
6-25.1.2.10.in-addr.arpa

This is created in the RIPE Database as a single object, including the dash in the range. The DNS provisioning software handles the dash notation and propagates this delegation to the zone file. The range 0-255 is a special case and is not allowed in the fourth octet. Modification and deletion can be performed on this single object in the database. Any change is propagated into the zone file by the DNS provisioning software.

Reverse DNS zones in the RIPE Database do not allow child objects. From a DNS view, only the parent object is effective. Business rules in the database software check for hierarchies when a reverse domain object is being created. If either a less or more specific domain object already exists, the creation of the new object is rejected.

Description of Attributes Specific to the DOMAIN Object

  • “domain:” - This is the reverse delegation address or range. It can be for IPv4 or IPv6 addresses or an ENUM phone number. If a trailing dot is included it will be removed from the stored record.
  • “descr:” - A short description related to the object.
  • “zone-c:” - This attribute references the primary key, or NIC Handle, of either a role or person object. It should always reference a role object, except in the role object where it optionally references nested role objects or a person object.
  • “nserver:” - The "nserver:" attributes in each domain object define the officially delegated DNS nameservers (the ‘NS' in DNS zone contents). If a trailing dot is included it will be removed from the stored record. The nameserver name can optionally be followed by an IPv4 or IPv6 address as a glue record.
  • “ds-rdata:” – This attribute holds information about a signed delegation record for DNS Security Extensions (DNSSEC). In DNSSEC the Delegation Signer (DS) Resource Record is created from a DNSKEY Resource Record by comparing it with the public key. The parent publishes the DS Resource Record (opens new window). The "ds-rdata:" attribute contains the RDATA of the DS Resource Records related to the domain (as shown in the "domain:" attribute). ds-rdata: 64431 5 1 278BF194C29A812B33935BB2517E17D1486210FA The tools provided with BIND (version 9.3.0 and later) will generate a "ds set" during signing. Before an update, you can copy the DS Rdata into the attributes.

# Description of the INET6NUM Object

Below is the object template for the inet6num object. It lists all possible attributes that are allowed in this object type. Required attributes are shown as ‘mandatory'.

Attribute Name    Presence    Repeat     Indexed
inet6num:         mandatory   single     primary/lookup key
netname:          mandatory   single     lookup key
descr:            optional    multiple  
country:          mandatory   multiple  
geofeed:          optional    single
geoloc:           optional    single    
language:         optional    multiple  
org:              optional    single     inverse key
sponsoring-org:   optional    single    
admin-c:          mandatory   multiple   inverse key
tech-c:           mandatory   multiple   inverse key
abuse-c:          optional    single     inverse key
status:           mandatory   single    
assignment-size:  optional    single    
remarks:          optional    multiple  
notify:           optional    multiple   inverse key
mnt-by:           mandatory   multiple   inverse key
mnt-lower:        optional    multiple   inverse key
mnt-routes:       optional    multiple   inverse key
mnt-domains:      optional    multiple   inverse key
mnt-irt:          optional    multiple   inverse key
created:          generated   single
last-modified:    generated   single
source:           mandatory   single

An inet6num object contains information on allocations and assignments of IPv6 address space resources. This is one of the main elements of the RIPE Internet Number Registry.

Hierarchy of INET6NUM Objects

The inet6num objects cover many different types of data in the RIPE Database. The policy on issuing IPv6 addresses in the RIPE NCC service region (opens new window) explains more about the process of allocating and assigning addresses. This policy has changed a number of times over the years and some of the data in the RIPE Database was set up under previous policy conditions. The following paragraphs try to outline how this physical data in the RIPE Database is structured and how to make sense of it.

They are arranged in a hierarchical structure starting with a root object ::/0. This root object is there for data management reasons. It does not mean the RIPE NCC has any administrative authority over the whole IPv6 address space.

The next level down in the hierarchy after the root object includes placeholder objects representing the blocks of address space that the RIPE NCC is administratively responsible for. Most allocations to members are from the placeholder objects. However, there are also some allocations to members that have no parent placeholder object. All of these objects, from the root object down to and including the allocations to members, have the same status value of ‘ALLOCATED-BY-RIR'. There are no differences in the status to distinguish between blocks allocated by IANA to the RIPE NCC (opens new window) and allocations made by the RIPE NCC to members. For this you need to look at the “mnt-lower:”. For the blocks allocated by IANA to the RIPE NCC, the “mnt-lower:” has a RIPE NCC mntner, or it has no “mnt-lower:” which defaults to the “mnt-by:”. For allocations made from these administrative blocks to members, the “mnt-lower:” has the member's mntner. Some objects also include remarks highlighting that they are allocations from IANA to the RIPE NCC.

RIPE NCC also makes assignments to end users and TLD operators from the placeholder administrative objects. These are recognised by the “status:” and the “mnt-by:”. In most cases, these assignments will have the status ‘ASSIGNED PI' or ‘ASSIGNED ANYCAST'. Some of the earlier direct assignments still have the status ‘ASSIGNED'. These can still be recognised, as they should have a RIPE NCC mntner as one of the joint “mnt-by:” attributes.

Within the hierarchy, these allocations and assignments made from the administrative blocks are on the same level. They all have a placeholder object as their parent. All of these allocations and assignments are required to have a reference to an organisation object. Although the “org:” attribute is syntactically optional in an inet6num object, this requirement is set by software business rules.

The same principle applies to the assignments made from these administrative blocks. These are jointly managed by the RIPE NCC and either the End User or the sponsoring organisation. The sponsoring organisation is a RIPE NCC member who handles the End User's administration for this resource with the RIPE NCC.

An assignment is the lowest level of the hierarchy. There can be no more specific objects. For the allocations, the hierarchy can continue down several levels of more specific objects. All objects more specific to the allocation are created and managed in the RIPE Database by the member organisation, not by the RIPE NCC.

The allocation can be partitioned to match the member organisation's business structure, or the member can create an aggregation object with part of the allocation. Assignments of a fixed size will be made from this aggregation object. Finally, any part of the address space may be assigned to an End User. Again, the assignment is the lowest level, or an end point, for that part of the hierarchy. All of these levels can be recognised by the status values.

Description of Attributes Specific to the INET6NUM Object

  • “inet6num:” – This specifies a block of IPv6 addresses that the inet6num object presents. The block may be one or more addresses. Addresses can only be expressed in a prefix notation. The prefix is converted to a canonical format where necessary and an informational message will be returned to the user if this conversion is done. The format expresses addresses as a 128-bit number in hexadecimal groups of two bytes with colon separators between the groups . There is the possibility of using a shorthand notation for strings of consecutive zeros. Leading zeros from any two-byte group will be removed by the software. In this case, an informational message will be returned to the user.
  • “netname:” – This is a name given to a range of IP address space. A netname is made up of letters, digits, the underscore character and the hyphen character. The first character of a name must be a letter, and the last character of a name must be a letter or a digit. It is recommended that the same netname be used for any set of assignment ranges used for a common purpose, such as a customer or service.
  • “descr:” – A short description related to the object.
  • “country:” – This identifies a country using the ISO 3166 2-letter country codes. It has never been specified what this country represents. It could be the location of the head office of a multi-national company, where the server centre is based, or the home of the End User. Therefore, it cannot be used in any reliable way to map IP addresses to countries.
  • "geofeed:" – Contains a URL referencing a CSV file containing geolocation data for the resource. The geofeed format is defined in RFC 8805 (opens new window).
  • “geoloc:” – The geolocation coordinates for the resource in decimal degrees notation. Format is latitude followed by longitude, separated by a space. Latitude ranges from [-90,+90] and longitude from [-180,+180]. All more specific objects to the inet6num object containing this attribute inherit this data.
  • “language:” – Identifies the language as a two-letter code from the ISO 639-1 language code list. All more specific objects to the inet6num object containing this attribute inherit this data.
  • “org:” – single valued to make sure that only one organisation is responsible for this resource. This is a required attribute. In some cases, there are business rules to ensure that it is present. If the inet6num object is (jointly) maintained by the RIPE NCC then the object must have an “org:” attribute.
  • “sponsoring-org:” – references an organisation object representing the sponsoring organisation that is administratively responsible for the resource. If a resource is no longer subject to a contract with the sponsoring organisation, or a contract is signed with a new sponsoring organisation, this will be updated in the registry information for this resource. The inet6num object in the RIPE Database will then be synchronised with the changes. A user cannot set, remove or change this value. An inet6num object can be created without this attribute. The software will generate the correct value if it is required. The RIPE NCC will remove the attribute during a period in-between the ending of a contract with one sponsoring organisation and the signing of a contract with a new sponsoring organisation.
  • “abuse-c:” – This attribute references an abuse contact object. If present, this overrides any existing referenced organisation, or "abuse-c:" attribute present in the hierarchy of this object . This can only be a role object that contains an "abuse-mailbox:" attribute. Making this reference will remove any query limits for that role object, which must only include business data (no personal information).
  • “status:” – The status is used to show the different types of data stored in an inet6num object and the relative positions within a hierarchy. It can not be changed after creating the object and it can take one of these values:
    • ALLOCATED-BY-RIR – This is mostly used to identify blocks of addresses for which the RIPE NCC is administratively responsible and allocations made to members by the RIPE NCC.
    • ALLOCATED-BY-LIR – This is equivalent to the inetnum status ‘SUB-ALLOCATED PA'. A member can sub-allocate part of an allocation to another organisation. The other organisation may take over some of the management of this sub-allocation. However, the RIPE NCC member is still responsible for the whole of their registered resources, even if some parts of it have been sub-allocated to another organisation. Provisions have been built in to the RIPE Database software to ensure that the member is always technically in control of their allocated address space. Within such allocation, it is still required to document assignments using the status "AGGREGATED-BY-LIR" or "ASSIGNED". With the inet6num object there is no equivalent to the inetnum ‘LIR-PARTITIONED' status values allowing partitioning of an allocation by a member for internal business reasons.
    • AGGREGATED-BY-LIR – With IPv6, it is not necessary to document each individual End User assignment in the RIPE Database. If you have a group of End Users who all require blocks of addresses of the same size, say a /56, then you can create a large, single block with this status. The “assignment-size:” attribute specifies the size of the End User blocks. All assignments made from this block must have that size. It is possible to have two levels of ‘AGGREGATED-BY-LIR'. The "assignment-size" value cannot be changed after the inet6num object has been created.
    • ASSIGNED – These are assignments made by a member from their allocations to an End User.
    • ASSIGNED PI – These are assignments made by the RIPE NCC directly to an End User. In most cases, there is a member acting as the sponsoring organisation who handles the administrative processes on behalf of the End User. The sponsoring organisation may also manage the resource and related objects in the RIPE Database for the End User.
    • ASSIGNED ANYCAST – This address space has been assigned for use in TLD anycast networks.
  • “assignment-size:” – This specifies the common size of all individual assignments aggregated into one block with the status ‘AGGREGATED-BY-LIR'. This attribute is required to be present if the inet6num object has this status. The individual assignments do not need to be represented in the RIPE Database. But one or more assignments may be included if the member wishes to specify them for any reason. The maximum assignment size is 128.
  • “mnt-lower:” – This attribute references mntner objects that provide a set of authorisation tokens used for hierarchical object creation. These tokens are used to authorise the creation of the one level more specific (child) objects to the inet6num with the “mnt-lower:” attribute. If there is no “mnt-lower:” attribute, the “mnt-by:” authorises the creation of the child objects. This is explained in more detail in the section 'Authorisation'.
  • “mnt-domains:” – This attribute references mntner objects that provide a set of authorisation tokens used for domain object creation for reverse delegation. These tokens are used to authorise the creation of the domain objects whose prefixes are contained within the range of addresses set by the inet6num with the “mnt-domains:” attribute. Depending on the hierarchical relationship between the inet6num and domain objects, the “mnt-lower:” and “mnt-by:” attributes may also be used. This is explained in more detail in the section 'Authorisation'.
  • “mnt-routes:” – This attribute references mntner objects that provide a set of authorisation tokens that may be used for route6 object creation. Authorisation for route6 object creation is the most complex. This is explained in more detail in the section 'Authorisation'.
  • “mnt-irt:” – Despite its name, this attribute is not a reference to a mntner object. It references an irt object, which is a contact data object, like the role object. Authorisation is required from the irt object to be able to add this reference. These references apply in a hierarchical way. So where an “irt:” attribute is included, all more specifics to that inet6num object inherit the reference.

# Description of the INETNUM Object

Below is the object template for the inetnum object. It lists all possible attributes allowed in this object type. Required attributes are shown as ‘mandatory'.

Attribute Name    Presence   Repeat     Indexed
inetnum:          mandatory  single     primary/lookup key
netname:          mandatory  single     lookup key
descr:            optional   multiple  
country:          mandatory  multiple  
geofeed:          optional   single
geoloc:           optional   single    
language:         optional   multiple  
org:              optional   single     inverse key
sponsoring-org:   optional   single    
admin-c:          mandatory  multiple   inverse key
tech-c:           mandatory  multiple   inverse key
abuse-c:          optional   single     inverse key
status:           mandatory  single    
assignment-size:  optional   single 
remarks:          optional   multiple  
notify:           optional   multiple   inverse key
mnt-by:           mandatory  multiple   inverse key
mnt-lower:        optional   multiple   inverse key
mnt-routes:       optional   multiple   inverse key
mnt-domains:      optional   multiple   inverse key
mnt-irt:          optional   multiple   inverse key
created:          generated  single
last-modified:    generated  single
source:           mandatory  single

An inetnum object contains information on allocations and assignments of IPv4 address space resources. This is one of the main elements of the RIPE Internet Number Registry.

Hierarchy of INETNUM Objects

The inetnum objects cover many different types of data in the RIPE Database. The policy on issuing IPv4 addresses in the RIPE NCC service region (opens new window) explains more about the process of allocating and assigning addresses within the region. This policy has changed many times over the years. Some of the data in the RIPE Database was set up under previous policy conditions. The following paragraphs outline how this physical data in the RIPE Database is structured and how to make sense of it.

They are arranged in a hierarchical structure starting with a root object 0/0. This root object is there for data management reasons. It does not mean the RIPE NCC has any administrative authority over the whole IPv4 address space.

The next level down in the hierarchy after the root object includes placeholder objects representing the /8 ranges of address space that the RIPE NCC is administratively responsible for. There are also top-level legacy objects. These are outside the administrative control of the RIPE NCC but still used by resource holders within the RIPE NCC service region. These are generally smaller than a /8 but hierarchically on the same level. In other words, the root object is the parent of all the top-level legacy objects and these /8 placeholder objects. There may be other placeholder objects outside these /8 objects for historical reasons. These will be cleaned up at some point in the future. There are also some allocations to members that have no parent placeholder object.

The different types of data can be recognised by the “status:” and “mnt-lower:” attribute values. The root object and all the placeholder objects will have a status ‘ALLOCATED UNSPECIFIED'. But some of the member allocations may also have this status. If it has this status and has a RIPE NCC mntner as the “mnt-lower:”, then it is an administrative block. All the legacy objects will have the status ‘LEGACY'.

The RIPE NCC has directly issued address space to its members and End Users from the placeholder administrative objects. Again, these are recognised by the “status:” and “mnt-lower:” attribute values. Most allocations to members have a status ‘ALLOCATED PA'. But a few will also have the status ‘ALLOCATED UNSPECIFIED'. They will all have the members mntner as “mnt-lower:”. The assignments made by the RIPE NCC will have a status ‘ASSIGNED PI' or ‘ASSIGNED ANYCAST'. An allocation can also contain a single assignment with the same prefix length as the allocation, this combined object has the status 'ALLOCATED-ASSIGNED PA'.

Within the hierarchy, these allocations and assignments made from the administrative blocks are on the same level. They all have the placeholder objects as their parent. All of these allocations and assignments are required to have a reference to an organisation object. Although the “org:” attribute is syntactically optional in an inetnum object, this requirement is set by software business rules.

The member allocation objects are partly managed by the RIPE NCC and partly by the member. Because of this joint management, there are two maintainers on the object as the “mnt-by:” - these are the RIPE NCC maintainer and the LIR's default maintainer. If no default maintainer is present yet, the LIR must select it on the LIR Portal account details page. After doing this, the default maintainer will be reflected on all existing and new objects that have joint responsibility. Business rules determine which attributes can only be changed by the RIPE NCC and which ones can be changed by the LIR.

The same principle applies to the assignments made from these administrative blocks. These are jointly managed by the RIPE NCC and either the End User or the sponsoring organisation. The sponsoring organisation is a RIPE NCC member who handles the End User's administration for this resource with the RIPE NCC.

An assignment is the lowest level of the hierarchy. There can be no more specific objects. For the allocations, the hierarchy can continue down several levels of more specific objects. All objects more specific to the allocation are created and managed in the RIPE Database by the member organisation, not by the RIPE NCC.

The allocation can be partitioned to match the member organisation's business structure, or part of it can be sub-allocated to another organisation. Finally, any part of it may be assigned to an End User. Again, the assignment is the lowest level or end point for that part of the hierarchy. All of these levels can be recognised by the status values.

The top-level legacy objects are also jointly managed by the resource holder and the RIPE NCC. Some values in these objects have business rules preventing the resource holder from changing the values. All other parts of the object can be edited in the same way as any other object. Below the top-level legacy object, the resource holder can create as many levels of hierarchy as they wish. All the objects in this legacy hierarchy will have the same status value of ‘LEGACY'. So it is not possible to identify, for example, sub-allocations or assignments in the legacy hierarchy by status.

Description of Attributes Specific to the INETNUM Object

  • “inetnum:” – This specifies a range of IPv4 addresses that the inetnum object presents. The range may be one or more addresses.

Addresses can be expressed in either range or prefix notation. If prefix notation is used, the software will convert this to range notation and an informational message will be returned to the user. The end address must always be greater than or equal to the start address.

The range notation expresses addresses as 32-bit whole numbers in dotted quad notation. Leading zeros from any quad will be removed by the software and an informational message will be returned to the user.

  • “netname:” – This is a name given to a range of IP address space. A netname is made up of letters, digits, the underscore character and the hyphen character. The first character of a name must be a letter, and the last character of a name must be a letter or a digit. It is recommended that the same netname be used for any set of assignment ranges used for a common purpose, such as a customer or service.

  • “descr:” - A short description related to the object.

  • “country:” – This identifies a country using the ISO 3166-2 letter country codes. It has never been specified what this country represents. It could be the location of the head office of a multi-national company or where the server centre is based or the home of the End User. Therefore, it cannot be used in any reliable way to map IP addresses to countries.

  • "geofeed:" - Contains a URL referencing a CSV file containing geolocation data for the resource. The geofeed format is defined in RFC 8805 (opens new window).

  • “geoloc:” - The geolocation coordinates for the resource in decimal degrees notation. Format is latitude followed by longitude, separated by a space. Latitude ranges from [-90,+90] and longitude from [-180,+180]. All more specific objects to the inetnum object containing this attribute inherit this data.

  • “language:” - Identifies the language as a two-letter code from the ISO 639-1 language code list. All more specific objects to the inetnum object containing this attribute inherit this data.

  • “org:” – single-valued to make sure that only one organisation is responsible for this resource. This is a required attribute. In some cases, there are business rules to ensure that it is present. If the inetnum object is (jointly) maintained by the RIPE NCC then the object must have an “org:” attribute.

  • “sponsoring-org:” – references an organisation object representing the sponsoring organisation that is administratively responsible for the resource. This value is generated by the software and synchronised with the registry information. If a resource is no longer subject to a contract with the sponsoring organisation, or a contract is signed with a new sponsoring organisation, this will be updated in the registry information for this resource. The inetnum object in the RIPE Database will then be synchronised with the changes. A user cannot set, remove or change this value. An inetnum object can be created without this attribute. The software will generate the correct value if it is required. The RIPE NCC will remove the attribute during a period in-between the ending of a contract with one sponsoring organisation and the signing of a contract with a new sponsoring organisation.

  • “abuse-c:” – This attribute references an abuse contact object. If present, this overrides any existing referenced organisation, or * "abuse-c:" attribute present in the hierarchy of this object . This can only be a role object that contains an "abuse-mailbox:" attribute. Making this reference will remove any query limits for that role object, which must only include business data (no personal information).

  • “status:” – The status is used to show the different types of data stored in an inetnum object and the relative positions within a hierarchy. It can take one of these values:

    • ‘ALLOCATED UNSPECIFIED' – This is mostly used to identify blocks of addresses for which the RIPE NCC is administratively responsible. Historically, a small number of allocations made to members have this status also.
    • ‘ALLOCATED PA' – These are allocations made to members by the RIPE NCC.
    • 'ALLOCATED-ASSIGNED PA' - An allocation with a single assignment of the same prefix length.
    • AGGREGATED-BY-LIR – It is not necessary to document each individual End User assignment in the RIPE Database. If you have a group of End Users who all require blocks of addresses of the same size, say a /24, then you can create a large, single block with this status. The “assignment-size:” attribute specifies the size of the End User blocks. All assignments made from this block must have that size. It is possible to have two levels of ‘AGGREGATED-BY-LIR'. The "assignment-size" value cannot be changed after the inetnum object has been created.
    • ‘LIR-PARTITIONED PA' – This is to allow partitioning of an allocation by a member for internal business reasons.
    • ‘SUB-ALLOCATED PA' – A member can sub-allocate a part of an allocation to another organisation. The other organisation may take over some of the management of this sub-allocation. However, the RIPE NCC member is still responsible for the whole of their registered resources, even if parts of it have been sub-allocated. Provisions have been built in to the RIPE Database software to ensure that the member is always technically in control of their allocated address space.
    • ‘ASSIGNED PA' – These are assignments made by a member from their allocations to an End User.
    • ‘ASSIGNED PI' – These are assignments made by the RIPE NCC directly to an End User. In most cases, there is a member acting as the sponsoring organisation who handles the administrative processes on behalf of the End User. The sponsoring organisation may also manage the resource and related objects in the RIPE Database for the End User.
    • ‘ASSIGNED ANYCAST' - This address space has been assigned for use in TLD anycast networks.
    • ‘LEGACY' – These are resources that were allocated to users before the RIPE NCC was set up.

  • “mnt-lower:” – This attribute references mntner objects that provide a set of authorisation tokens used for hierarchical object creation. These tokens are used to authorise the creation of the one-level more specific (child) objects to the inetnum with the “mnt-lower:” attribute. If there is no “mnt-lower:” attribute, the “mnt-by:” authorises the creation of the child objects. This is explained in more detail in the section, 'Authorisation'

  • “mnt-domains:” - This attribute references mntner objects that provide a set of authorisation tokens used for domain object creation for reverse delegation. These tokens are used to authorise the creation of the domain objects whose prefixes are contained within the range of addresses set by the inetnum with the “mnt-domains:” attribute. Depending on the hierarchical relationship between the inetnum and domain objects, the “mnt-lower:” and “mnt-by:” attributes may also be used. This is explained in more detail in the section, 'Authorisation'

  • “mnt-routes:” - This attribute references mntner objects that provide a set of authorisation tokens that may be used for route object creation. Authorisation for route object creation is the most complex. This is explained in more detail in the section, 'Authorisation'

  • “mnt-irt:” - This attribute is not a reference to a mntner object. It references an irt object, which is a contact data object, like the role object. Authorisation is required from the irt object to be able to add this reference. These references apply in a hierarchical way. Therefore, where an “irt:” attribute is included, all more specifics to that inetnum object inherit the reference. This is explained in more detail in the section on Abuse Handling.

# Description of the ROUTE Object

Below is the object template for the route object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
route:          mandatory  single     primary/lookup key
descr:          optional   multiple   
origin:         mandatory  single     primary/inverse key
pingable:       optional   multiple   
ping-hdl:       optional   multiple   inverse key
holes:          optional   multiple   
org:            optional   multiple   inverse key
member-of:      optional   multiple   inverse key
inject:         optional   multiple   
aggr-mtd:       optional   single     
aggr-bndry:     optional   single     
export-comps:   optional   single     
components:     optional   single     
remarks:        optional   multiple   
notify:         optional   multiple   inverse key
mnt-lower:      optional   multiple   inverse key
mnt-routes:     optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
created:        generated  single     
last-modified:  generated  single     
source:         mandatory  single

A route object contains routing information for IPv4 address space resources. This is one of the main elements of the RIPE Internet Routing Registry.

Each interAS route (also known as an interdomain route) originated by an Autonomous System can be specified by using a route object for IPv4 addresses.

Authorisation for creating route objects is quite complex. There are multiple scenarios depending on who administers the address space. Because the RIPE INR and IRR are part of the same logical database, they can both be used for authorisation if the address space is RIPE NCC administered resources. For more details on this see the section, 'Authorisation'.

Please refer to RFC 2622 (opens new window) for more information on the specific routing information attributes in the route object.

The route consistency can be checked using the AS routing consistency tool (opens new window). This wizard compares the actual state of the Internet Routing tables (collected by RIS), in order to identify and correct possible inconsistencies in the RIPE Database.

Description of Attributes Specific to the ROUTE Object

  • “route:” – This specifies the IPv4 address prefix of the route. Together with the "origin:" attribute, these constitute a combined primary key of the route object. The address can only be specified as a prefix. It can be one or more IP addresses.
  • “descr:” - A short description related to the object.
  • “origin:” - AS Number of the Autonomous System that originates the route into the interAS routing system. The corresponding aut-num object for this Autonomous System may not exist in the RIPE Database.
  • “pingable:” - Allows a network operator to advertise an IP address of a node that should be reachable from outside networks. This node can be used as a destination address for diagnostic tests. The IP address must be within the address range of the route object containing this attribute.
  • “ping-hdl:” - References a person or role capable of responding to queries concerning the IP address(es) specified in the 'pingable' attribute.
  • “holes:” – These attributes form a list of the component address prefixes that are not reachable through the aggregate route (that part of the address space is possibly unallocated).
  • “member-of:” – This attribute identifies a set object that this route object wants to be a member of. This membership claim, however, should be acknowledged by a corresponding "mbrs-by-ref:" attribute in the referenced set object.
  • “inject:” – These attributes specify which routers perform the aggregation and when they perform it.
  • “aggr-mtd:” – This attribute specifies how the aggregate is generated.
  • “aggr-bndry:” – This attribute defines a set of Autonomous Systems, which form the aggregation boundary.
  • “export-comps:” – This attribute defines the set's policy filter, a logical expression which, when applied to a set of routes, returns a subset of these routes.
  • “components:” – This attribute defines the component routes used to form the aggregate.
  • “mnt-lower:” - Provides a set of authorisation tokens used for hierarchical object creation. These tokens are used to authorise the creation of the one level more specific (child) objects to the route with the “mnt-lower:” attribute. This is only used if the parent route object does not contain an “mnt-routes:” attribute. If there is no “mnt-routes:” or “mnt-lower:” attribute, the “mnt-by:” authorises the creation of the child objects. For more details see the section on authorisation.
  • “mnt-routes:” - Provides a set of authorisation tokens that may be used for exact match or more specific route object creation. For an exact match route object- if there is no “mnt-routes:” attribute, the “mnt-by:” is used. For a more specific route object the “mnt-lower may also be used, if present. The "mnt-routes:" attribute can include an optional list of prefix ranges inside curly brackets ("{}") or the keyword "ANY". This should follow the reference to the maintainer. The default, when no additional set items are specified, is "ANY" or all more specifics.

# Description of the ROUTE6 Object

Below is the object template for the route6 object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
route6:         mandatory  single     primary/lookup key
descr:          optional   multiple  
origin:         mandatory  single     primary/inverse key
pingable:       optional   multiple  
ping-hdl:       optional   multiple   inverse key
holes:          optional   multiple  
org:            optional   multiple   inverse key
member-of:      optional   multiple   inverse key
inject:         optional   multiple  
aggr-mtd:       optional   single    
aggr-bndry:     optional   single    
export-comps:   optional   single    
components:     optional   single    
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
mnt-lower:      optional   multiple   inverse key
mnt-routes:     optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A route6 object contains routing information for IPv6 address space resources. This is one of the main elements of the RIPE Internet Routing Registry.

Each interAS route (also known as an interdomain route) originated by an Autonomous System can be specified by using a route6 object for IPv6 addresses.

Authorisation for creating route6 objects is quite complex. There are four scenarios depending on who administers the address space and the AS Number. Because the RIPE INR and IRR are part of the same logical database, they can both be used for authorisation if the address space and/or AS Number are RIPE NCC administered resources. Where one or both are not administered by the RIPE NCC authorisation is bypassed but with the illusion of being genuine authorisation. For more details see the section 'Authorisation'.

The route consistency can be checked using the AS routing consistency tool (opens new window). This wizard compares the actual state of the Internet Routing tables (collected by RIS), in order to identify and correct possible inconsistencies in the RIPE Database.

Example ROUTE6 object including all optional attributes:

route6:        fc00:600::/32
descr:         Route
origin:        AS3333
mnt-by:        CHILD-MB-MNT
components:    protocol BGP4 { 0:0:0:0:1:1:1:1/10^+}
               protocol OSPF { 0:0:0:0:1:1:1:1/12^+}
inject:        at 1.2.3.4 action pref=100; upon HAVE-COMPONENTS { 0:0:0:0:1:1:1:1/0, 0:0:0:0:1:1:1:1/0 }
inject:        at rtrs-myset:AS2:rtrs-test:AS777234
inject:        at AS777234:rtrs-myset:AS2:rtrs-test:AS7777234
inject:        action community = {65535:295};
inject:        action community = {65535:20};
inject:        upon HAVE-COMPONENTS {::/8}
export-comps:  { fc00:600::/48 }
holes:         fc00:600::/48, fc00:600::/56, fc00:600::/64
aggr-bndry:    AS771234:AS-mytest:AS3:AS-test:AS775234
aggr-mtd:      outbound AS771234:AS-mytest:AS3:AS-test:AS775234
member-of:     AS200200:rs-test
member-of:     AS3333:rs-test
mnt-routes:    LIR-MNT { fc00:600::/36^+, fc00:600::/36^-, fc00:600::/16^36-48, fc00:600::/16^42, fc00:600::/56}
mnt-routes:    LIR2-MNT      anY
created:       1970-01-01T00:00:00Z
last-modified: 2012-01-01T15:30:45Z
source:        TEST

Please refer to RFC 2622 (opens new window) for more information on the specific routing information attributes in the route6 object.

Description of Attributes Specific to the ROUTE6 Object

  • “route6:” – This specifies the IPv6 address prefix of the route. Together with the "origin:" attribute, these constitute a combined primary key of the route6 object. The address can only be specified as a prefix. It can be one or more addresses.
  • “descr:” - A short description related to the object.
  • “origin:” - AS Number of the Autonomous System that originates the route into the interAS routing system. The corresponding aut-num object for this AS must already exist in the RIPE Database.
  • “pingable:” - Allows a network operator to advertise an IP address of a node that should be reachable from outside networks. This node can be used as a destination address for diagnostic tests. The IP address must be within the address range of the route6 object containing this attribute.
  • “ping-hdl:” - References a person or role capable of responding to queries concerning the IP address(es) specified in the 'pingable' attribute.
  • “holes:” – These attributes form a list of the component address prefixes that are not reachable through the aggregate route (that part of the address space is possibly unallocated).
  • “member-of:” – This attribute identifies a set object that this route6 object wants to be a member of. This membership claim, however, should be acknowledged by a corresponding "mbrs-by-ref:" attribute in the referenced set object.
  • “inject:” – These attributes specify which routers perform the aggregation and when they perform it.
  • “aggr-mtd:” – This attribute specifies how the aggregate is generated.
  • “aggr-bndry:” – This attribute defines a set of Autonomous Systems, which form the aggregation boundary.
  • “export-comps:” – This attribute defines the set's policy filter, a logical expression which when applied to a set of routes returns a subset of these routes.
  • “components:” – This attribute defines the component routes used to form the aggregate.
  • “mnt-lower:” - Provides a set of authorisation tokens used for hierarchical object creation. These tokens are used to authorise the creation of the one level more specific (child) objects to the route6 with the “mnt-lower:” attribute. This is only used if the parent route6 object does not contain an “mnt-routes:” attribute. If there is no “mnt-routes:” or “mnt-lower:” attribute, the “mnt-by:” authorises the creation of the child objects. For more details see the section 'Authorisation'.
  • “mnt-routes:” - Provides a set of authorisation tokens that may be used for exact match or more specific route6 object creation. For an exact match route6 object- if there is no “mnt-routes:” attribute, the “mnt-by:” is used. For a more specific route6 object- the “mnt-lower may also be used, if present. The "mnt-routes:" attribute can include an optional list of prefix ranges inside curly brackets ("{}") or the keyword "ANY". This should follow the reference to the maintainer. The default, when no additional set items are specified, is "ANY" or all more specifics.

# Description of the AS-SET Object

Below is the object template for the as-set object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
as-set:         mandatory  single     primary/lookup key
descr:          optional   multiple
members:        optional   multiple  
mbrs-by-ref:    optional   multiple   inverse key
remarks:        optional   multiple  
org:            optional   multiple   inverse key
tech-c:         mandatory  multiple   inverse key
admin-c:        mandatory  multiple   inverse key
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-lower:      optional   multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

To specify policies, it is often useful to define sets of objects. An as-set object forms a set of AS Numbers that can be referenced in many of the places where an AS Number reference can be used. Sets can be built with hierarchical names and can also include direct references to other sets. References can also be made indirectly by using the “mbrs-by-ref:” attribute. For more details see the section about sets.

Description of Attributes Specific to the AS-SET Object

  • “as-set:” – This attribute defines the name of the set which must start with ‘as-‘. It can be a hierarchical name with components separated by a colon (:). At least one component must be an as-set name. The others can be more set names or AS Numbers. All the set name components of a hierarchical name have to be as-set names. For more details see the section on sets.
  • “descr:” – A short description related to the object.
  • “members:” – These attributes list the direct members of the set. They can be either lists of AS Numbers, or other as-set names.
  • “mbrs-by-ref:” – These attributes can be used in all set objects. They allow indirect population of a set. If this attribute is used, the set also includes objects of the corresponding type (aut-num objects for as-set, for example) that are protected by one of these maintainers and whose "member-of:" attributes refer to the name of the set. If the value of a "mbrs-by-ref:" attribute is ANY, any object of the corresponding type referring to the set is a member of the set. If there are no "mbrs-by-ref:" attributes, the set is defined explicitly by the "members:" attributes. For more details see the section about sets.
  • “mnt-lower:” – When creating hierarchical sets, more specific object creations can be authorised using the “mnt-lower:”, if present. Otherwise the “mnt-by:” mntner objects can be used for authorisation. For more details see the section about sets.

# Description of the FILTER-SET Object

Below is the object template for the filter-set object. It lists all possible attributes that are allowed in this object type. Required attributes are shown as ‘mandatory'.

Attribute Name  Presence   Repeat     Indexed
filter-set:     mandatory  single     primary/lookup key
descr:          optional   multiple
filter:         optional   single  
mp-filter:      optional   single     
remarks:        optional   multiple  
org:            optional   multiple   inverse key
tech-c:         mandatory  multiple   inverse key
admin-c:        mandatory  multiple   inverse key
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-lower:      optional   multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

To specify routing policies, it is often useful to define sets of objects. A filter-set object defines a set of routes that match the criteria that you specify in your 'filter' – in other words, it filters out the routes that you do not want to see. The policy filter can match routes using any BGP path attribute, such as the destination address prefix, AS-path, or community attributes. Although the “filter:” and “mp-filter:” attributes are ‘single', they can be composite by using the operators AND, OR, and NOT.

Sets can be built with hierarchical names. Unlike other set objects the filter-set object does not include the “members:” or "mbrs-by-ref:" attributes.

Description of Attributes Specific to the FILTER-SET Object

  • “filter-set:” – This attribute defines the name of the set which must start with ‘fltr-‘. It can be a hierarchical name with components separated by a colon (:). At least one component must be a filter-set name. The others can be more set names or AS Numbers. All the set name components of a hierarchical name must be filter-set names. For more details, see the section about sets.
  • “descr:” – A short description related to the object.
  • “filter:” – This attribute defines the policy filter of the set. This is a logical expression which, when applied to a set of routes, returns a subset of these routes. These are the ones that you want to filter in or filter out. A filter-set object is required by business rules to include either a “filter:” or an “mp-filter:” attribute. One of these must exist, but you cannot include both attributes.
  • “mp-filter:” – This attribute extends the "filter:" attribute to allow you to specify IPv4 or IPv6 prefixes and prefix ranges. A filter-set object is required by business rules to include either a “filter:” or an “mp-filter:” attribute. One of these must exist, but you cannot include both attributes.
  • “mnt-lower:” – When creating hierarchical sets, more specific object creations can be authorised using the “mnt-lower:”, if present, otherwise they can be authorised by “mnt-by:” mntner objects. For more details see the section about sets.

# Description of the INET-RTR Object

Below is the object template for the inet-rtr object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence     Repeat       Indexed
inet-rtr:       mandatory    single       primary/lookup key
descr:          optional     multiple  
alias:          optional     multiple   
local-as:       mandatory    single       inverse key
ifaddr:         mandatory    multiple     inverse key
interface:      optional     multiple   
peer:           optional     multiple   
mp-peer:        optional     multiple   
member-of:      optional     multiple     inverse key
remarks:        optional     multiple   
org:            optional     multiple     inverse key
admin-c:        mandatory    multiple     inverse key
tech-c:         mandatory    multiple     inverse key
notify:         optional     multiple     inverse key
mnt-by:         mandatory    multiple     inverse key
created:        generated    single     
last-modified:  generated    single     
source:         mandatory    single

An inet-rtr object specifies a router and its peering protocols with other routers. Canonical DNS name aliases can be set up as well as specifying which AS Number owns/operates the router.

Description of Attributes Specific to the INET-RTR Object

  • “inet-rtr:” – This attribute is a valid DNS name of the router described by this object. It cannot end with a dot.
  • “descr:” – A short description related to the object.
  • “alias:” – Each optional “alias:” attribute is a canonical DNS name for the router.
  • “local-as:” – This attribute specifies the AS Number of the AS which owns/operates this router.
  • “ifaddr:” - This attribute specifies the interface address and mask length within an Internet router, as well as an optional action to set other parameters on this interface.
  • “interface:” – This attribute specifies an interface address, This can be multi-protocol. It can have an optional action, examples being RPSL preferences, prepending and MED. Also an optional tunnel definition can be included.
  • “peer:” – This attribute specifies the details of any interior or exterior router peering. This can be specified using either an IP address of the peer router or its inet-rtr name. A group of peers can be specified using an rtr-set name or a peering-set name. If peering-set name form is used, only the peerings in the corresponding peering set that are with this router are included.
  • “mp-peer:” – This attribute extends the "peer:" attribute to support both IPv4 and IPv6 addresses.
  • “member-of:” - references a set object that this router wants to be a member of. This membership claim must be acknowledged by a respective "mbrs-by-ref:" attribute in the referenced set object.

# Description of the PEERING-SET Object

Below is the object template for the peering-set object. It lists all possible attributes that are allowed in this object type. Required attributes are shown as ‘mandatory'.

Attribute  Name  Presence   Repeat     Indexed 
peering-set:     mandatory  single     primary/lookup key
descr:           optional   multiple
peering:         optional   multiple  
mp-peering:      optional   multiple
remarks:         optional   multiple  
org:             optional   multiple   inverse key
tech-c:          mandatory  multiple   inverse key
admin-c:         mandatory  multiple   inverse key
notify:          optional   multiple   inverse key
mnt-by:          mandatory  multiple   inverse key
mnt-lower:       optional   multiple   inverse key
created:         generated  single
last-modified:   generated  single
source:          mandatory  single

To specify routing policies, it is often useful to define sets of objects. A peering-set object defines a set of peerings that you specify in the “peering:” or “mp-peering:” attribute. It identifies all the peerings between a (set of) local routers and a (set of) peer routers. Although the “peering:” and “mp-peering:” attributes are ‘single', they can be composite by using the operators AND, OR, and EXCEPT. EXCEPT is equivalent to ‘AND NOT'.

Sets can be built with hierarchical names. Unlike other set objects the peering-set object does not include the “members:” or "mbrs-by-ref:" attributes.

Description of Attributes Specific to the PEERING-SET Object

  • “peering-set:” – This attribute defines the name of the set which must start with ‘prng-‘. It can be a hierarchical name with components separated by a colon (:). At least one component must be a peering-set name. The others can be more set names or AS Numbers. All the set name components of a hierarchical name have to be peering-set names. For more details see the section 'Set Objects'.

  • “descr:” – A short description related to the object.

  • “peering:” – This attribute defines a peering that you can use to import or export routes. A peering-set object is required by business rules to include either a “peering:” or an “mp-peering:” attribute. One of these must exist, but you cannot include both attributes.

  • “mp-peering:” – This attribute extends the "peering:" attribute to allow you to specify IPv4 or IPv6 prefixes and prefix ranges. A peering-set object is required by business rules to include either a “peering:” or an “mp-peering:” attribute. One of these must exist, but you cannot include both attributes.

  • “mnt-lower:” – When creating hierarchical sets, more specific object creations can be authorised using the “mnt-lower:”, if present, otherwise the “mnt-by:” mntner objects. For more details see the section 'Set Objects'.

# Description of the ROUTE-SET Object

Below is the object template for the route-set object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
route-set:      mandatory  single     primary/lookup key
descr:          optional   multiple
members:        optional   multiple  
mp-members:     optional   multiple  
mbrs-by-ref:    optional   multiple   inverse key
remarks:        optional   multiple  
org:            optional   multiple   inverse key
tech-c:         mandatory  multiple   inverse key
admin-c:        mandatory  multiple   inverse key
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-lower:      optional   multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A route-set object is a set of route prefixes and not a set of database route objects. Sets can be built with hierarchical names and can also include direct references to other sets. References can also be made indirectly by using the “mbrs-by-ref:” attribute. For more details see the section on Sets.

Where a route-set is expected (e.g. “members:” attribute of the route-set object), an AS number ASx defines the set of routes that are originated by ASx; and an as-set AS-X defines the set of routes that are originated by the ASes in AS-X. A route p is said to be originated by ASx if there is a route object for p, with ASx as the value of the “origin:” attribute.

Description of Attributes Specific to the ROUTE-SET Object

  • “route-set:” – This attribute defines the name of the set which must start with ‘rs-‘. It can be a hierarchical name with components separated by a colon (:). At least one component must be a route-set name. The others can be more set names or AS Numbers. All the set name components of a hierarchical name have to be route-set names. For more details see the section on Sets.
  • “descr:” – A short description related to the object.
  • “members:” – These attributes list the direct members of the set. They can be either address prefixes or ranges, other route-set names, lists of AS Numbers, or as-set names. An address prefix or a route-set name in a members attribute can be optionally followed by a range operator.
  • “mp-members:” – Extends the “members:” attribute to include IPv6 address prefixes.
  • “mbrs-by-ref:” – These attributes can be used in all set objects. They allow indirect population of a set. If this attribute is used, the set also includes objects of the corresponding type (aut-num, route-set or as-set objects for route-set, for example) that are protected by one of these maintainers and whose "member-of:" attributes refer to the name of the set. If the value of a "mbrs-by-ref:" attribute is ‘ANY', any object of the corresponding type referring to the set is a member of the set. If there are no "mbrs-by-ref:" attributes, the set is defined explicitly by the "members:" attributes. For more details see the section 'Set Objects'.
  • “mnt-lower:” – When creating hierarchical sets, more specific object creations can be authorised using the “mnt-lower:”, if present, otherwise the “mnt-by:” mntner objects. For more details see the section 'Set Objects'.

# Description of the RTR-SET Object

Below is the object template for the rtr-set object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
rtr-set:        mandatory  single     primary/lookup key
descr:          optional   multiple
members:        optional   multiple  
mp-members:     optional   multiple  
mbrs-by-ref:    optional   multiple   inverse key
remarks:        optional   multiple  
org:            optional   multiple   inverse key
tech-c:         mandatory  multiple   inverse key
admin-c:        mandatory  multiple   inverse key
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-lower:      optional   multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A rtr-set object defines a set of routers. Sets can be built with hierarchical names and can also include direct references to other sets. References can also be made indirectly by using the “mbrs-by-ref:” attribute. For more details, see the section 'Set Objects'.

Description of Attributes Specific to the RTR-SET Object

  • “rtr-set:” – This attribute defines the name of the set which must start with ‘rtrs-‘. It can be a hierarchical name with components separated by a colon (:). At least one component must be an rtr-set name. The others can be more set names or AS Numbers. All the set name components of a hierarchical name have to be rtr-set names. For more details, see the section 'Set Objects'.
  • “descr:” – A short description related to the object.
  • “members:” – These attributes list the direct members of the set. They can be inet-rtr names, or IPv4 addresses, or other rtr-set names.
  • “mp-members:” – This attribute extends the “members:” attribute to include IPv6 addresses.
  • “mbrs-by-ref:” – These attributes can be used in all set objects. They allow indirect population of a set. If this attribute is used, the set also includes objects of the corresponding type (inet-rtr or other rtr-set objects for rtr-set, for example) that are protected by one of these maintainers and whose "member-of:" attributes refer to the name of the set. If the value of a "mbrs-by-ref:" attribute is ‘ANY', any object of the corresponding type referring to the set is a member of the set. If there are no "mbrs-by-ref:" attributes, the set is defined explicitly by the "members:" attributes. For more details, see the section 'Set Objects'.
  • “mnt-lower:” – When creating hierarchical sets, more specific object creations can be authorised using the “mnt-lower:”, if present. Otherwise, it can be authorised using the “mnt-by:” mntner objects. For more details, see the section 'Set Objects'.

# Descriptions of Secondary Objects

# Description of the AS-BLOCK Object

Below is the object template for the as-block object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
as-block:       mandatory  single     primary/lookup
descr:          optional   multiple  
remarks:        optional   multiple  
org:            optional   multiple   inverse
notify:         optional   multiple   inverse
mnt-lower:      optional   multiple   inverse
mnt-by:         mandatory  multiple   inverse
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

An as-block object delegates a range of AS Numbers to a given RIR. Only the RIPE Database Administrators can create as-block objects. The set of as-block objects covers the full range of 16-bit and 32-bit AS Numbers. These objects prevent anyone other than the RIPE Database administrators from creating aut-num objects in the RIPE Database for AS Numbers that are administered by the RIPE NCC. The authorisation is set up so that anyone can create aut-num objects in the RIPE Database as copies of AS Numbers administered by other RIRs.

The primary key value will be in this format:

‘ASn - ASm' where n and m is a 32-bit unsigned, numbers in the range 0: 4,294,967,295. The values of n and m can be the same representing a block of one AS Number.

Leading zeroes (AS1 - AS065536) are not allowed and will be removed (AS1 - AS65536) by the database software.

Description of Attributes Specific to the AS-BLOCK Object

  • "as-block:" – the range of AS Numbers covered by this block.
  • "descr:" - A short description related to the object.
  • "mnt-lower:" – This attribute controls who is able to create aut-num objects in the RIPE Database for the range of AS Numbers covered by this as-block object. See the section 'Authorisation' for more information.

# Description of the IRT Object

Below is the object template for the irt object. It lists all possible attributes that are allowed in this object type.

Attribute Name   Presence   Repeat     Indexed
irt:            mandatory  single     primary/lookup key
address:        mandatory  multiple  
phone:          optional   multiple  
fax-no:         optional   multiple  
e-mail:         mandatory  multiple   lookup key
signature:      optional   multiple  
encryption:     optional   multiple  
org:            optional   multiple   inverse key
admin-c:        mandatory  multiple   inverse key
tech-c:         mandatory  multiple   inverse key
auth:           mandatory  multiple   inverse key
remarks:        optional   multiple  
irt-nfy:        optional   multiple   inverse key
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-ref:        optional   multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

The irt object was introduced to represent a Computer Security Incident Response Team (CSIRT). This object includes security information for use by CSIRT teams as they communicate with each other.

The irt object may only be referenced from inetnum and inet6num objects to show which CSIRT is responsible for handling computer and network incidents for that address range. Use is made of the hierarchical nature of address space. Any reference in an inet(6)num object to an irt object applies not only to the referencing object but also to all more specific address space. So the more specific objects inherit the reference to the irt object. When querying address space for an irt reference, the query software takes account of this inheritance and queries up the hierarchy looking for the nearest applicable irt object reference. This information is returned when any more specific inet(6)num object is queried. Where irt references are made at multiple points in an address space hierarchy, the closest less specific reference applies.

Adding a reference to an irt object requires authorisation from the maintainer of the irt object. This is handled using the "auth:" attribute of the irt object. Although the reference to an irt object from an inet(6)num object is made using the "mnt-irt:" attribute, it should be clear that the irt object is not a mntner object. The irt object contains contact information and is more similar to a role object than a mntner object.

The contact details provided by an irt object must be business information and must not contain any personal information.

Description of Attributes Specific to the IRT Object

  • "irt:" – This attribute is a single word name for the response team starting with ‘IRT-‘.
  • "address:" - This is a full postal address for the business contact represented by this irt object.
  • "phone:" – This is a phone number for the business contact represented by this irt object. It specifies a telephone number in international format. It must start with a '+' followed by the international country code, area code and number, optionally followed by an extension number.
  • "fax-no:" - This is a fax number for the business contact represented by this irt object.
  • "e-mail:" – This is an email address of a business role, organisation or CSIRT team represented by this irt object.
  • "signature:" – This attribute references a key-cert object in the RIPE Database representing a public key used by the CSIRT team to sign their correspondence.
  • "encryption:" – This attribute references a key-cert object in the RIPE Database representing a public key used to encrypt correspondence sent to the CSIRT team.
  • "auth:" – This attribute defines the authentication scheme to be used to authorise the addition of a reference to this irt object. It has the same authentication options as described in the the sub-section 'Description of the mntner Object'.
  • "irt-nfy:" – This attribute specifies a business email address to be notified when a reference to this irt object is added or removed.
  • "mnt-ref:" – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this irt object in any other object.

# Description of the KEY-CERT Object

Below is the object template for the key-cert object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
key-cert:       mandatory  single     primary/lookup key
method:         generated  single    
owner:          generated  multiple  
fingerpr:       generated  single     inverse key
certif:         mandatory  multiple  
org:            optional   multiple   inverse key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
admin-c:        optional   multiple   inverse key
tech-c:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A key-cert object holds a public key certificate, available by querying the RIPE Database. Anyone who needs to use authorisation in the RIPE Database and who has a private key can store their public key in a key-cert object. It is used with the mntner and irt objects. You cannot create a public/private key pair using the RIPE Database software. You must use some external software to create your keys and then copy the certificate data into the key-cert object.

Currently, the RIPE Database supports two types of keys, PGP and X.509.

The PGP certificate can be used to authorise updates to the RIPE Database and for signing and encrypting correspondence with a CSIRT using an irt object (see the sub-sections 'Description of the irt Object' and ‘Description of the mntner Object' for more details). The "key-cert:" attribute takes the format ‘PGP-nnnnnnnn' where the key-id nnnnnnnn is a hexadecimal number. These keys are compliant with the Open PGP Message Format. PGP keys using an Elliptic Curve algorithm are not currently supported (e.g. Curve 25519, NIST, SECG, ECC Brainpool etc.).

The X.509 certificate can be used to sign and encrypt correspondence with a CSIRT using an irt object. It may work in some circumstances for authorising updates to the RIPE Database but we cannot guarantee this. The "key-cert:" attribute takes the format ‘X509-nnn' where key-id nnn is an integer number starting with 1. If you want to create an X.509 key-cert object you must follow this appendix.

The "method:", "owner:" and "fingerpr:" attributes are all generated by the software. It is not necessary to include these attributes when you create or modify one of these objects. If any of them are supplied, the software will check the values. If the value is wrong for any reason, the software will replace the supplied values with generated values. In this case, a warning will be returned to the user.

In case of performing REST updates using this authentication method Client Certificate Authentication API needs to be used.

Description of Attributes Specific to the KEY-CERT Object

  • "key-cert:" – This attribute specifies the key-id. This is used in "auth:" attributes of the mntner and irt objects.
  • "method:" – This attribute defines the type of the public key. Currently, only PGP and X509 are supported.
  • "owner:" – This attribute specifies the owner of the public key. This information must be supplied when you create the key. The RIPE Database software extracts this information from the key data when the key-cert object is created.
  • "fingerpr:" – This attribute is an identifier of the public key. The RIPE Database software extracts this information from the key data when the key-cert object is created.
  • "certif:" – The value of the public key should be supplied either using multiple "certif:" attributes, or in one "certif:" attribute. In the first case, this is easily done by exporting the key from your local key ring in ASCII-armored format and adding the string "certif:" to the start of each line of the key. In the second case, line continuation should be used to represent an ASCII-armored format of the key. All the lines of the exported key must be included, not forgetting the begin and end markers and the empty line that separates the header from the key body.

# Description of the MNTNER Object

Below is the object template for the mntner object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
mntner:         mandatory  single     primary/lookup key
descr:          optional   multiple  
org:            optional   multiple   inverse key
admin-c:        mandatory  multiple   inverse key
tech-c:         optional   multiple   inverse key
upd-to:         mandatory  multiple   inverse key
mnt-nfy:        optional   multiple   inverse key
auth:           mandatory  multiple   inverse key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-ref:        optional   multiple   inverse key 
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

Objects in the RIPE Database are protected using mntner objects. A mntner object is an anonymous box containing the credentials needed to authorise creation, deletion or modification of any objects that it protects by whomever maintains this data. Currently, these credentials are MD5 passwords or PGP keys or Single Sign-On user names from the RIPE NCC Access system. The syntax also allows for X.509 certificates, but these are not fully implemented throughout the whois software.

Objects are protected by a mntner, if they contain a reference to the mntner in the object. This is done by including a "mnt-by:" attribute. Other "mnt-xxx:" attributes offer hierarchical protection. The "mnt-by:" attribute is mandatory in all object types.

A mntner object can be referenced either as a single mntner or comma-separated list of mntners.

Most users set the "mnt-by:" value in a mntner to reference itself. That makes it maintain itself. But this is not always the case. There are situations where someone wants to control who maintains a set of objects. This can be done by using mnt-a to maintain mnt-b. The object mnt-b contains the credentials to maintain a set of data. These credentials are set up by mnt-a.

To update an object protected by a mntner the authorisation must be passed from one of the "auth:" values in the mntner object referenced in one of the "mnt-by:" attributes of the updated object. This means that the correct credential for one of the "auth:" values must be supplied as part of the update. If an object references more than one mntner in the "mnt-by:" attributes, they act as a logical 'OR'. If the authorisation is passed by any "auth:" value from any of the referenced *mntner objects, then the update will be authorised.

The "mnt-lower:", "mnt-routes:" and "mnt-domains:" attributes all provide for hierarchical authorisation. These also work in a logical 'OR' when multiple values are included in an object. How they are used is described in the object descriptions where these attributes are valid.

For more detailed information about using mntner attributes, see the section ‘Authorisation'.

Description of Attributes Specific to the MNTNER Object

  • "mntner:" – This attribute specifies the name of the mntner object. It should end in ‘-mnt', but the software has never enforced this.
  • "descr:" – A short description related to the object.
  • "upd-to:" – This attribute specifies an email address where a notification will be sent when an attempt to update an object protected by this mntner is unsuccessful due to authorisation failure. If there are multiple attributes, all specified email addresses will receive a direct email to that address.
  • "mnt-nfy:" – This attribute specifies the email address where a notification will be sent when an object protected by this mntner is successfully updated. If there are multiple attributes, all specified email addresses will receive a direct email to that address.
  • "mnt-ref:" – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this mntner object in any other object.
  • "auth:" – This attribute defines an authentication scheme to be used. Any of the current authentication schemes used by the RIPE Database are allowed.

# Description of the ORGANISATION Object

Below is the object template for the organisation object. It lists all possible attributes that are allowed in this object type.

Attribute Name    Presence   Repeat     Indexed
organisation:     mandatory  single     primary/lookup key
org-name:         mandatory  single     lookup key
org-type:         mandatory  single    
descr:            optional   multiple  
remarks:          optional   multiple  
address:          mandatory  multiple 
country:          optional   single 
phone:            optional   multiple  
fax-no:           optional   multiple  
e-mail:           mandatory  multiple   lookup key
geoloc:           optional   single    
language:         optional   multiple  
org:              optional   multiple   inverse key
admin-c:          optional   multiple   inverse key
tech-c:           optional   multiple   inverse key
abuse-c:          optional   single     inverse key
ref-nfy:          optional   multiple   inverse key
mnt-ref:          mandatory  multiple   inverse key
notify:           optional   multiple   inverse key
mnt-by:           mandatory  multiple   inverse key
created:          generated  single
last-modified:    generated  single
source:           mandatory  single

The organisation object provides information about an organisation that has registered an Internet resource in the RIPE Database. This may be a company, non-profit group or individual. It was introduced as a means to link together all of the human and Internet resources related to one organisation.

This object is the central starting point for managing data in the RIPE Database. All your other objects are related to this object. If you manage any aspect of any resource then you should have an organisation object so that other people know who you are, what you maintain and how to contact you.

The organisation object should only contain business information. Even if the organisation is an individual, it should not include any personal information.

Adding references to an organisation object requires authorisation from the organisation. Removing them does not need any authorisation. The maintainer of the organisation object can choose to be notified when any reference is added or removed.

This object is created for new members by the RIPE NCC with "org-type: LIR". These objects are required to include an "abuse-c:" attribute referencing an abuse contact object.

The member organisation objects are partly managed by the RIPE NCC and partly by the member. Because of this joint management, with the RIPE NCC mntner as the "mnt-by:", these objects are locked out of normal updates by members. The parts that the member can change can only be edited in the LIR Portal (opens new window) Object Editors.

Description of Attributes Specific to the ORGANISATION Object

  • "organisation:" – This attribute specifies the ID of an organisation object. When creating an object, you must specify an "AUTO" ID by setting the value of the attribute to "AUTO-1" or "AUTO-1<letterCombination>" ,so the database will assign the ID automatically. The ID will always start with the string ‘ORG-‘ prefix, followed by 2 to 4 letters, digits, a dash and the database source. If deleted, it is not possible to recreate an organisation object with the same ID.
  • “org-name:” – This attribute specifies the name of the organisation that this organisation object represents in the RIPE Database.
  • “org-type:” – This attribute specifies the type of the organisation. It takes one of the following fixed values. Uses can only create organisation objects with the type ‘OTHER'. The rest of the values can only be set by the RIPE NCC.
    • 'IANA' – Only used for Internet Assigned Numbers Authority
    • 'RIR' – Only used for the five Regional Internet Registries
    • 'NIR' – This is for National Internet Registries (there are no NIRs in the RIPE NCC service region, but it is used by APNIC)
    • 'LIR' – This represents all the Local Internet Registries (the RIPE NCC members)
    • 'WHITEPAGES' – A little-used historical idea for people who have a ‘significant' presence in the industry but who don't manage any resources in the RIPE Database.
    • 'DIRECT_ASSIGNMENT' – Used for organisations who have a direct contract with RIPE NCC
    • 'OTHER' – This represents all organisations that do not fit any of the above categories.
  • “descr:” – A short description related to the object.
  • "country:" - This is the country for the organisation. Can only be added, modified or removed by the RIPE NCC if the organisation is referenced from RIPE NCC (jointly) maintained resources.
  • “phone:” – This is a phone number for the business contact represented by this organisation object. It specifies a telephone number in international shorthand. It must start with a '+' followed by the international country code, area code and number, optionally followed by an extension number.
  • “fax-no:” – This is a fax number for the business contact represented by this organisation object.
  • “e-mail:” – This is a business email address for the organisation represented by this object.
  • “geoloc:” – The geolocation coordinates for the resource in decimal degrees notation. Format is latitude followed by longitude, separated by a space. Latitude ranges from [-90,+90] and longitude from [-180,+180].
  • “language:” – Identifies the language as a two-letter code from the ISO 639-1 language code list.
  • “abuse-c:” – This attribute references an abuse contact object. This can only be a role object that contains an "abuse-mailbox:" attribute. Making this reference will remove any query limits for that role object, which must only include business data (no personal information).
  • “ref-nfy:” – This attribute specifies an email address where a notification will be sent when a reference to an organisation object is added or removed. If there are multiple attributes, all specified email addresses will receive a direct email to that address.
  • “mnt-ref:” – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this organisation object in any other object.
  • “address:” – This is a full postal address for the business contact represented by this organisation object.

# Description of the PERSON Object

Below is the object template for the person object. It lists all possible attributes that are allowed in this object type.

Attribute Name    Presence   Repeat     Indexed 
person:           mandatory  single     lookup key
address:          mandatory  multiple  
phone:            mandatory  multiple  
fax-no:           optional   multiple  
e-mail:           optional   multiple   lookup key
org:              optional   multiple   inverse key
nic-hdl:          mandatory  single     primary/lookup key
remarks:          optional   multiple  
notify:           optional   multiple   inverse key
mnt-by:           mandatory  multiple   inverse key
mnt-ref:          optional   multiple   inverse key
created:          generated  single
last-modified:    generated  single
source:           mandatory  single

The person object provides information about a real person. The original intention was that this should only be used for contacts responsible for technical or administrative issues relating to Internet resources registered in the RIPE Database. However, the business model used by many resource holders is to also document End User customers who have been assigned a resource. One of its purposes is defined as a contact database for people who manage resources. It is not easy to distinguish between customers and contacts from the person object, unless it is documented in "remarks:". The person object is the only object in the RIPE Database that should contain any personal information. The "person:" attribute is not the primary key of this object, even though it is the first attribute. The name in the "person:" attribute can be changed by the user.

The person and role objects are the only objects where the first attribute is not (even part of) the primary key of the database object. For these objects the primary key is the "nic-hdl:" attribute. Both these objects ‘share' the use of the primary key. So it is not possible to have a person object with the same “nic-hdl:” value as a role object. The two objects have become almost interchangeable and in most situations either can be used. But it is not possible to convert one into the other. It is not possible to determine if an object is a person or role object from the “nic-hdl:”.

If a person object is deleted, it is not possible to recreate it with the same NIC Handle. This rule was only introduced in 2009. Before that date, the NIC Handles could be re-used. Some caution should be exercised when looking at the history of objects that reference NIC Handles. A person or role object in the database that currently has that NIC handle may not be the same person or contact as the one using this NIC Handle in the historical reference.

Description of Attributes Specific to the PERSON Object

  • "person:" – This attribute specifies the full name of the contact person. It must have at least two words in the name.
  • “address:” – This is a full postal address for the contact represented by this object.
  • “phone:” – This is a phone number for the contact represented by this object. It specifies a telephone number in international format. It must start with a '+' followed by the international country code, area code and number., optionally followed by an extension number.
  • “fax-no:” – This is a fax number for the contact represented by this object.
  • “e-mail:” – This is an email address for the contact represented by this object.
  • “nic-hdl:” – This attribute specifies the ID of a person object. When creating an object, you can specify an "AUTO" ID by setting the value of the attribute to ‘AUTO-1' or ‘AUTO-1<letterCombination>', so the database will assign the ID automatically. If an AUTO ID is requested, it will always end with the source name, e.g. ‘-RIPE'. If you choose the value yourself you can use a two-letter international country code instead of the source at the end or you can just leave out this suffix. For example DW-RIPE, DW-NL and DW are all valid NIC Handles.
  • “mnt-ref:” – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this person object in any other object.

# Description of the POEM Object

Below shows the object template for the poem object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
poem:           mandatory  single     primary/lookup key
descr:          optional   multiple  
form:           mandatory  single     inverse key
text:           mandatory  multiple  
author:         optional   multiple   inverse key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
mnt-by:         mandatory  single     inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A poem object contains a poem that is submitted by a user. It has no operational use and reflects the humorous side of industry representatives.

Description of Attributes Specific to the POEM Object

  • "poem:" – This attribute specifies the title of the poem.
  • “descr:” – A short description related to the object.
  • “form:” – This attribute specifies the identifier of a registered poem type. These are set by the poetic-form objects.
  • “text:” – This attribute specifies the body of the poem. It must be humorous, but not malicious or insulting. It should be written in the style of the "form:".
  • “author:” – This attribute is the NIC Handle of the person who entered the poem.

# Description of the POETIC-FORM Object

Below is the object template for the poetic-form object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
poetic-form:    mandatory  single     primary/lookup key
descr:          optional   multiple  
admin-c:        mandatory  multiple   inverse key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
mnt-by:         mandatory  single     inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A poetic-form object defines the supported poem types. A new ‘poetic form' must be approved by the community ‘style council'. For more details, contact the RIPE Database Working Group or RIPE NCC Customer Services (opens new window).

Description of Attributes Specific to the POETIC-FORM Object

  • "poetic-form:" – This attribute starts with "FORM-". It is followed by the name of an internationally recognised poetic format of humorous writing. For example, limerick or haiku.
  • “descr:” – This attribute describes the style of the poetic form, written in the form style. For example, if it is a FORM-LIMERICK, the description will be written as a limerick.
  • "mnt-by:" - The poetic-form object must contain a single "mnt-by:" attribute. The object must be maintained by RIPE-DBM-MNT.

# Description of the ROLE Object

Below is the object template for the role object. It lists all possible attributes that are allowed in this object type. Required attributes are shown as ‘mandatory'.

Attribute Name  Presence   Repeat     Indexed
role:           mandatory  single     lookup key
address:        mandatory  multiple  
phone:          optional   multiple  
fax-no:         optional   multiple  
e-mail:         mandatory  multiple   lookup key
org:            optional   multiple   inverse key
admin-c:        optional   multiple   inverse key
tech-c:         optional   multiple   inverse key
nic-hdl:        mandatory  single     primary/lookup key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
abuse-mailbox:  optional   single     inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-ref:        optional   multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A role object is similar to a person object. However, instead of describing a single person, it describes a role performed by one or more people. This might be a help desk, network monitoring centre, team of system administrators, etc. A role object is useful since often a person performing a specific function may change while the role itself remains.

The role object should only include business information about the role. It should not contain any personal information, although it can reference person objects. The original intention was that the role object should be used in every other object where contacts are referenced. The person object was only intended to be referenced by the role object. However, business rules were never built into the software to enforce this. As a consequence, the person and role objects have been used inter changeably in almost any situation where contacts are referenced. The "role:" attribute is not the primary key of this object, even though it is the first attribute. The name in the “role:” attribute can be changed by the user.

The person and role objects are the only objects where the first attribute is not (even part of) the primary key of the database object. For these objects the primary key is the “nic-hdl:” attribute. Both these objects ‘share' the use of the primary key. So it is not possible to have a person object with the same “nic-hdl:” value as a role object. The two objects have become almost interchangeable and in most situations either can be used. But it is not possible to convert one into the other. It is not possible to determine if an object is a person or role object from the “nic-hdl:”.

If a role object is deleted, it is not possible to recreate it with the same NIC Handle. This rule was only introduced in 2009. Before that date, the NIC Handles could be re-used. Some caution should be exercised when looking at the history of objects that reference NIC Handles. A person or role object in the database now with that NIC handle may not be the same person or contact as the one using this NIC handle in the historical reference.

References to person objects is optional. A help desk can be represented by a role object. The role contains all the details needed to contact the help desk. It may not be necessary to identify the individuals who make up a team to provide support. Anyone with a problem will contact the help desk and ‘someone' will respond and provide support. Therefore, no person objects need to be referenced by this help desk role object.

Description of Attributes Specific to the ROLE Object

  • "role:" – This attribute specifies a name for the role. As this is business data rather than personal data, the structure of the “role:” value is similar to the “org-name:” in the organisation object.
  • “address:” – This is a full postal address for the role represented by this object.
  • “phone:” – This is a phone number for the role represented by this object. It specifies a telephone number in international shorthand. It must start with a '+' followed by the international country code, area code and number, optionally be followed by an extension number.
  • “fax-no:” – This is a fax number for the role represented by this object.
  • “e-mail:” – This is an email address for the role represented by this object.
  • “abuse-mailbox:” – The role object is the only place that this attribute should be used. It represents the email address to be used when someone wants to report abuse from an Internet resource. A role object with an “abuse-mailbox:” attribute can be referenced by an “abuse-c:” attribute in an organisation object. For more details see the section on Abuse Handling.
  • “nic-hdl:” – This attribute specifies the ID of a role object. When creating an object, you can specify an "AUTO" ID by setting the value of the attribute to ‘AUTO-1' or ‘AUTO-1<letterCombination>', so the database will assign the ID automatically. If an AUTO ID is requested, it will always end with the source name, e.g. ‘-RIPE'. If you choose the value yourself you can use a two-letter international country code instead of the source at the end or you can just leave out this suffix. For example DW-RIPE, DW-NL and DW are all valid NIC handles.
  • “mnt-ref:” – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this role object in any other object.

# Set Objects

Throughout this section we have used the as-set object as an example. The same rules apply to all the different set object types.

# Creating Set Objects

Newly created as-set names must be hierarchical. The hierarchy consists of a series of other as-set names separated by colons (:). Anything to the left of a colon is considered a parent, anything to the right is considered a child. At each stage, the whole of the hierarchy, including the colons, is considered as a single string that forms an object name. The set hierarchy can optionally start with an AS number reference as the top-level parent.

Existing as-set names can be short (i.e. with a name only, e.g. AS-TEST) or hierarchical (i.e. with a name and AS number reference(s), e.g. AS3333:AS-TEST). It is now mandatory to only use hierarchical names to create an as-set object, so that the creation is authenticated by the AS number holder. This restriction does not apply to the other set types.

AS-LIST1:AS-CUST

AS3333:AS-RIPE:AS-APNIC

are both valid AS-SET names

In each case, the whole string is the name of the as-set. So "AS-LIST1:AS-CUST" is a set name, including the colon :. But also "AS-LIST1" is a set name and this set is the parent of the set "AS-LIST1:AS-CUST".

In the second case, "AS3333:AS-RIPE:AS-APNIC" is a set and it is the child of the set "AS3333:AS-RIPE". The 'parent' of this set is AS3333, which is an aut-num object and not a set.

For each new (child) set object in a hierarchy, the immediate parent object must exist at the time of creating the new child set object. This is everything to the left of the last colon in the new child set object name, taken as a single (hierarchical) object name. Only one level of parent is checked. If any of the higher levels of parent objects have been deleted, it will not affect the creation of the new child object. The parent is only needed for authorisation.

Therefore, if we were to create a new set "AS3333:AS-RIPE:AS-APNIC:AS-CUSTOMERS" then the immediate parent object, "AS3333:AS-RIPE:AS-APNIC" must exist to authorise the new set creation. However, it does not matter if higher parent objects still exist, like "AS3333:AS-RIPE".

If an AS number is the first element in the hierarchical set name (the top-level parent) then the corresponding aut-num object must exist in order to create the next level in the hierarchy as this is the parent object. However, it is only needed for authorisation.

Therefore, to create the set "AS3333:AS-RIPE", the aut-num object "AS3333" must exist to provide authorisation.

If an AS number appears anywhere else in the set name hierarchy it is treated as part of a set name and the aut-num object does not need to exist. You cannot have AS numbers as the first two levels in the name hierarchy. The second level could not be created, as there must be at least one element starting with "AS-" in the set name.

So "AS3333:AS-RipeOriginAS1" is a valid set name but AS1 is not an aut-num object, it is simply part of this set name.

"AS3333:AS1" is not valid as it does not contain an "AS-" string defining an as-set name.

"AS3333:AS1:AS-CUSTOMERS" is also not valid as it would require "AS3333:AS1" to exist as the parent to authorise the creation of this set.

Only hierarchical AS-SET objects can be created. If the set name is a single as-set (starting with AS- and with no colons) then it is considered to be non-hierarchical,

The as-set object can also list members of the set with a "members:" attribute. The as-set and aut-num objects referenced in a "members:" attribute do not need to exist.

# Modifying and Deleting Set Objects

Any intermediate set can be deleted from the hierarchy. This includes everything from the highest-level parent (which is a non-hierarchical as-set or aut-num object) to the lowest-level parent (which is everything to the left of the last colon in the name of the lowest level child object).

In the case of "AS3333:AS-RIPE:AS-APNIC:AS-CUSTOMERS", it is possible to delete any of these individual objects:

"AS3333"

"AS3333:AS-RIPE"

"AS3333:AS-RIPE:AS-APNIC"

They can also be recreated, as the check is only that the immediate parent object (to the left hand side of the last colon of the object name being created) exists. It does not check any higher-level parents or any existing child objects (right hand side of the colon). If several intermediate parents have been deleted, they can only be recreated in the correct sequence, starting with the highest level.

In the case of "AS3333:AS-RIPE:AS-APNIC:AS-CUSTOMERS", suppose we delete: "AS3333" and "AS3333:AS-RIPE:AS-APNIC" but not "AS3333:AS-RIPE". We can recreate "AS3333:AS-RIPE:AS-APNIC" as its parent object is "AS3333:AS-RIPE" and this object still exists. Authorisation is required from the existing parent object to recreate the child object.

There is an issue if the top-level parent is an as-set object and it is deleted. Suppose we have the set "AS-RIPE:AS3333:AS-RIPE:AS-CUSTOMERS" and all the parents exist. (Note that this is subtly different to the set object above, as the top-level parent of this set is a set object, not an aut-num object.) We can delete the top-level parent set "AS-RIPE". The remaining sets "AS-RIPE:AS3333" to "AS-RIPE:AS3333:AS-APNIC:AS-CUSTOMERS" are still valid. However, anyone can now recreate the deleted top-level parent set "AS-IX". This has no parent and therefore requires no hierarchical authorisation. This only becomes a problem if the next-level child set is deleted and the user tries to recreate it. Authorisation is now required from the new parent set that is owned by someone else.

If there are any aut-num objects with "member-of:" attributes referencing an as-set object then this as-set object cannot be deleted. If the "mbrs-by-ref:" attributes are removed from the as-set object, it still cannot be deleted if there are any existing "member-of:" references to it.

A "mbrs-by-ref:" attribute can be removed from an as-set object even if there are "member-of:" references to this as-set object. The "mbrs-by-ref:" attribute is only needed for validation of an object's claim to membership of the set. A modification to an aut-num object with a "member-of:" reference to this as-set object will fail unless the "member-of:" reference is removed from the aut-num object.

The as-set object can be deleted if it has "members:" listed in the object that do exist. However, if there are "member-of:" references to the set in other objects, this set object cannot be deleted, even if you first remove the "mbrs-by-ref:" attributes.

# The ROUTE-SET Object

  • The same rules apply to the route-set object as to the as-set object but the "member:" attributes include route and route6 objects instead of aut-num object.
  • "member:" attributes include other route-set objects
  • The set name must have an element starting with 'RS-'
  • The set name can also include AS numbers

# The RTR-SET Object

  • The same rules apply to the rtr-set object as to the as-set object but the "member:" attributes include inet-rtr objects instead of aut-num objects.
  • "member:" attributes also include other rtr-set objects
  • The set name must have an element starting with 'RTRS-'
  • The set name can also include AS numbers

# The PEERING-SET Object

  • The same rules apply to the peering-set object as to the as-set object
  • There are no "member:" attributes
  • "peering:" and "mp-peering:" attributes also include other peering-set objects
  • There are no referential integrity checks on the values of the "peering:" and "mp-peering:" attributes. Objects referenced in these attributes do not need to exist on creation and can be deleted later
  • The set name must have an element starting with 'PRNG-'
  • The set name can also include AS numbers

# The FILTER-SET Object

  • The same rules apply to the filter-set object as to the as-set object
  • There are no "member:" attributes
  • "filter:" and "mp-filter:" attributes also include other filter-set objects
  • There are no referential integrity checks on the values of the "filter:" and "mp-filter:" attributes. Objects referenced in these attributes do not need to exist on creation and can be deleted later
  • The set name must have an element starting with 'FLTR-'
  • The set name can also include AS numbers

# Tables of Query Types Supported by the RIPE Database

# Table 1: Queries Using Primary and Lookup Keys

Lookup key(s) Objects Returned
IPv4 address prefix, range or single address inetnum, route objects with exact match on the specified key. If the exact match does not exist, the objects with the smallest less specific match are returned. When you specify a single address, an inet-rtr object whose "ifaddr:" attribute matches the query argument is also returned..
IPv6 address prefix or single address inet6num, route6 objects with exact match on a specified key. If the exact match does not exist, the objects with the smallest less specific match are returned. If you specify a single address, an inet-rtr object whose "interface:" attribute matches the query argument is also returned.
Network name inetnum and inet6num objects whose "netname:" attribute matches the query argument.
AS Number aut-num object whose "aut-num:" attribute matches the query argument and an as-block object with the range containing the aut-num object, if it exists.
AS Number – AS Number as-block object whose primary key defines a range that exactly matches or fully contains the range specified in the query argument.
Domain/reverse domain domain and inet-rtr objects whose primary keys match the query argument.
IRT name irt object whose primary key matches the query argument.
Person or role name person and role objects whose "person:" or "role:" attributes contain the name specified in the query argument.
Set name A as-set, filter-set, peering-set, route-set or rtr-set whose primary key matches the query argument.
NIC handle person or role object whose "nic-hdl:" attribute matches the query argument.
Maintainer name mntner object whose primary key matches the query argument.
Organisation name All organisation objects with an "org-name:" containing the name specified in the query.
Organisation ID organisation object whose primary key matches the query argument.
Key-cert key-cert object whose primary key matches the query argument.
Poem poem object whose primary key matches the query argument.
Poetic form poetic-form object whose primary key matches the query argument.
Route/route6 Exact match or less specific route/route6 object and exact match or less specific inetnum/inetnum6 object
Router interface address inet-rtr with an "ifaddr:" containing the IPv4 or IPv6 address specified in the query
Email person, role and organisation objects with a matching "email:"

# Table 2: Queries For IP Networks table

Flag Objects Returned or Effect
-x
--exact		 Only inetnum, inet6num, route, route6 or domain objects that exactly match the prefix. If no exact match is found, no objects are returned.
-M
--all-more		 All level more specific inetnum, inet6num, route, route6 or domain objects, excluding exact matches.
-m
--one-more		 First level more specific inetnum, inet6num, route or route6 objects, excluding exact matches.
-L
--all-less		 All level less specific inetnum, inet6num, route, route6 or domain objects, including exact matches.
-l
--one-less		 First level less specific inetnum, inet6num, route, route6 or domain objects, excluding exact matches.
-d
--reverse-domain		 When used with -x, -M, -m, -L and -l flags, both address and route object types and domain object types are returned.
-c
--irt		 The smallest, less specific inetnum or inet6num object found encompassing the range specified in the query argument. Also any irt objects found referenced from the returned inetnum or inet6num, or referenced from the first less specific inetnum or inet6num to the returned object that has such a reference.
-b
--abuse-contact		 Provides a brief output of ranges with associated abuse contact information.

# Table 3: Inverse Queries

Flag Argument (Alternative Form) Lookup Key(s) Objects Returned
-i am (abuse-mailbox) Email Objects whose "abuse-mailbox:" attribute matches the query argument.
-i au (abuse-c) NIC handle Objects whose "abuse-c:" attribute matches the query argument.
-i ac (admin-c) NIC handle Objects whose "admin-c:" attributes match the query argument.
-i pc (ping-hdl) NIC handle route(6) objects whose "ping-hdl:" attribute match the query argument.
-i ah (author) NIC handle poem object whose "author:" attribute match the query argument.
-i at (auth) PGP key mntner objects whose "auth:" attribute matches the query argument. Please note that encrypted passwords and SSO usernames cannot be inverse- searched, but only PGPKEY and X509 certicates.
-i fp (fingerpr) Fingerprint key-cert objects whose "fingerpr:" attribute matches the query argument.
-i pn (person) NIC handle Objects whose "admin-c:", "tech-c:", "zone-c:" or "author:" attribute matches the query argument.
-i iy (irt-nfy) Email irt objects whose "irt-nfy:" attribute matches the query argument.
-i la (local-as) AS Number inet-rtr objects whose "local-as:" attribute matches the query argument.
-i mi (mnt-irt) IRT name inetnum and inet6num objects whose "mnt-irt:" attribute matches the query argument.
-i mr (mbrs-by-ref) Maintainer name Set objects (as-set, route-set and rtr-set) whose "mbrs-by-ref:" attribute matches the query argument.
-i mo (member-of) Set name Objects whose "member-of:" attribute matches the query argument and their membership claim is validated by the "mbrs-by-ref:" attribute of the set. Absence of the "mbrs-by-ref:" attribute means that the membership is only defined by the "members:" attribute of the set.
-i mb (mnt-by) Maintainer name Objects whose "mnt-by:" attribute matches the query argument.
-i md (mnt-domains) Maintainer name Objects whose "mnt-domains:" attribute matches the query argument.
-i ml (mnt-lower) Maintainer name Objects whose "mnt-lower:" attribute matches the query argument.
-i mn (mnt-nfy) Email mntner objects whose "mnt-nfy:" attribute matches the query argument.
-i mu (mnt-routes) Maintainer name aut-num, inetnum, route and route6 objects whose "mnt-routes:" attribute matches the query argument.
-i mz (mnt-ref) Maintainer name Returns all objects whose "mnt-ref:" attribute matches the query argument.
-i ny (notify) Organisation objects with a matching "ref-nfy:" Objects whose "notify:" attribute matches the query argument.
-i ns (nserver) Domain name or single address domain objects whose "nserver:" attribute matches the query argument.
-i or (origin) AS Number route and route6 objects whose "origin:" attribute matches the query argument.
-i og (org) Organisation ID Objects whose "organisation:" attribute matches the query argument.
-i tc (tech-c) NIC handle Objects whose "tech-c:" attribute matches the query argument.
-i dt (upd-to) Email mntner objects whose "upd-to:" attribute matches the query argument.
-i zc (zone-c) NIC handle Objects whose "zone-c:" attribute matches the query argument.
-i rn (ref-nfy) Email Objects whose "notify" attribute matches the query argument.
-i fr (form) Poetic form Poetic form objects whose matches the query argument.
-i sp (sponsoring-org) Organisation ID Objects whose "sponsoring-org:" attribute matches the query argument.

# Table 4: Query Support For Tools

Flag Lookup Key(s) Effect
-F --brief Produces output using shorthand notation for attribute names. Produces slower responses.
-K --primary- keys Requests that only the primary keys of an object be returned. The exceptions are set objects, where the "members:" attributes will also be returned. This flag does not apply to person and role objects.
-k --persistent- connection (optional normal query) Requests a persistent connection. After returning the result, the connection will not be closed by the server and a client may issue multiple queries on the same connection. The server implements a "stop-and-wait" protocol, whereby no next query can be sent before receiving a reply for the previous one. Use RIPE Whois client to be able to send queries in batch mode. Except the first -k query, -k without an argument closes the persistent connection.

# Table 5: Miscellaneous Queries

Flag Argument Effect
-r --no- referenced Switches off lookups for referenced contact information after retrieving the objects that match the lookup key.
-B --no- filtering Switches off default filtering of objects.
-G --no- grouping Switches off grouping of associated objects.
-T --select- types Comma separated list of object types, no white space is allowed Restricts the types of primary objects to lookup in the query.
-a --all- sources Specifies that the server should perform lookups in all available sources. See also -q sources query. `
-s --sources Comma separated list of sources, no white space is allowed. Specifies which sources are to be looked up when performing a query and in which order.
--list- versions
--diff- versions Version number Indicates the difference between given historical versions of the object.
--show- version Version number Returns the historical version of the object with this index number. Must use --list- versions to get the index numbers.
--types Lists available RPSL object types.
--version Displays the current software version.
--list- sources Returns the current set of sources along with the information required for mirroring.
--resource Search all sources for the specified resource and returns the authoritative one. Placeholders are omitted.
--show- personal Include referenced person and role objects in results.
--no- personal Filter referenced person and role objects from results. A client can be blocked for excessive querying of these objects.

# Table 6: Informational Queries

The following notations are used in this table:

<object-type> means full or abbreviated name;

Flag Argument Effect
-q sources Returns the current set of sources along with the information required for mirroring.
-q version Displays the current version of the server.
-q types A list of all available object types.
-t --template Object type Requests a template for the specified object type.
-v --verbose Object type Requests a verbose template for the specified object type.
-V --client Client type Sends information about the client to the server.

# Types of Queries

Throughout this section, the query flags described allow specific types of queries. For command-line queries and for API searches, these flags can be used directly. For web queries, some of the flags can be selected by ticking appropriate check boxes, others can be typed as part of the query string. There are some flags that make no sense with web queries and streamed output, for example -k for a persistent connection or –G to turn off grouping, as grouping is disabled by default in the streamed output.

# Abuse Contacts

There are many attributes in objects within the RIPE Database containing e-mail addresses. These addresses cover a number of functions. A growing concern to engineers and administrators that maintain networks is receiving spam and abuse complaints that are sent to every e-mail address displayed. This will get the message to the right person,but it also causes more spam and abuse to people who are not responsible for solving these problems.

To solve this issue, an "abuse-c:" attribute is available in the organisation object. This optional attribute references a role object which is required to contain an "abuse-mailbox:" attribute. Any Internet resource object (inetnum, inet6num, aut-num) that references this organisation object is then "covered" by this abuse email address.

By default, any query for an Internet resource object will return the related abuse email address. This appears in the query output as a comment line (starting with the % 'characters).

There is also a -b query flag to find the "abuse-mailbox:" attributes for any specific range. It returns the resource primary key with any abuse contact email address found. Also the prefix of any corresponding route or route6 objects, followed by the "abuse-mailbox:" attributes.

If no abuse contact is found in any encompassing objects then no object summaries will be returned.

A complaint will not be handled any quicker by copying your message to any other e-mail address found in the database.

The -b query flag cannot be used with many other query flags.

# Access Control for Queries

The control mechanism is based on the amount of contact information (contained in person and role objects) that is returned because of any queries made. Limits are based on the IP address of a whois client sending queries to the database server. Sometimes an IP address may be acting as a proxy and submitting queries on behalf of other IP addresses (for example, a webserver providing an interface to the RIPE Database). The database server provides a facility for such proxy clients that allows accounting to be based on the IP address of the clients using the proxy to query the RIPE Database and not on the IP address of the proxy server. This is done using the -V flag as follows:

-V <version>,<ipv4-address>

where

  • <version> is a client tag that usually represent the software version that the proxy uses
  • <ipv4-address> is the IPv4 address of the client that queries the database using the proxy

Not all users can use this -V flag. You must contact RIPE Database Administration and tell us why you need this facility. If we approve your request, we will add the IP address of the proxy server to an access control list. You can then use the -V flag, but only from your stated IP address.

Attempting to use the -V flag without approval may result in permanent denial of access to the RIPE Database. This denial of access will apply to the IP address that submits the query.

We restrict access to stop people using the RIPE Database to collect excessive amounts of contact data. If the amount of contact data returned by all your queries in a day (defined by UTC) exceeds defined limits, a temporary block on access is applied to that IP address. This block will be automatically released at midnight (UTC) to allow querying to continue. There is also a limit on the number of times an IP address can be blocked and recover. When this limit is reached, that IP address is permanently blocked from accessing the RIPE Database. This permanent block will not be automatically removed. The limits are defined in the RIPE Database Acceptable Use Policy

There are many reasons why you could find yourself in this position. One is that you are mining the RIPE Database for contact data to use for non-agreed purposes. In this case, the denial of access is justified and your IP address will remain on the blocked list. However, there may be other reasons. Queries for object types other than person and role objects return contact information by default. Using the -r or --no-referenced flag to prevent contact data being included in your query results can turn of this default. Alternatively, you may have an error in a script that runs automatically, retrieving contact data that you did not know about. If you believe there was a genuine error or mistake that led to the permanent block, you need to contact RIPE Database Administration. Explain the error and tell us what steps you have taken to stop it happening again. RIPE Database Administration will decide whether to remove the block. It will remain on record that this IP address has been permanently blocked and unblocked. If another permanent block occurs, we will be less likely to consider removing it a second time.

Each time a person or role object is retrieved, a counter increases. When it reaches the limit defined in the AUP, the query execution is aborted and the connection is terminated, displaying an error message to the client (see "Access errors" in Appendix C,RIPE Database Query Server Response Codes and Messages). Also a count of denials increases. Retrieving any other object type does not affect these counters.

Any role object used for abuse contacts with an "abuse-mailbox:" attribute is exception to this rule. No accounting is done on these objects.

There is also a limit on the number of simultaneous connections from a host. When this limit is reached, further connections from the same host are refused.

If we block your access, you will not be able to query for any object types. We will not just block your access to contact date alone.

# Filtering the Query Response

A filtering process restricts some data from the default query response. This applies to email contact data. When a user is searching for abuse contact data, they sometimes take all email addresses found in all objects in the query response. This may include the correct address. However, it often also includes many other addresses for people who are not responsible for handling such complaints.

To help overcome this issue, some attributes containing email addresses are filtered out of the default response. One exception to this is where a role object includes an "abuse-mailbox:" attribute. The abuse email address is never filtered. If you include the -B or --no-filtering query flag then the response will not be filtered

When any attribute has been filtered out of an object in the query response, a "Note:" is added to the response header to warn the user. In addition, the "source:" attribute of each filtered object in the response will have a comment added to the end of the line saying "# Filtered". If this filtered output is cut and pasted into an update message, including this end of line comment on the "source:" attribute, the update will be rejected for any filtered object. This is because some mandatory attributes may be missing and the "source:" will not be recognised. Filtered output can therefore not be accidentally used for updates.

Any "auth:" attribute of mntner objects apart from those which reference to key-cert objects are always filtered when these objects are queried. This filtering cannot be turned off with any query flags. The only way to see an unfiltered mntner object is to authenticate using a password or SSO credential that matches an auth: attribute on the mntner.

# Getting All the Members of Set Objects

In RPSL, an object can be a member of a set object in two ways.

  • You can list objects in a "members:" attribute in the set object.

  • You can use the "member-of:" attribute. You can use this in route, route6, aut-num and inet-rtr object types. The value of the "member-of:" attribute identifies a set object that this object wants to be a member of.

However, just specifying "member-of:" is not enough. The referenced set object must also have a "mbrs-by-ref:" attribute. This lists the maintainer of the object that wants to be a member of the set. This means that the set owner must validate the membership claim of an object with a "member-of:" attribute. It does this by matching the "mnt-by" line of the object with one of the maintainers in the "mbrs-by-ref:" attributes of the set object.

# Grouping the RIPE Database Output

There are two ways to order the objects in a query response.

One way is for the first part of the response to list the objects that are the direct results of the query. Then, the second part of the response lists all the secondary objects that are directly referenced from the objects in the first part of the response, like organisation and person. If any of these secondary objects are referenced by more than one of the returned objects, it will only be listed once in the response.

$ whois  -i mb aardvark-mnt
mntner:         AARDVARK-MNT
admin-c:        DW6465-RIPE
tech-c:         DW-RIPE
mnt-by:         AARDVARK-MNT
key-cert:       X509-1
admin-c:        DW6465-RIPE
tech-c:         DW6465-RIPE
mnt-by:         AARDVARK-MNT
org:            ORG-EIP1-RIPE
organisation:   ORG-EIP1-RIPE
mnt-ref:        ripe-ncc-hm-mnt
tech-c:         TCP-RIPE
mnt-by:         RIPE-NCC-HM-MNT
abuse-c:        AR13455-RIPE
person:         Denis Walker
nic-hdl:        DW-RIPE
person:         Denis Walker
nic-hdl:        DW6465-RIPE
$ whois  -i mb aardvark-mnt
% Information related to 'AARDVARK-MNT'
mntner:         AARDVARK-MNT
admin-c:        DW6465-RIPE
tech-c:         DW-RIPE
person:         Denis Walker
nic-hdl:        DW-RIPE
person:         Denis Walker
nic-hdl:        DW6465-RIPE
% Information related to 'X509-1'
key-cert:       X509-1
admin-c:        DW6465-RIPE
tech-c:         DW6465-RIPE
mnt-by:         AARDVARK-MNT
org:            ORG-EIP1-RIPE
organisation:   ORG-EIP1-RIPE
mnt-ref:        ripe-ncc-hm-mnt
tech-c:         TCP-RIPE
mnt-by:         RIPE-NCC-HM-MNT
abuse-c:        AR13455-RIPE
person:         Denis Walker
nic-hdl:        DW6465-RIPE

The default response is grouped. If you include the -G or --no-grouping query flag then the output will not be grouped.

# Historical Queries

The RIPE Database holds a lot of historical data going back over ten years. This can be of use operationally and statistically. It is possible to query the history of operational data objects that still exist. The available historical data stretches back to the most recent time that the object was (re-)created. If an object is created, modified several times, deleted, recreated and modified again, the available data for this object will cover the most recent creation and modification, as well as the date that it was deleted. This policy of not showing historical data for deleted objects is subject to change.

For the available historical data, a list can be requested showing the versions with a timestamp. Each of these versions of the object can then be queried. Also, a diff is available between versions. These historical query flags do not have a short format and can only be used from the command line. These query flags are not available through either the web query form or the RESTful API.

All timestamps use the UTC timezone.

Any attribute containing email addresses is filtered out from the query response. These may no longer be related to the object and, also, the owner of the email address may not want to receive any further communications concerning this data. It is also not possible to query for historical personal data objects i.e. person and role.

“—list-versions”

The response to this is a list of available object versions with a timestamp. This timestamp is the date that an update was processed by the database server to create this version of the object. It is a system-generated timestamp; it is not information supplied by the user. The format looks like this:

$ whois --list-versions 193.0.0.0 - 193.0.7.255
% Version history for INETNUM object "193.0.0.0 - 193.0.7.255"
% You can use "--show-version rev#" to get an exact version of the object.
% This object was deleted on 2003-03-17 13:03
rev#  Date              Op.
1     2003-03-17 13:15  ADD/UPD
2     2003-04-12 08:32  ADD/UPD
3     2003-05-22 13:20  ADD/UPD
4     2004-10-22 14:43  ADD/UPD
5     2004-10-31 03:08  ADD/UPD
6     2006-02-21 16:46  ADD/UPD
7     2009-12-02 13:27  ADD/UPD
8     2009-12-02 13:49  ADD/UPD
9     2010-03-17 15:00  ADD/UPD
10    2011-02-17 12:11  ADD/UPD
11    2013-03-19 16:24  ADD/UPD

The specified primary key must be an exact match for an object. In the above example, you cannot request the history for 193.0.7.35. Even though this is part of the above range, these queries work on objects not hierarchies. Although this object existed prior to 2003-03-17, that part of the history is not available as it was deleted on this date.

“—show-version #n”

This query will return one version of an object from the history list. Taking version #10 from the above example, the query response will look like this:

$ whois --show-version 10 193.0.0.0 - 193.0.7.255
% Version 10 of object "193.0.0.0 - 193.0.7.255"
% This version was a UPDATE operation on 2011-02-17 12:11
% You can use "--list-versions" to get a list of versions for an object.
inetnum:        193.0.0.0 - 193.0.7.255
netname:        RIPE-NCC
descr:          RIPE Network Coordination Centre
descr:          Amsterdam, Netherlands
remarks:        Used for RIPE NCC infrastructure.
country:        NL
admin-c:        JDR-RIPE
admin-c:        BRD-RIPE
tech-c:         OPS4-RIPE
status:         ASSIGNED PI
source:         RIPE # Filtered
mnt-by:         RIPE-NCC-MNT
mnt-lower:      RIPE-NCC-MNT

“--diff-versions version-number:version-number”

This query will return the textual difference between two versions from the history list. Checking the difference between versions 10 and 11 in the example above will look like this:

$ whois --diff-versions 10:11 193.0.0.0 - 193.0.7.255
% Difference between version 10 and 11 of object "193.0.0.0 - 193.0.7.255"
@@ -3,2 +3,3 @@
descr:          RIPE Network Coordination Centre
+org:            ORG-RIEN1-RIPE
descr:          Amsterdam, Netherlands

We can see that a reference to an organisation object was added. If you reverse the version numbers, then the logical diff will show that the reference to an organisation object was removed when looking back over the timeline of changes, from more recent to older changes:

$ whois --diff-versions 11:10 193.0.0.0 - 193.0.7.255
% Difference between version 11 and 10 of object "193.0.0.0 - 193.0.7.255
@@ -3,3 +3,2 @@
descr:          RIPE Network Coordination Centre
-org:           ORG-RIEN1-RIPE
descr:          Amsterdam, Netherlands

# Inverse Queries

Inverse queries search for object's inverse keys that are supplied as an argument to a query. The query flag -i (or --inverse) must also be specified with appropriate query flag arguments. Inverse keys are defined in the templates of the RIPE Database objects. (See section 'RPSL Object Types' for more details.) These templates can be listed by querying the RIPE Database. See section 'Accessing the Object Templates' for more details. See Table 3: Query Flag Arguments to the “-” Query Flag and the Corresponding Inverse Keys

By performing an inverse query, the user requests all objects to be returned from the database that contain the specified query argument in the attribute(s) specified in the query flag arguments.

If you are looking for this... ...then type this in the query interface:
All objects where contact person (or role) is XY-RIPE -i person XY-RIPE
All objects that are protected by XY-MNT -i mnt-by XY-MNT
All objects that have XY-MNT as mnt-lower -i mnt-lower XY-MNT
All objects that have XY-MNT as mnt-routes -i mnt-routes XY-MNT
All objects that have ORG-XYZ-RIPE as their organisation object -i org ORG-XYZ-RIPE
All route/route6 objects that are originated by ASx -i origin ASx

Example:

whois -i admin-c <nic-handle>

will return all objects where the "admin-c:" attribute contains the <nic-handle> specified as the query argument.

You can specify several query flag arguments to request searches against several attributes in objects. If you want to do this, the query flag arguments should be entered as a comma-separated list with no white spaces. All the attributes searched must contain the same type of value. In other words, all the values must be maintainers or nic-handles or one of the other values listed in the appendix section on Supported Queries.

Example:

whois --inverse mb,mnt-lower <mntner name>

will return all objects where the "mnt-by:" or the "mnt-lower:" attributes contain the <mntner name> specified as the query argument.

Example:

An inverse query can be used to search for references to a person or role in objects. To find a person or role you could search for matching "admin-c", "tech-c", "abuse-c", "zone-c" attributes, however you need to specify all attributes separately. Instead you can specify "person" or "pn" to search all such attributes.

whois -i admin-c,tech-c,abuse-c,zone-c <person value>

will return the same results as

whois -i pn <person value> or whois -i person <person value>

Finding the references for a person is very useful when someone leaves the company and you want to delete all the registers from this person. Note that you can also specify a role instead of a person:

whois -i pn <role value>

# IRR Toolset Support

The IRRToolset is a third-party suite of routing policy analysis tools. Some of the tools in this set access Routing Registry servers through an authorisation whois interface.

The RIPE Database server includes support for these query types. This section describes the additions to the RIPE Database user interface that allow it to support the IRRToolset. The required queries are:

  • Return the prefixes of all route and route6 objects with a specified origin – whois -Ki origin<asn>
  • Return only the primary keys of the route and route6 objects, not full objects – whois –KTroute,route6 <prefix>
  • Return the prefixes of all route and route6 objects referenced in a given route-set – whois –K <route-set>
  • Return all the members (aut-num or as-set object) of a specified as-set. This returns only the "members:" attributes, not the full object – whois –K <as-set>
  • Optionally, include support for expansion of the previous query, if the returned value contains references to as-sets, so that the result contains only a list of aut-num objects.

The RIPE Database server does not support this and it is up to the client to perform the expansion. The IRRToolset currently does the expansion.

  • Return route and route6 objects that exactly match a specified prefix - whois –BGxTroute,route6 193.0.0.0/21
  • Return route and route6 objects that exactly match a specified prefix (as above), but return only the "route:" or "route6:" attributes prefix - whois –KxTroute,route6 193.0.0.0/21

See Table 4: Query Support For Tools

# More and Less Specific Lookups For Reverse Domains

The RIPE Database supports IP network queries including the -x, -M, -m, -L and -l functionality for reverse delegation domains. If you want to include reverse delegation domains in the query response when using the more or less specific or exact match query flags. You must also include the -d query flag, this will return all domain objects for the address range.

Please note that there is no hierarchy allowed with reverse domain objects. These queries work on the address space hierarchies and return the corresponding domain object, if found, for any address space objects in the query response.

# Other Query Flags

# The “-T” (“--select-types”) Query Flag

This query flag restricts the type of the objects returned to those specified. The query flag argument is a comma-separated list of object types. A space after "T" is optional but the list cannot contain any spaces.

# The “-K” (“--primary-keys”) Query Flag

The -K (--primary-keys) query flag returns only the primary keys of each object in the query response.

There are some exceptions to this:

  • With set objects, the "members:" attributes will also be returned.
  • With route and route6 objects both the prefix and the "origin:" attribute are returned as these jointly provide the primary key.
  • No information is returned for person, role or organisation objects.

# The “-t” (“--template”) Query Flag

The -t (--template) query flag returns a template of the specified object type as shown for each object in the section RPSL Object Types.

# The “-v” (“--verbose”) Query Flag

The -v (--verbose) query flag returns a verbose description of the specified object type as shown for each object in the section RPSL Object Types.

# The “-q” Query Flag

The RIPE Database server supports the retrieval of certain information about itself and the data sets served, using a -q query flag.

The -q query flag requests the server to reply with information about the system setup. It does not return any information extracted from any of the databases that it serves. This query flag takes a single argument, which has three possible values:

  • Version (usage: -q version). This will display version information for the server software
  • Types (usage: -q types). This will list all the object types recognised by the RIPE Database
  • Sources (usage: -q sources). This will list all available sources. That is, the local RIPE Database and all the mirrored databases

# The “-a” (“--all-sources”) Query Flag

The -a (--all-sources) query flag requests that the server searches all the sources available to it and the response will include any output found from any of the available sources. These are the sources listed by using the –q sources query.

# The “-s” (“--sources”) Query Flag

The -s (--sources) query flag requests that the server searches all the sources specified and the response will include any output found from any of these sources. The available sources are the sources listed by using the –q sources query. The argument to this flag can be a comma-separated list of sources. They will be queried in the order specified by the user. Search other mirrored databases, not only the RIPE Database.

# The “-S” (“--resources) Query Flag

The -S (--resources) query flag search in other mirrored databases, such as: RIPE-GRS or ARIN-GRS, not only the RIPE Database. For example: whois -S ARIN-GRS 193.201.1.1

# The “-F” (“--brief”) Query Flag

The “-F” (“--brief”) query flag changes the format of the returned objects. The attribute names are represented in a short hand notation. For example, "person:" becomes "*pn:". Using the –F query flag includes the non-recursive action of the –r query flag

# The “--valid-syntax” and “--no-valid-syntax” Query Flags

Over time, the syntax of database objects changes. The existing data is not always updated when these changes occur. Therefore, there are many objects in the RIPE Database with invalid syntax according to current rules. These query flags filter the objects in the query response. Either those objects with valid syntax, or those without valid syntax, will be returned in the response depending on the choice of flag.

# The “-c” (“--irt”) Query Flag

The “-c” (“--irt”) query flag can only be used with queries for address space objects. The appropriate address space object for this query is returned in the query response. The query software then searches up the address space hierarchy (moving through the less specific objects) until an address space object is found that references an irt object, and then the referenced irt object is included in the query response. The default behaviour is not to return any referenced irt object.

# The “-C” (“--no-irt”) Query Flag

The “-C” (“--no-irt”) query flag turns off the behaviour given with the “-c” query flag. Related irt objects are not returned by default.

# The “-Z” (“--charset”) Query Flag

The "-Z" ("--charset") query flag specifies which character set the client expects. The default is latin-1 (ISO-8859-1) encoding.

# Persistent Connections and Keeping State

If you are carrying out batched queries, your database client can request a persistent connection. The server will not close this connection after sending a reply to your client. This avoids having to set up a new TCP connection for every query.

The client can request this by sending the -k or --persistent-connection query flag to the server. This flag may be sent without a query argument to start the connection. Or it may be included as a query flag with the first query.

During a persistent connection, the server operates a "stop-and-wait" protocol. This means that the next query cannot be sent until the reply has been received to the previous query. If you want to be able to send queries in batch mode, you must use a third-party tool, for example netcat or telnet, or the whois client with the file name ripe-whois-client-3.2.2.tar.gz that can be downloaded and compiled. The default whois client that is available with most operating systems may not allow this.

To exit a persistent connection, send the -k or --persistent-connection flag with no query argument or an empty query (\n) to the server. The connection will also time out after a period of inactivity.

# Queries for Autonomous Systems

AS numbers can be either 32-bit or 16-bit. They are both described by a 32-bit number.From the point of view of the RIPE Database there is no difference. The difference is mainly historical.

# Queries for IP Networks

The RIPE Database provides information about IP networks allocated or assigned within the RIPE NCC service region. This information is mainly stored as inetnum, inet6num, route and route6 objects. These objects store information about a single IP address or ranges of addresses.

The route and route6 objects use prefix notation to specify the single address or range of addresses about which they contain information.

"Prefix notation" specifies ranges using two parts: the prefix and its length.

  • For IPv4, the prefix is a 32-bit integer written in dotted quad notation with the value of the lowest IP address in the range. The prefix length is a whole number in the range 0-32 (for example 193.0.0.0/22 specifies the range of 1024 IPv4 addresses starting with,and including, 193.0.0.0).
  • For IPv6 address ranges, the prefix length must be in the range 0-128 and is a 128-bit whole number, written in hexadecimal groups of two bytes separated by colons and with the possible use of shorthand notation for strings of consecutive 0s.

The inetnum objects represent an IPv4 address space in range notation. The inet6num objects represent IPv6 address space in standard prefix notation.

When you query the RIPE Database for information about IP addresses, you can specify query arguments with the following notations:

  • A prefix (IPv4 or IPv6).
  • An explicit range (IPv4 only).
  • A single IP address. This is interpreted as a range of just one address. For IPv4, this can be written in range notation using the same start and end address. It could also be written as a single address. For IPv6, this has a prefix length of 128 or again it could also be written as a single address.

For IPv4 address space, the query argument can be specified with either prefix or range notation. When prefix notation is used, the database software converts this into range notation. An information message is included in the query response showing the conversions performed. For IPv6 address space, the query argument can only be specified in prefix notation. The single IP address is accepted as a short hand notation for a prefix. See Table 2: Queries For IP Networks table

We use three terms in these types of queries. These are all defined relative to the specified(reference) range:

  • An exact match refers to a range that is identical to the reference range.
  • A more specific range is contained within the reference range and is smaller. It contains fewer IP addresses than the reference range. We also call this a sub range.
  • A less specific range contains the whole of the reference range and is bigger. It has a greater number of IP addresses than the reference range. We also call this an encompassing range.

There are a number of options that describe how you can retrieve different types of information relative to a particular range of IP addresses (IPv4 or IPv6) including more and less specific queries.

# Default Queries for IP Network

If you do not specify one of the following IP related query flags, and your query argument is a range of IP addresses in any one notation, a RIPE Database server will try to find an object with an exact match range for the specified range. If found, the exact match range is returned. If an exact match range cannot be found, the server looks for the object with the smallest less specific range. This will be the smallest, existing, encompassing range.

# Exact Match Queries

If you want to change the default behaviour so that the server returns only an object with an exact match range, you need to use the –x (or --exact) query flag. This flag stops the server from looking for any less specific ranges if no exact match range exists. Not even the smallest encompassing range will be returned. If no exact match range is found, no object will be returned in the query response.

# More Specific Range Queries

These refer to queries qualified by the use of the -M and -m query flags.

These queries will return information about objects with ranges of IP addresses that are fully contained within the reference range specified in the query argument. The returned objects contain fewer addresses than the specified range. More specific range queries do not return the exact match range if it exists.

  • -M (or --all-more) - requests that the server should return all the sub-ranges that are completely contained within the reference range. When there are hierarchies of sub-ranges, all levels of the hierarchies will be returned down to the smallest sub-range in each hierarchy. Many objects can be returned.
  • -m (or --one-more) - requests that the server should return all the sub-ranges that are completely contained within the reference range. When there are hierarchies of sub-ranges, only the top level of the hierarchies will be returned. These are usually called one level more specific ranges. Many objects can be returned.

# Less Specific Range Queries

These refer to queries qualified by the use of the -L and -l query flags.

These queries will return information about objects with ranges of IP addresses that fully contain the reference range specified in the query argument. The returned objects contain a greater number of addresses than the specified range.

  • -L (or --all-less) - requests that the server returns the object with an exact match range, if it exists, and all objects with ranges that are bigger than the reference range and that fully contain, or encompass, it. Many objects can be returned.

  • -l (or --one-less) - requests that the server does not return the object with an exact match range, if it exists. It returns only the object with the smallest range that is bigger than the reference range and that fully contains, or encompasses, it. This is usually referred to as the one level less specific range. Only one object can be returned.

# Less Specific Range Queries For Referenced IRT Objects

An irt object represents a Computer Security Incident Response Team (CSIRT). It includes contact and security information. It is optionally referenced from inet(6)num objects using the "mnt-irt:" attribute (even though the irt object is not a mntner object). This shows which CSIRT is responsible for handling computer and network incidents for that address range.

A reference to an irt object does not only apply to the inet(6)num object that contains the reference. It also applies to all inet(6)num objects that are more specific to the one containing the reference. Not every inet(6)num object needs to contain a reference to the irt object. The irt reference only needs to be placed in the least specific encompassing object to apply to a whole hierarchy of objects. This makes it easier to apply and maintain.

There may be more than one inet(6)num object in a hierarchy referencing an irt object. In this case, the one referenced from the smallest encompassing object is the one that applies to the range in question.

There is a -c (or --irt) query flag to make it easy to find the inet(6)num object containing the reference to an irt object for any specific range.

This flag makes the server search up the hierarchy of less specific range objects from the range specified as the query argument. The search will stop when the first object is found containing a reference to an irt object. This can be either the specified range or an encompassing inet(6)num object at any level in a hierarchy. The query will return the inet(6)num object found for the range specified in the query argument. The referenced irt object found in the hierarchy will also be returned.

Sometimes, no inet(6)num object is found in the hierarchy that contains a reference to an irt object. In this case, the query response will only contain the inet(6)num object found for the range specified in the query argument.

# Queries Using Primary and Lookup Keys

All objects have a primary key. (See the section 'Attributes in an Object' for more details) This is the most basic type of query that can be made in the RIPE Database. Based on the primary key, a very specific instance of an object type can be queried. In almost all cases, a query on a primary key will only return a single object (assuming the query has not selected to include directly referenced objects). In most of those situations, that object will have a primary key that exactly matches the query argument. For example, querying for ‘aardvark-mnt' will only return the mntner object that has this as its primary key. In this example, you cannot query for a random part of the primary key. For example querying for ‘aardv' will not return this object. However if you query for ‘aardvark', you will not return this mntner object, but you will return any object containing the word ‘aardvark' in a lookup attribute.

In some cases, with hierarchical primary key values, the returned object may not exactly match the query argument. For example, if you query for ‘193.0.7.35' the returned inetnum object has the primary key value of ‘193.0.0.0 - 193.0.7.255'. Where address space is concerned, route(6) objects are usually returned with the address space object. So, in this case, you not only get objects with different primary keys, but also more than one object could be possibly returned in the query response.

Many objects also have lookup keys. (See attribute section on 'Indexed' for more details.) These are used for search type queries. If you query for ‘aardvark', the response will include any object where the word ‘aardvark' has been used in any attribute value of a lookup key, as well as any object where this is the primary key. For primary keys, the key would need to be an exact match with this word. A lookup key value only needs to include this word as part of the value. Individual words in lookup keys are separately indexed.

The terminology is a bit confusing. A query using a primary key is really a ‘lookup' for a specific object exactly matching the query argument. A query using the lookup keys is really a ‘search' for any objects containing the query argument.

There are several query flags that can filter or limit the objects contained in the response.

Examples of all queries using primary and lookup keys are shown in the next table. See Table 1: Queries Using Primary and Lookup Keys

# Referenced Objects in Query Response

A standard query will return a set of secondary objects that are directly referenced from the objects in the query response. For example, if the query response returns an inetnum object then, by default, the response will also include any directly referenced organisation, person and role objects. The person and role objects are subject to daily limits. A user can find themselves blocked for excessive querying of personal data objects even if they did not want that information.

This default behaviour can be turned off so that these secondary objects are not returned. There are two options for doing this:

“-r” or “--no-referenced” With this query flag, none of the referenced secondary objects will be returned in the response. If an inetnum object references a role object as "admin-c:", a person object as "tech-c:", and an organisation object, none of these objects will be returned with the inetnum object.

“--no-personal” This query flag only removes the personal objects, person and role. So, in the example above, the organisation object is still returned (Use this flag to avoid getting blocked for excessive querying of personal data).

“--show-personal” This is the opposite of the --no-personal flag. Currently, it does not do anything but may be changed in the future.

# RIPE NCC Global Resource Service

The RIPE NCC mirrors several other databases, in near real-time, that are considered useful to anyone who queries the RIPE Database. These include the other Regional Internet Registries (RIRs). This allows queries to the RIPE Database to retrieve information from one or more of the mirrored databases. A local copy is maintained of each mirrored database. Daily updates are obtained from the mirrored databases to keep the local copies up-to-date.

The mirrored databases are referenced by the source of the data. A list of currently available sources can be obtained by using the “-q” query flag.

All mirrored databases are made available by the RIPE NCC in RPSL syntax with the same RPSL extensions as the RIPE Database. If the mirrored data stream has some other syntax, it is converted into RIPE Database syntax before submission to the local database copy. This means that the data returned to a user who queries a RIPE NCC mirror may not be in the same format as data returned by querying the original data source directly.

Users can query the RIPE NCC mirrored databases as if they were querying the RIPE Database by adding the “-s” query flag or “-a” query flag. Bulk access to any of the mirrored databases is not possible. The access control mechanism, described in the section on Access to Personal Data, applies to all data returned, regardless of the source.

The mirrors of the other RIRs' databases only contain the resource information. They do not include all the personal data. To access the personal data users must query the other RIR databases directly.

The resource information received from the other RIRs in the daily data dumps is cross-referenced with the daily statistics published by each RIR. These statistics detail all the resources that each RIR is administratively responsible for. Only resources listed in these statistics are entered into the mirrored database. This eliminates any placeholder objects or aggregated blocks used administratively by the RIR. The result is a set of databases containing a global view of Internet resources administered by the RIRs.

This global database view can be queried collectively using the query flag —resource. This will return a single response from the RIR that claims to be administratively responsible for this resource.

# Update Methods

The available options for updating the RIPE Database are:

  • RESTful API
  • Webupdates (web form)
  • Syncupdates
  • Email Updates

However, these are not all distinct methods of updating the database. Some are front-ends to the others.

# Email Updates

Email updates were the original method of updating the RIPE Database. They are still used by many people, although synchronous updates by the other methods now account for the majority of updates.

Email update messages must be in plain text and can be MIME-encoded. If encoded messages are multipart/signed, the signature part will be associated with the corresponding MIME text part. When an encoded message is received, the database software will take each valid MIME part (including any related signature part) and merge them into one update message. Please see section 'MIME Support' for more information.

Passwords needed for authorising the updates of all objects in the message must be included somewhere in the message. This is done with the pseudo-attribute "password:", for example:

password: some clear text

This "password:" pseudo-attribute can be placed anywhere in the message. One attribute is needed for each required password. If the message is MIME-encoded the passwords can be in any MIME part. When it is all merged into a single update message, all passwords found will apply to all objects in the update. Passwords can also be contained within the text part of a signed update message and apply to objects outside the signed part. All credentials will be extracted before any authorisation checks are made. The "password:" pseudo-attributes will be removed before any of the objects are processed. This ensures that they will never be considered as part of any object.

Acknowledgements (ack) containing the result of the update are returned to the sender of the email based on the "Reply-to:" and "From:" fields in the email header. Notifications (notif) may also be sent based on email addresses found in the attributes within each object in the update message and the related mntner objects. See section on Notifications.

To submit an email update, send your email message to one of the following email addresses:

There is no limit on how many objects that can be included in an email update message, or MIME part. There is a maximum limit on the size of an email message, which is 40 MB.

Only one ack message is returned for each update message. However, there may be many notif messages generated for each object in the update. This can result in large numbers of emails sent out when an update contains many objects. The ack and all notifs are all sent out at the end of processing the whole update message. Your mail server needs to be able to handle large numbers of emails coming from a single source (@ripe.net), otherwise they may all get marked as spam. You should optimise the number of update messages and number of objects per update to suit your working practises.

# MIME Support

The database software supports the MIME format. This means that you can cryptographically sign an update message using email agents that attach the signature in a separate MIME part, not in the body of the message. However, encryption of the text is not allowed. All update messages must be sent in plain text.

Nested signing of messages is possible, allowing an update message to be signed by one user, sent to another user who signs it again and submits the update.

The database software does not allow any scoping of authorisation within the message (for example, MIME parts where different passwords apply).

It is strongly recommended to keep MIME encapsulation simple. Complex MIME structures are more likely to generate errors.

The following rules apply when submitting updates using MIME encapsulation:

The software will recognise the following headers and take the appropriate actions:

  • multipart/signed
  • multipart/alternative
  • multipart/mixed
  • multipart/unknown
  • application/pgp-signature
  • application/x-pkcs7-signature
  • application/pkcs7-signature
  • text/plain

All other content-types are treated as text/plain.

After extracting credentials and validating signatures, all MIME parts are merged together and treated as a single update message.

# Subject Line Keywords

The subject line can have a special meaning in email update messages by using keywords. The available keywords, which are case-insensitive, are:

  • NEW
  • HELP
  • HOWTO

One way to use a keyword is to put the single keyword in the subject line of an email message, with NO other words. If any other word is found (for example, Subject: NEW objects) then none of the words will be treated as keywords. All words in the subject line will be reported in the acknowledgement reply as invalid keywords, along with a WARNING message. In this context, it is impossible to know if a word is meant as a keyword or just part of a comment.

Many users often include their own references in the subject line. Using this method, it is not possible to also use a keyword. The user's references are reported in the WARNING message as invalid keywords.

Some examples: Subject: new

This is an accepted keyword. Subject: sending my new objects

None of these words are accepted as a keyword and all reported in the warning message.

Use the NEW keyword if you want the database to only accept new objects. In this case, all objects found in the update are assumed to be creation operations. If an object already exists in the database, that object will result in an error message in the acknowledgement. However, the remaining objects will still be processed.

The HELP keyword causes a piece of text to be returned in the acknowledgement that contains information about how to query and update the database. When this keyword is used the body of the update message, it is ignored. HOWTO performs the same action as the HELP keyword.

# RIPE Database RESTful API

For more information about the REST paradigm, see https://en.wikipedia.org/wiki/Representational_state_transfer. All the services are accessible via HTTPS. Use of the Whois REST API is governed by the RIPE Database terms and conditions

# RESTful URI format

Each object in the RIPE Database has a unique locator URI, in the following format:

https://rest.db.ripe.net/{source}/{objecttype}/{key}

Where:

  • Source is the database source (e.g. RIPE).
  • Objecttype is the object type (e.g. inetnum)
  • key is the primary key(s)
    • Normally key is a single attribute value.
    • Use the nic-hdl attribute value for person or role object types.
    • Combine the route(6) attribute value and origin attribute value for route or route6 object types (e.g. route 193.0.22.0/23AS3333).

# Environments

Environment Protocol Client cert Endpoint
TEST HTTP No http://rest-test.db.ripe.net
TEST HTTPS No https://rest-test.db.ripe.net
TEST HTTPS Yes https://rest-cert-test.db.ripe.net
RIPE HTTP No http://rest.db.ripe.net
RIPE HTTPS No https://rest.db.ripe.net
RIPE HTTPS Yes https://rest-cert.db.ripe.net

# POST

Create an object in the RIPE database.

HTTPS is mandatory.

# METHOD: POST

# URI Format: /{source}/{objectType}

# Path Parameters

name description
source RIPE or TEST (depending on location)
objectType object type.

# Query Parameters

name description
password Password for maintainer authentication (one or more values).
unformatted Keep the formatting of the resource as provided in the request (spaces, end-of-lines) .
dry-run Optional. Perform validation but don't perform the update.

# Headers

name description
Authorization Basic HTTP Authentication (opens new window). The Authorisation request header value contains 'Basic' followed by the base64 encoding of the maintainer name and password separated by a colon.

# HTTP Request Body

A WhoisResource containing the object to be created.

The client should specify the desired response format using the Accept: header in the HTTP request. If unspecified, the response defaults to XML.

The HTTP request must include a Content-Type: header for POST, PUT and DELETE. The HTTP response will include a Content-Type: header, and the response body will be encoded in the requested format.

The possible values that you can specify for the Accept/Content-Type header are:

  • application/xml for XML
  • application/json for JSON

Clients can also append an extension of .xml or .json to the request URL instead of setting an Accept: header. The server will return a response in the appropriate format for that given extension.

# HTTP Response Body

A WhoisResource containing the newly created, unfiltered object.

# HTTP Status Codes

Client applications should use the HTTP status code to detect the result of an operation. Any error messages will be included in the response body (see below).

Possible reasons for various HTTP status codes are as follows:

code description
OK (200) Successful update
Bad request (400) Incorrect value for object type or key. The server is unable to understand and process the request.
Authentication failure (401) Incorrect password
Forbidden (403) Query limit exceeded.
Too Many Request (429) Query limit exceeded.
Not Found (404) No results were found (on a search request), or object specified in URI does not exist.
Method not Allowed (405) No results were found (on a search request), or object specified in URI does not exist.
Conflict (409) Integrity constraint was violated (e.g. when creating, object already exists).
Unsupported Media Type (415) Unsupported/missing value for Accept/Content-Type header.
Internal Server Error (500) The server encountered an unexpected condition which prevented it from fulfilling the request.

# Examples

  • Example XML Request:

    curl -X POST -H 'Content-Type: application/xml' --data @form.txt 'https://rest.db.ripe.net/ripe/person?password=...'

  • Example JSON Request:

    curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' --data @form.txt 'https://rest.db.ripe.net/ripe/person?password=...'

  • Example Request using Basic authorisation (Basic AA1-TEST:AA1-TEST):

    curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'Authorization: Basic QUExLVRFU1Q6QUExLVRFU1QtUEFTU1dPUkQ=' --data @form.txt 'http://rest-test.db.ripe.net/test/person'

  • Example dry-run requests:

    curl -X POST --data @form.txt 'https://rest.db.ripe.net/ripe/person?dry-run&password=...'

    curl -X POST --data @form.txt 'https://rest.db.ripe.net/ripe/person?dry-run=true&password=...'

# PUT

Updates an existing object in the RIPE Database.

HTTPS is mandatory.

# Method: PUT

# URI Format: /{source}/{objectType}/{key}

# Path Parameters

name description
source RIPE or TEST (depending on location)
objectType The object type
key Requested object key

# Query Parameters

name description
password Password for maintainer authentication (one or more values).
unformatted Keep the formatting of the resource as provided in the request (spaces, end-of-lines).
dry-run Optional. Perform validation but don't perform the update.

# Headers

name description
Authorization Basic HTTP Authentication (opens new window). The Authorisation request header value contains 'Basic' followed by the base64 encoding of the maintainer name and password separated by a colon.

# HTTP Request Body

A WhoisResource containing the new version of the specified objects.

The client should specify the desired response format using the Accept: header in the HTTP request. If unspecified, the response defaults to XML.

The HTTP request must include a Content-Type: header for POST, PUT and DELETE. The HTTP response will include a Content-Type: header, and the response body will be encoded in the requested format.

The possible values that you can specify for the Accept/Content-Type header are:

  • application/xml for XML
  • application/json for JSON

Clients can also append an extension of .xml or .json to the request URL instead of setting an Accept: header. The server will return a response in the appropriate format for that given extension.

# HTTP Response Body

A WhoisResource containing either the newly created, unfiltered object or the error message in case of a bad/unauthorized request.

# HTTP Status Codes

Client applications should use the HTTP status code to detect the result of an operation. Any error messages will be included in the response body (see below).

Possible reasons for various HTTP status codes are as follows:

code description
OK (200) Successful update
Bad request (400) Incorrect value for object type or key. The server is unable to understand and process the request.
Authentication failure (401) Incorrect password
Forbidden (403) Query limit exceeded.
Too Many Request (429) Query limit exceeded.
Not Found (404) No results were found (on a search request), or object specified in URI does not exist.
Method not Allowed (405) No results were found (on a search request), or object specified in URI does not exist.
Conflict (409) Integrity constraint was violated (e.g. when creating, object already exists).
Unsupported Media Type (415) Unsupported/missing value for Accept/Content-Type header.
Internal Server Error (500) The server encountered an unexpected condition which prevented it from fulfilling the request.

# Error Response

If the request fails, any error messages will be returned in the response body, using the request Accept format (XML or JSON). This element will not be included on a successful response. Examples in WhoisResource.

# Examples

  • Example XML Request:

    curl -X PUT -H 'Content-Type: application/xml' --data @form.txt 'https://rest.db.ripe.net/ripe/person/PP1-RIPE?password=...'

  • Example JSON Request:

    curl -X PUT -H 'Content-Type: application/json' -H 'Accept:application/json' --data @form.txt 'https://rest.db.ripe.net/ripe/person/PP1-RIPE?password=...'

  • Example of a bad XML request when updating a mntner object using as request the person object from the first example:

    curl -X PUT -H 'Content-Type: application/xml' --data @form.txt 'https://rest.db.ripe.net/ripe/mntner/PP1-RIPE?password=...'

  • Example of a bad JSON request when updating a mntner object using as request the person object from the first example:

    curl -X PUT -H 'Content-Type: application/json' -H 'Accept:application/json' --data @form.txt 'https://rest.db.ripe.net/ripe/person/PP1-RIPE?password=...'

  • Example unfiltered using Basic authorisation header request (Basic AA1-TEST:AA1-TEST):

    curl -X PUT -H 'Content-Type: application/json' -H 'Accept:application/json' -H 'Authorization: Basic QUExLVRFU1Q6QUExLVRFU1QtUEFTU1dPUkQ=' --data @form.txt 'http://rest-test.db.ripe.net/test/person/AA1-TEST'

  • Example dry-run requests:

    curl -X PUT --data @form.txt 'https://rest.db.ripe.net/ripe/person/TP1-RIPE?dry-run&password=...'

    curl -X PUT --data @form.txt 'https://rest.db.ripe.net/ripe/person/TP1-RIPE?dry-run=true&password=...'

# DELETE

Deletes an object from the Database.

HTTPS is mandatory.

# Method: DELETE

# URI Format: /{source}/{objectType}/{key}

# Path Parameters

name description
source RIPE or TEST (depending on location)
objectType object type.
key Requested RPSL Object primary key.

# Query Parameters

name description
password Password for maintainer authentication (one or more values). Mandatory.
reason Reason for deleting given object. Optional.
dry-run Optional. Perform validation but don't delete the object.

# Headers

name description
Authorization Basic HTTP Authentication (opens new window). The Authorisation request header value contains 'Basic' followed by the base64 encoding of the maintainer name and password separated by a colon.

# HTTP Request Body

The client should specify the desired response format using the Accept: header in the HTTP request. If unspecified, the response defaults to XML.

The HTTP request must include a Content-Type: header for POST, PUT and DELETE. The HTTP response will include a Content-Type: header, and the response body will be encoded in the requested format.

The possible values that you can specify for the Accept/Content-Type header are:

  • application/xml for XML
  • application/json for JSON

Clients can also append an extension of .xml or .json to the request URL instead of setting an Accept: header. The server will return a response in the appropriate format for that given extension.

# HTTP Response Body

A WhoisResource containing the (filtered) deleted object.

# HTTP Status Codes

Client applications should use the HTTP status code to detect the result of an operation. Any error messages will be included in the response body (see below).

Possible reasons for various HTTP status codes are as follows:

code description
OK (200) Successful update
Bad request (400) Incorrect value for object type or key. The server is unable to understand and process the request.
Authentication failure (401) Incorrect password
Forbidden (403) Query limit exceeded.
Too Many Request (429) Query limit exceeded.
Not Found (404) No results were found (on a search request), or object specified in URI does not exist.
Method not Allowed (405) No results were found (on a search request), or object specified in URI does not exist.
Conflict (409) Integrity constraint was violated (e.g. when creating, object already exists).
Unsupported Media Type (415) Unsupported/missing value for Accept/Content-Type header.
Internal Server Error (500) The server encountered an unexpected condition which prevented it from fulfilling the request.

# Examples

  • Example Request:

    curl -X DELETE 'https://rest.db.ripe.net/ripe/person/pp1-ripe?password=123'

  • Example Request using Basic authorisation (Basic AA1-TEST:AA1-TEST):

    curl -X DELETE -H 'Authorization: Basic QUExLVRFU1Q6QUExLVRFU1QtUEFTU1dPUkQ=' 'http://rest-test.db.ripe.net/test/person/AA1-TEST'

  • Example dry-run requests:

    curl -X PUT --data @form.txt 'https://rest.db.ripe.net/ripe/person/TP1-RIPE?dry-run&password=...'

    curl -X PUT --data @form.txt 'https://rest.db.ripe.net/ripe/person/TP1-RIPE?dry-run=true&password=...'

# Request / Response Encoding

Please take into account the following points to avoid unexpected encoding behaviour:

  • Objects are stored using the latin-1 (ISO-8859-1) character set.
  • If the request character set is not latin-1, then the request body is converted to latin-1. A question mark character ('?' or 0x3F) is used as a substitution character, if the character is outside the latin-1 character set.
  • The response should contain a warning, if conversion was necessary. known issue #291 (opens new window)
  • Unrecognised encodings that cannot be converted to latin-1 will result in an unsuccessful operation.
  • To be absolutely certain of what was stored in the database, do a follow-up query.
  • The REST API response will be in UTF-8.
  • We recommend to use UTF-8 character encoding in all REST API requests, but restrict the content to valid latin-1 characters.

# Update latency

It could take up to 10 seconds before an update becomes visible for lookup or search operations. For non-hierarchical object types (person, role, organisation,...), the typical latency is less than 1 second. For hierarchical objects types (inet(6)num, route(6), domain), it is about 3-5 seconds on average, up to 10 seconds maximum.

A way to work around this limitation is to rely on the response of the muting operation in REST API (PUT, POST, DELETE). These all return the object as it appears in the database in their response body after the successful update. This object is never filtered or altered in any way.

Any required passwords must also be supplied as part of the Uniform Resource identifier (URI) using the URI query parameter "password=". One parameter should be used for each password supplied. The pseudo attribute "password:" cannot be used in the HTTP request body. See "Email Updates" for more information.

# Client Certificate Authentication

Client Certificate Authentication is supported by our REST API. To use the client certificate service, you must have your own certificate: either from a certificate authority (CA) such as Let's Encrypt, or you can generate one yourself.

The key-cert object's client certificate status is validated by checking its notBefore and notAfter dates to ensure it is within its designated validity period. This involves comparing the current date against these dates: if the certificate is not yet valid (notBefore) or has expired (notAfter), it is considered invalid and an error is raised. This validation ensures that the certificate is only used within its valid time frame, maintaining secure and reliable authentication.

Additionally, signed updates are only considered valid for an hour after they are signed. After that the authentication will fail.

# Examples

  • Create your own certificate:
    • Generate the private key: openssl genrsa -out client.key 2048
    • Generate the Certificate Signing Request (CSR): openssl req -new -key client.key -out client.csr
    • Generate the self-signed certificate using the CSR: openssl x509 -req -days 365 -in client.csr -signkey client.key -out client.crt
  • Example using curl and previous certificate:
    • curl --cert client.crt --key client.key -X PUT --data @form.txt'https://rest-cert.db.ripe.net/ripe/person/TP1-RIPE?dry-run&password=...'

# Syncupdates

Syncupdates (opens new window) enables updates to the RIPE Database synchronously, meaning, the result is returned immediately to the user. It is intended for use by applications that need to update the RIPE Database and are able to process the result afterwards. An interface can easily be created in any language that supports the HTTP protocol. Syncupdates supports HTTP GET and POST methods (both multipart and URL-encoded formats). It can also be used directly via a web form.

Syncupdates accepts the following parameters (query params for GET, form params for POST):

  • DATA
    This variable should contain the actual update message.
  • NEW
    This variable can be either yes or no. If it contains yes, the update will fail if it contains changes to existing objects.
  • HELP
    This variable can be either yes or no. If it contains yes, the help message of the whois server will be given as the output.

Multiple objects are accepted in the body, and any required passwords must also be supplied in the body using the "password:" attribute.

After composing the input and sending it as a POST or a GET request, the server will return the usual http response headers and the body if an acknowledgement exists.

The first line of the response will give the result of the transaction, in the form of:

HTTP/1.1 (code) (message)

where (code) is a three-digit number which is a code for the message. The first digit of the code denotes the type of the message. The rest of the digits are unique for all messages:

  • 2XX denotes a successful transaction
  • 4XX denotes that the request could not be understood by the server due to malformed syntax,

If the code begins with 2, there will be an acknowledgement in the body of the response, in the form of text/plain.

These are the actual codes returned by Syncupdates:

  • 200 OK (successful)
  • 400 Bad Request (invalid HTTP request, URL or parameters)

Syncupdates can be accessed using the following URLs:

Examples of GET requests:

curl -4 -v -d "HELP=yes" https://syncupdates-test.db.ripe.net
curl -4 -v https://syncupdates-test.db.ripe.net/?HELP=yes

Example of a POST request:

curl -v -4 -X POST -H "Content-Type: multipart/form-data; boundary=--------------------------466af99a9520" --data-binary @form.txt https://syncupdates-test.db.ripe.net
----------------------------466af99a9520
Content-Disposition: form-data; name="DATA"
organisation:   ORG-TS1-TEST
org-name:       RIPE NCC Training Services
org-type:       LIR
address:        Singel 258, 1016 AB Amsterdam
phone:          +31205354444
fax-no:         +31205354444
e-mail:         training@example.org
admin-c:        TS1-TEST
tech-c:         TS1-TEST
abuse-c:        AA2-TEST
ref-nfy:        auto@example.net
notify:         xnotify@example.org
mnt-ref:        TEST-DBM-MNT
mnt-by:         TEST-DBM-MNT
source:         TEST
password:       some clear text 
----------------------------466af99a9520--

The aim of this service is to provide updates around the clock, except for maintenance operations. In cases where it's not possible to update the database, Syncupdates will return with the following message:

"Updates are unavailable at the moment. Please try again later."

Behind Syncupdates, the software has a separate handler to the one used for both the RESTful API and Webupdates. This handler is the same for both scripted access to Syncupdates or the web form access. This handler will accept multiple objects in the same update. This allows for a different type of usage to the RESTful API. A single response is returned to the user with the results of processing all the objects in the update message. The same timing issue applies across the whole update as referred to in the Webupdates description above. If an update has a very long list of objects and the http connection times out during the update, the processing of the update will still run to completion. No response message will be returned to the user after an http timeout. Notification emails will always be sent on completion.

To modify data without affecting the underlying database, you can use dry-run

# Webupdates

Webupdates can be accessed via the following URLs:

Webupdates (opens new window) is a graphical front-end for the RESTful API. It allows objects to be created, modified and deleted from either the RIPE or TEST Database and their RC equivalents. Object templates are available to guide users through object creation and modification. These can be selected as individual fields or a single text area. In field mode, a template for creating a new object will only show the mandatory attributes. Additional and optional attributes can be added to the template as required. In text area mode, the initial template will show all possible attributes for an object type. The mandatory attributes are in upper case and the optional ones are in lower case. It is not possible to switch between the field mode and text area.

When the submit key is clicked, the data is sent via the RESTful API to the database software. This restricts input to single object processing only. If you paste more than one object into a text area, an error will occur.

When deleting objects, the full object is presented to you for verification and you must then enter the reason for the deletion.

When an object is queried using the Webquery form, ‘hover over' buttons are available to take any object from the query results directly into Webupdates to update or delete the object.

Objects up to a maximum size of 10MB can be managed through the Webupdates interface. If any errors occur during the update, the error messages are shown either:

  • In a single error block at the start of the form- if they are general errors
  • Within the form- if the error is specific to a particular attribute and you are using the field mode
  • In a series of error blocks at the start of the form- for errors specific to particular attributes but you are using the text area mode

There is no maximum amount of time for an update operation to be completed. You should set your timeout to the highest possible value. Problems sometimes occur with reverse domain objects. Because of all the DNS checks made, reverse domain objects sometimes take longer to process, and your connection may occasionally time out. The update will still be completed by the database server, but no acknowledgement will be returned if the connection has timed out. Notification messages are always sent by email, and will be sent regardless of your connection status.

Any required passwords must also be supplied. These can be entered via the form password field. When using the text area input mode, passwords can also be included the message body using the "password:" attribute. More information about passwords is available in 'Email Updates'

# Creating Basic RIPE Database Objects

You need to create a number of objects in the RIPE Database in order to fill in the RIPE Database Template.

Please follow the steps below in order to create them.

  1. RIPE NCC Access Account You need to have a RIPE NCC Access account in order to be able to use the web interface of the RIPE Database.

    You can create your RIPE NCC Access account using https://access.ripe.net/registration

  2. Role Object and Maintainer Object Each role objects describe a business function. Each object has a unique NIC handle as primary key.

    Maintainer objects protect object in the RIPE Database. They contain the information needed to authorise creation, deletion or modification of the objects they protect.

    You can create your first role and maintainer objects using the object creation tool (opens new window).

    Choose a name for your maintainer object and enter it in the "mntner" field which will be the primary key.

    When you receive the message "Your objects have been successfully created", make a note of your role object's primary key and mntner object's primary key.

    You can use your role object's primary key (NIC handle) in the "admin-c:", "tech-c:" and "zone-c:" fields of the RIPE Database Template.

    You can use yor mntner object's primary key in the "mnt-by:" field of the RIPE Database Template.

    You can create additional person, role and mntner objects and also change the objects you already created using RIPE Database Webupdates (opens new window).

  3. Organisation Object Organisation objects contain information about organisations. Each object has a unique organisation ID ("organisation").

    You can create organisation object using RIPE Database Webupdates (opens new window)

    Keep "AUTO-1" in the "organisation" field. The organisation ID will be created automatically. Enter the primary key of your mntner object in the "mnt-ref" field. Use the "bell" icon to fill in the "abuse-c" field.

    When you receive this message: "Your object has been successfully created". For example, "organisation ORG-XYZ-RIPE", make a note of the new organisation ID (ORG-XYZ-RIPE).

    You can use the organisation ID in the "org:" field.

    Please note that organisation objects with IANA, RIR, NIR or LIR can only be created by the RIPE NCC. Any other entity must use OTHER in the "org-type:" when creation organisation objects.

# Accessing the Object Templates

To create or modify an object you may need to access the template for that object. These are shown along with a detailed description of each attribute and its value in section 4. RPSL Object Types.

From almost any computer, if you have a terminal window with a command line prompt, you can use either netcat (nc) or telnet commands to obtain any of the object templates. For this purpose, they both do the same job, but netcat is considered to have better error handling than telnet.

For example, getting the template for an inetnum object using these methods:

Using netcat in a terminal window to obtain an object template:

$ nc whois.ripe.net 43
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
-t inetnum
inetnum:        [mandatory]  [single]     [primary/lookup key]
netname:        [mandatory]  [single]     [lookup key]
descr:          [mandatory]  [multiple]   [ ]
country:        [mandatory]  [multiple]   [ ]
geofeed:        [optional]   [single]     [ ]
geoloc:         [optional]   [single]     [ ]
language:       [optional]   [multiple]   [ ]
org:            [optional]   [single]     [inverse key]
sponsoring-org: [optional]   [single]     [inverse key]
admin-c:        [mandatory]  [multiple]   [inverse key]
tech-c:         [mandatory]  [multiple]   [inverse key]
abuse-c:        [optional]   [single]     [inverse key]
status:         [mandatory]  [single]     [ ]
remarks:        [optional]   [multiple]   [ ]
notify:         [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
mnt-lower:      [optional]   [multiple]   [inverse key]
mnt-domains:    [optional]   [multiple]   [inverse key]
mnt-routes:     [optional]   [multiple]   [inverse key]
mnt-irt:        [optional]   [multiple]   [inverse key]
created:        [generated]  [single]     [ ]
last-modified:  [generated]  [single]     [ ]
source:         [mandatory]  [single]     [ ] 
% This query was served by the RIPE Database Query Service version 1.92.5 (ANGUS)
$

Using telnet in a terminal window to obtain an object template:

$ telnet whois.ripe.net 43
Trying 2001:67c:2e8:22::c100:687...
Connected to whois.ripe.net.
Escape character is '^]'.
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
-t inetnum
inetnum:        [mandatory]  [single]     [primary/lookup key] 
netname:        [mandatory]  [single]     [lookup key]
descr:          [mandatory]  [multiple]   [ ]
country:        [mandatory]  [multiple]   [ ]
geofeed:        [optional]   [single]     [ ]
geoloc:         [optional]   [single]     [ ]
language:       [optional]   [multiple]   [ ]
org:            [optional]   [single]     [inverse key]
sponsoring-org: [optional]   [single]     [ ]
admin-c:        [mandatory]  [multiple]   [inverse key]
tech-c:         [mandatory]  [multiple]   [inverse key]
abuse-c:        [optional]   [single]     [inverse key]
status:         [mandatory]  [single]     [ ]
remarks:        [optional]   [multiple]   [ ]
notify:         [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
mnt-lower:      [optional]   [multiple]   [inverse key]
mnt-domains:    [optional]   [multiple]   [inverse key]
mnt-routes:     [optional]   [multiple]   [inverse key]
mnt-irt:        [optional]   [multiple]   [inverse key]
created:        [generated]  [single]     [ ]
last-modified:  [generated]  [single]     [ ]
source:         [mandatory]  [single]     [ ]
% This query was served by the RIPE Database Query Service version 1.92.5 (ANGUS)
Connection closed by foreign host.
$

To obtain the template with the full description of each attribute and its value, use -v instead of -t in the above commands. Once you have the template, it can be copied into an email message or pasted into a web form or added into a script to generate objects. To create an object from the template, you must remove all the attribute lines that you do not want. For the remaining lines, you must replace the description with the value. Where an attribute is multiple, further lines can be added with additional values.

With some update methods the template is provided for you - for example, when using Webupdates. If you select to create a new object using field mode it presents a set of fields matching all the mandatory attributes for the selected object type. Optional attributes can be selected from a drop-down menu. More instances of any given attribute can be inserted. If you choose the text area mode, a list of all attributes is presented in the text area. The mandatory attributes are in upper case and the optional attributes are in lower case. Delete the optional ones you don't want to use. The software later converts all attribute names to lower case.

The Webupdates text area template can be used to present a template to be cut and pasted in another form or medium. The Webupdates object creation process does not present the full template information. It only shows lists of attributes. To get the full template details, as shown in section 4. RPSL Object Types, use the Web Query form (by selecting the Query option from Webupdates) and enter the following query for the appropriate object type as the ‘Search term':

-t inetnum

Using -v instead of -t in the Web Query form will present the longer output describing all the attributes.

# Dry-run

The TEST Database has always been promoted as the place to "try" an update to see what happens. But the TEST Database has very little data. It is also reset every 24 hours. So if you want to test anything that has dependencies on other data, you have to reproduce it all in the TEST Database to do the test. That in itself can be a major effort. And tomorrow it is all gone.

To address this, there is a "dry-run" feature that lets you test updates on the production RIPE Database. All your data is there with the correct authorisation tokens. All dependencies are taken care of. You can submit your update and see what the result would be, but nothing is actually changed in the database.

To use the dry-run feature, submit an update by any available update method.

Enter whatever you want for this single object. Use the correct syntax or include deliberate errors, full set of credentials or not - it all depends on what you want to test. Somewhere in the update, enter the "dry-run:" pseudo-attribute on a new line:

dry-run:

It does not need a value. If you add any text it will be ignored. This pseudo-attribute can be added anywhere in the update message in the same way as the "password:" pseudo attribute can be. Then submit the update.

The update is received by the RIPE Database production software. All the checks are done on the object:

  • Syntax
  • Business rules
  • Authorisation
  • Referential integrity

Then it stops! Nothing is changed in the RIPE Database.

An acknowledgement message is returned to the user who submitted the update by the normal channels, depending on the input method used. No notifications are sent. So only the user who is testing the update gets the results. For a dry-run update that would modify an object, the diff output that would normally be in the notification message is added to the dry-run acknowledgement message. This helps to show what would be changed by an actual update. See the section on Notifications for more details.

# Format of the Update Message

Historically updates were only sent to the database using email messages. Currently, there are many other methods of submitting update information to the database. However, we still refer to an update as an update message.

The different ways of submitting the update message are described in section Email updates. The method that is used passes the data to an appropriate handler in the software. These handlers extract the one or more database objects from the update message along with any credentials, including passwords, PGP signatures and single sign-on session details. An object must start with one of the recognised object type attributes. These are described in section RPSL Object Types. The object ends with the first blank line found after the type attribute. This is technically defined as two consecutive new-line characters ("\n\n"). An object cannot contain a blank line. If a blank line is required for the visual representation of an object it must be either a "remarks:" attribute with no ‘value' part or, if it is a continuation line of any attribute, it must start with a plus sign ("+"). See section Split Values for more details.

We apply a heuristic method to each paragraph of text in the update message to determine if it is an RPSL object. Any part of the message that is not recognised as an RPSL object is ignored. These ignored parts are grouped together at the end of the acknowledgement message.

The object(s) presented in the update message must each match one of the object templates described in section RPSL Object Types. These templates can be accessed in several ways. See section Accessing the Object Templates.

Each instance of an object must contain at least one of each of the mandatory attributes for that object type. The optional attributes can be left out, unless the software business rules require them. If any of the optional attributes are included they must have a ‘value' part, unless the value is defined as free text. Free text values can be blank. Depending on the update method, one update message may contain several objects, with a mixture of creation, modification and deletion operations.

# Garbage Collection

When specific objects of a certain type have existed in the database unreferenced for a continuous period of time, it becomes eligible for automatic deletion.

The object types include person, role, mntner, organisation (not if the type is LIR) and key-cert. Clusters of these objects that form a self-referencing group, without any reference from resource data, will also be deleted.

# Historical Data

Every time an object is updated in the RIPE Database, the old version is saved. A standard query will always return the most recent version. The old versions are available by using the history query flags. See the section on Querying Historical Data for more details. Personal historical data is not available.

# Object Processing

When an update message contains multiple objects, the order of processing the objects in the message only changes in specific situations. The database software tries to process the objects one by one, starting with the first recognised object in the message. The order can matter, however, the database software has limited options for changing the order. The only condition the software can recognise is when an auto-generation process is used for certain object primary keys. "AUTO-n" primary key values can be included for generation and can also be referenced by other objects in the same update message. These will be resolved, as long as the number "n" is consistent and there are no circular references. If an object that references a value ‘AUTO-1' is listed in the update message before the object where the value ‘AUTO-1' is generated, the ordering will be changed. The referencing object will be pushed to the end of the list, by which time the object crating the ‘AUTO-1' value will have been processed.

The below figure shows an example of two objects that will be created but in a different order. The second figure shows an example of two objects that will not be created as there is a circular reference between the ‘AUTO-n' attributes that can never be resolved. (Only the relevant parts of the objects are shown in the figures.)

inetnum:     193.0.7.35
admin-c:     auto-1
person:      admin guy
nic-hdl:     auto-1

In the example of the figure above. the second, person object must be created first. This gives a real value to ‘auto-1'. Then the first, inetnum object can be created referencing that real value for ‘auto-1'.

organisation:    auto-1
admin-c:         auto-2
person:          admin guy
nic-hdl:         auto-2
org:             auto-1

In this figure, the object can be created because of the circular reference to ‘auto-n' values. They both need to create a real value for an ‘auto-n' tag. But they both reference the ‘auto-n' tag of the other object, which does not yet exist.

You can avoid these complex arrangements of, and circular references to, auto-generated values in a single update message by sending multiple, consecutive updates instead.

When processing each individual object, the software makes many checks including that:

  • The syntax of the object is correct.
  • The object passes all required authorisation checks.
  • All references to other objects can be resolved without conflicts.
  • The operation does not compromise referential integrity. For example, when an object is to be deleted, the server checks that it is not referenced from any other object in the RIPE Database.
  • The object complies with all software business rules, for example, not creating an allocation resource object without including the optional "org:" attribute. This is required in an allocation object.
  • The object complies with relevant policies, such as having the correct "status:" value in inetnum objects.

If all checks are passed, the update will be successful for this object. If one of these checks fails, the operation fails for this object. This is shown in the acknowledgement message and sometimes in notification messages. See the section on Notifications for more details.

Each object in the update message is processed independently of others (except for the ‘AUTO-n' references). If the operation fails on one object, the following objects will still be processed. There may, however, be consequences of a previous failed operation. For example if a person object creation fails, a later object creation which references this person object will fail the referential integrity checks because the person object does not exist in the database.

After the software finishes processing all the objects in the update message, an acknowledgement message is returned to the sender of the original update. For email update messages, the acknowledgement will be another email sent to the address as specified in the "Reply-to:" field or "From:" field. For synchronous update messages it will be returned via the open HTTP connection. If the connection has timed out or been closed, no acknowledgement is sent. In all cases, the update will still be completed by the database software regardless of the status of HTTP sessions of validity of email addresses. Notification messages may also be sent. See the section on Notifications for more information about this.

# 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.

# Update Operations

There are three update operations that can be performed on an object:

  • create
  • modify
  • delete

The create and modify share a lot in common. Initially, when an object is presented by either email or Syncupdates, the database software has to decide if the object already exists or not. If it exists, the operation is modify. If it does not exist the operation is create. This issue can be forced with the use of the keyword ‘NEW'. If this keyword is included then the operation is set as create. If the object already exists, it will be an error. An existing object will never be updated when this keyword is included in the update. For email updates, this keyword will be in the ‘Subject' line. For client-based Syncupdates this keyword is passed as a parameter. It is not possible to use the keyword with the web-based Syncupdates form at: https://apps.db.ripe.net/db-web-ui/syncupdates

The RESTful update method works differently as it follows the standard REST paradigm. If the data is received by a POST method, the ‘NEW' keyword is set and it can only be a create operation. If the data is received by a PUT method it can only be a modify operation. If the method and operation do not match it is an error.

Webupdates uses the RESTful API as the update method. So it must also follow the REST paradigm. There are additional checks at the Webupdates form level to ensure the right method is used.

If the operation is modify and the supplied object data is identical to the existing object stored in the database, allowing for white space variations, then the object is not modified. This is considered to be a successful ‘NO OPERATION'.

The delete operation is the same no matter what update method is used. The full version of the object must be supplied exactly as it is stored in the database. The supplied version is checked against the stored version by compressing the white spaces and doing a string comparison. If they don't match, the delete operation fails. If you query for the object before supplying the query result in a delete operation, make sure you use the correct query flags to avoid any filtering of the returned object. See section on Filtering Query Output for more details.

To delete an object, there must be no references to it from any other object in the database. A single reference will prevent it from being deleted. Note, however, that not all attributes containing primary keys of other objects are hard references. The routing policy attributes in an aut-num object can list other AS Numbers but these are not considered as references for the delete operation.

For the RESTful API and also Webupdates, the delete method is used. For mail and Syncupdates the pseudo attribute "delete: some reason text" must be added to the object data. As these update methods allow multiple objects in an update message, this pseudo-attribute must be part of the object itself to ensure a strong association with this pseudo-attribute and a specific object. Each object that is to be deleted must have a "delete:" pseudo attribute attached to it. It can be added at any point within the object or immediately before or after the object.

Objects can still be deleted from the database even if they are not syntactically correct. This allows for old objects to be deleted long after the syntax has been changed. If the object was to be modified, any syntax errors would need to be corrected.

Following Acceptable use policy (opens new window), we strive to detect potential attacks. If a DoS attack is detected, we temporarily block the user's IP address.

The RIPE Database Terms and Conditions (opens new window) allow the RIPE NCC to block or suspend access to the RIPE Database services for any suspected abuse. Users exhibiting suspected abusive behavior may be permanently blocked from the system. If a user is permanently blocked, they will receive a notification informing them of the block whenever they attempt to make an update.

If you wish to be unblocked, please contact the RIPE Database administration team ripe-dbm@ripe.net to discuss further.

# History of the RIPE Database

# Background of the RIPE Database

From the very first RIPE Meeting in 1989, the need for some sort of registry had been identified. In the early years of RIPE, this consisted of documenting the use of IPv4 address space in the RIPE region on a voluntary basis. The actual address space was not distributed by RIPE.

From August 1992, the newly established RIPE NCC started distributing address space in its service region. Allocations made by the RIPE NCC have always been documented in the registry by the RIPE NCC and the Local Internet Registries (LIRs). The RIPE NCC address registry was set up to serve two purposes:

  1. A comprehensive public record of the address space for which the RIPE NCC has administrative responsibility. This concerns both address space allocated by the RIPE NCC and address space allocated by others and transferred to the administrative responsibility of the RIPE NCC.
  2. A comprehensive public recording of the current holders of the address space. With the exhaustion of IPv4 address space, there will be no more unallocated IPv4 address space. However, the need for an accurate registry will remain.

Transparency and accountability about the administration of Internet number resources has always been very important. Publication of the registry is an essential element of this transparency and accountability. The registry plays an important part in the operational coordination between Internet operators. The Internet Routing Registry (IRR) was established in 1995. Its purpose is to ensure stability and consistency of the Internet-wide routing by sharing information between network operators.

Originally, the RIPE Database was used by many Domain Name Registries as their ccTLD authoritative registry database. For some of the larger ccTLD registries, the RIPE Database was not their authoritative database but held a lot of duplicated information from the Domain Registries. In some cases, it just held a top-level forward domain object and used a "refer:" attribute to re-direct any queries to their authoritative whois service. Because this was a mixed up and incomplete system, it was decided at RIPE 57 in October 2008 to remove all forward domain information from the RIPE Database. This was completed in January 2011.

# Versions of the RIPE Database

The original first version of the RIPE Database no longer exists and we have no information about it.

The second version of the RIPE Database was written in PERL and used files to store the data rather than a database. The data was in the ripe-181 (opens new window) format. This version provided a clear separation of routing information from allocation details.

Version 3 was released in April 2001. In this version, the old RIPE Database ripe-181 format was converted to the new RPSL format (opens new window). The software was written in C and the data was stored in a MySQL database.

The basic design of the data model is still the same now. Since its release several years ago, many additional features have been added. New object types were added in 2004, including the organisation object. When the RIPE NCC started to encourage the adoption of IPv6, theRIPE Database software was made fully compliant with IPv6 and additional object types were added for this: inet6num and route6.

Web forms were introduced for both queries and updates shortly after this version was released. These have been constantly revised over the years and are still subject to regular minor improvements and occasional major improvement.

A RESTful API was introduced, which was deployed to production in 2013.

The software underwent a major re-factor, still in C, in 2004. It was totally rewritten in Java in 2012, for queries, and early 2013- for updates. The database backend was switched from MySQL to MariaDB in 2016.

This database software is also used, with some local modifications, by APNIC and AFRINIC.

# Personal Data, Database Management and Responsibilities

# Personal Data in the RIPE Database

The RIPE NCC provides the software and the hardware infrastructure to operate the RIPE Database service. The RIPE NCC also provides 24/7 monitoring and engineering support to maximise reliability, availability and performance. There is a customer support service to provide assistance to those using the RIPE Database.

Most personal data is not registered in the RIPE Database by the RIPE NCC but by others (generally, those responsible for the specific Internet number resources or by the data subjects themselves). The RIPE NCC has only limited, control (and in some cases, no control) over the personal data stored in the RIPE Database. The purpose and means of processing personal data registered in the RIPE Database are not determined by the RIPE NCC but by the RIPE community. However, the RIPE NCC is the organisation that implements and/or oversees the implementation of instructions given by the RIPE community. In that sense, the RIPE NCC could be seen as the responsible party for processing personal data in the RIPE Database in accordance with the Dutch Data Protection Act.

Steps are taken to prevent bulk access to personal data and limits exist on how many personal data objects can be queried in a 24-hour period. In some situations, the data made available in some forms is dummified. This is a process by which information that could identify a person or organisation is removed from the output.

Anyone whose personal details have been entered into the public RIPE Database should have been informed by the person/organisation that entered those details. If you find your personal details within the RIPE Database and you had no knowledge of this, you should, firstly, raise this issue with the person/organisation that entered those details. You may find it is a condition of a contract that provides your Internet services, but you had not realised it.

If you want these details corrected or completely removed from the RIPE Database you should again, in the first instance, contact that same person/organisation that maintains this data in the RIPE Database. If they do not comply with your request to your satisfaction, the RIPE NCC has a procedure for the removal of personal contact details from the RIPE Database. You must realise that the consequences of removing such data may result in the cancellation of some services. That is a matter you must take up with the service provider.

For more information regarding Personal Data in the RIPE Database, please refer to the RIPE NCC Data Protection Report where more information can be found about the processing of personal data and the applicable legal framework.

# Database Management

The RIPE NCC is tasked by the RIPE community to manage the RIPE Database as a public service. Although the RIPE NCC has limited control over the personal data registered in the RIPE Database and is not responsible for all of the operational data content, there are occasions when the RIPE NCC may correct or delete RIPE Database data:

  • According to accepted RIPE Policy Proposals/RIPE Documents
  • To comply with applicable law
  • If so ordered by any competent court
  • To fulfil any legal obligation
  • When a breach of the Terms and Conditions has occurred
  • For management operations of the RIPE Database
  • If data is inaccurate
  • If data has been entered by someone who is not authorised to do so
  • If an individual has requested the removal of their personal data

This list may change over time and is not exhaustive. For further details please refer to the Terms and Conditions.

# Responsibilities of the RIPE NCC and Data Maintainers

In terms of managing the RIPE Database public service, there are some things the RIPE NCC is and is not responsible for.

  • The RIPE NCC does not guarantee the accuracy, completeness or availability of the RIPE Database or of the data contained therein.
  • The Maintainer is responsible for keeping all data maintained by them accurate and up-to-date, including correct contact details. The data must be good enough to allow the RIPE NCC to contact the Maintainer or Registrant within a reasonable time without having to get information from another source.
  • The Maintainer who enters personal data into the RIPE Database has a responsibility to inform the individual to whom the data pertains and to obtain his/her explicit consent for the entry in the public RIPE Database if required by law.
  • The RIPE NCC is not responsible for the use of any registered Internet number resources nor is the RIPE NCC responsible for any issues that may arise from this use.
  • The RIPE NCC is not responsible for any issues arising from the use of any information contained within the public RIPE Database.

This list may change over time and is not exhaustive. For further details please refer to the Terms and Conditions.

# 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:

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:

  • 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 (opens new window), 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 (opens new window).

# 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 (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.