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

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.

Last updated:

Pager
Previous pageAcknowledgment Message
Next pageAuthorisation Model