Database Consistency Project (DBConstat)

What is the Consistency Project?

The goal of this project is to find the objects with inconsistencies not enforced by the database, and provide reports and statistics for users to help correct them. It also aims at checking for the necessary protection of objects.
The goals of the consistency project do not include, for example, reality checks for inetnum objects, but it addresses only internal inconsistencies in the database, such as invalid references.

Here are the types of inconsistencies which are addressed in this project:

  • Inetnum object related:
    • Inetnum objects without "status" attribute;
    • Assigned inetnum objects without allocations;
    • Overlapping inetnum objects;
    • Inetnum objects with suspicious boundaries to form a network;
    • Assigned inetnum objects from assignments;
    • Inetnum objects with wrong PA or PI status;
    • Wrongly allocated inetnum objects.
  • Person object related:
    • Person objects with multiple identical copies;
    • Person objects which do not have any references to them;
    • Person objects not having a valid nic-handle;
    • Objects which have references to invalid nic-handles.
  • Maintainer (mntner) object related:
    • Mntner objects which do not have any references to them.
  • Protection related:
    • Weak authentications schemes for maintainers;
    • Inetnum objects with no "mnt-lower" attribute.

Inconsistency Reports

Overview

You can access the overview of inconsistencies and daily counts from the following overview.

Per Maintainer Reports

Reports about individual inconsistencies are sent only to the maintainers of objects. If you would like to receive the report for your inconsistencies, plase send an e-mail to auto-dbcon _at_ ripe _dot_ net containing the maintainer name in its body, and the appropriate authentication.

  • If the authentication of your maintainer is MD5-PW, your mail should contain the following lines in its body:
    mntner: <maintainer_name>
    password: <password>
  • If the authentication of your maintainer is PGPKEY, your mail should contain the following line and should be signed with the appropriate key:
    mntner: <maintainer_name>

If you supply an existing maintainer together with the proper authentication, the report of the inconsistencies related to that maintainer will be mailed back to you.

How To Fix Inconsistencies

The mails sent to maintainers about their inconsistencies contain a table with the following fields:

  1. TYPE: Type of the inconsistency.
  2. OBJECT: Object that is affected, you can query the Whois Database with the contents of this field to view the inconsistent object.
  3. NOTES: Additional notes to assist in the determination of inconsistency.
DUPNIC
Symptom: Contact information for the object is identical to another person / role object.
Treatment: A person object can be referenced by more that one object, which means that one person object is enough to represent a person in the database. Please centralise the references, i.e., replace the references to those person objects with a "NIC-handle" of one of those person objects, and delete the extra person objects in the database which contain the same contact information.
NOTNIC
Symptom: Object doesn't comply to usual "nic handle" notation.
Treatment: Please change the references to the object to point to a valid nic-handle.
NOT_ALLOCATED
Symptom: Object is of status "assigned", but is not inside an allocation.
Treatment: Please contact RIPE NCC Registration Services.
NO_STATUS
Symptom: Object has no "status:" field.
Treatment: Update the "status:" field of the object to reflect its situation.
OVERLAP
Symptom: Object overlaps with another inetnum: object.
Treatment: One of the objects should be deleted, since address spaces can not overlap.
SUSPICIOUS_BOUNDARY
Symptom: The range specified by the object is not likely to represent a network.
Treatment: Please check and correct the boundaries.
UNDESIRED_HIERARCHY
Symptom: Object is an assignment from another assignment.
Treatment: Subsequent levels of assignments should be deleted.
UNREF_MNTNER
Symptom: Object is unreferenced.
Treatment: Unreferenced maintainer (mntner) objects just take up resources. If you do not need it, please delete it from the database.
UNREF_PERSON_ROLE
Symptom: Object is unreferenced.
Treatment: Unreferenced person objects just take up resources. If you do not need it, please delete it from the database.
WRONGREF
Symptom: Object has a reference to an invalid person / role object.
Treatment: The person / role objects must be referred by their "NIC handles", instead of their real names, phone numbers etc, to prevent ambiguity. Please update the object so that it will refer to the person/role by its "NIC handle", and not by real name, phone number etc.
WRONG_ALLOCATED
Symptom: Object is of status "allocated", but should be an assignment.
Treatment: Correct the "status:"field of the object to assigned status.
WRONG_PAPI
Symptom: Object has a wrong "status:" field.
Treatment: Assigned address spaces should have the same PA/PI status with their parents. Check and correct the "status:" field.
NO_MNT_LOWER
Symptom: Object has no "mnt-lower:" field, allowing sub-assignments without authorization.
Treatment: It is recommended to add an "mnt-lower:" field to this object.
WEAK_MNT_AUTH
Symptom: The authentication type of this mntner object is weak (either MAIL-FROM or NONE).
Treatment:
Please change the authentication of the object to PGPKEY or MD5-PW to ensure better protection.