RIPE Database docs
Sidebar Navigation

Introduction to the RIPE Database

RIPE Database Documentation Overview

Intended Audience

Conventions Used in the RIPE Database Documentation

What is the RIPE Database

Purpose and Content of the RIPE Database

History of the RIPE Database

Personal Data Database Management and Reponsabilities

RIPE Database Structure

Database Object

Primary and Secondary Objects

List of Primary Objects

List of Secondary Objects

The Attributes in Database Objects

Attribute Names

Attributes in an Object

Attribute Values

Attribute Properties

How to Organise Your Data

REST API Data model

RPSL Object Types

Descriptions of Primary Objects

Descriptions of Secondary Objects

Available Databases

RIPE Database

TEST Database

Release Candidate Database

Experimental Databases

Update Methods

RESTful API

Webupdates

Syncupdates

Email Updates

Updating Objects in the RIPE Database

Format of the Update Message

Accessing the Object Templates

Object Processing

Update Operations

Historical Data

Special Considerations for Object Creation

Garbage Collection

Dry run

Set Objects

Notifications

Acknowledgment Message

Notification Messages

Authorisation

Authorisation Model

Using the Authorisation Methods

Security of Data Using Authorisation

Protection of PERSON and ROLE Objects

Protection of AUT NUM Object Space

Protection of Address Space

Protection of Route Object Space

Protection of Reverse Delegation Objects

Protection of Objects with Hierarchical Names

Protecting Membership of a Set

Referencing an ORGANIZATION Object

Referencing an IRT Object

IRT Object

Force Delete Functionality

Request ENUM delegation

Request DNSSEC delegation

How to Query the RIPE Database

The Structure of a Query

Web Query Form

RESTful API Queries

Command Line Queries

Query Responses

Registration Data Access Protocol

Access to Personal Data

Types of Queries

Queries Using Primary and Lookup Keys

Queries for IP Networks

Queries for Autonomous Systems

More and Less Specific Lookups For Reverse Domains

Inverse Queries

Abuse Contacts

Grouping the RIPE Database Output

Filtering the Query Reponse

IRR Toolset Support

Persistent Connections and Keeping State

Getting All the Members of Set objects

Access Control for Queries

RIPE NCC Global Resource Service

Other Query Flags

Referenced Objects in Query Response

Historical Queries

Related Software and Tools

Geolocation in the RIPE Database

RIPE Database Mirror

Setup RIPE Database Mirror

Near Real Time Mirroring v3

Near Real Time Mirroring v4

Access to NRTM

Tables of Query Types Supported by the RIPE Database

How to Recover Access to a Maintainer Object

Installation and Development

Getting started on macOS

Getting started on Ubuntu Linux

Building whois

Configure MariaDB

Coding standard

Installation instructions

Database Support

Support Overview

Clean up of Unreferenced Data

Database Security

Configuring Reverse DNS

Database Business Rules

Highlighted Values in the RIPE Database

Create First Role Mntner

Removal of personal data

Release Notes

FAQ

Appendices

Appendix A Syntax of Object Attributes

Appendix B Copyright Statement

Appendix C RIPE Database Query Server Response Codes and Messages

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

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

Appendix F Special Considerations for Object Types

Appendix G Object Types with Personal Data

Appendix H PGP Authentication Method

Appendix I Client Certificate Authentication

Appendix J Ripe Test Database

Appendix K API Keys

Glossary

Legal Information

RIPE Database Acceptable Use Policy

HTML Terms And Conditions

All Documentation Combined

On this page

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:

  • Email updates to the RIPE Database
  • Email updates to the TEST Database
  • Email updates to the RC Database

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.

Last updated:

Pager
Previous pageSyncupdates
Next pageFormat of the Update Message