WHOIS DB - Objects and Attributes

1.0 Database objects and attributes

The AFRINIC Network Management Database (often called the "AFRINIC Database") contains records of:

* allocations and assignments of IP address space (the IP address registry);
* contact information (details of people who are responsible for the operation of networks or routers, and those who are responsible for maintaining information in the AFRINIC Database).

  1.1 Object representation

Records in the AFRINIC Database are known as "objects". The syntax of the database objects is defined by RPSL, which is described in [1]. An object belongs to one of the object types, or classes. These two terms are used interchangeably through the document. The following object types are stored in the AFRINIC Database:

  1.2 Object types supported by AFRINIC DB

Table 1 Object types supported in the AFRINIC Database

Object type (Class name)

Abbreviated name

Description

as-block

ak

Represents delegation of a range of AS numbers to a given repository.

as-set

as

Defines a set of aut-num objects.

aut-num

an

Represents an Autonomous System (AS) in the database. Is used to describe external routing policy of the AS.

domain

dn

Represents forward or reverse domain registrations.

inet6num

i6

Contains information on allocations and assignments of IPv6 address space.

inetnum

in

Contains information on allocations and assignments of IPv4 address space.

key-cert

kc

Represents a public key certificate that is stored on the server and may be used with a maintainer object for authentication when performing updates.

limerick

li

Represents a humorous poem that has five lines and the rhyme scheme "aabba".

mntner

mt

Specifies authentication information required to authorise creation, deletion or modification to the objects protected by the mntner.

person

pn

Contains information about technical or administrative contacts.

role

ro

Contains information about technical or administrative contacts, but describes a role performed by one or more human beings.

A database object is defined as a list of attribute-value pairs in text. Each attribute-value pair is written on a separate line. The attribute name starts at column 0, followed by the character " : " and followed by the value of the attribute. The attribute that has the same name as the object's class should be specified first. An attribute's value can be split over multiple lines, by having a space, a tab or a plus ("+") character as the first character of the continuation lines. The character "+" for line continuation allows attribute values to contain blank lines. More spaces may optionally be used after the continuation character to increase readability. The order of attribute-value pairs is significant. An object's description may contain comments. A comment can be anywhere in an object's definition, it starts at the first "#" character on a line and ends at the first end-of-line character. A comment cannot start at column 0. White space characters can be used to improve readability. The object's representation ends when a blank line is encountered.

Attributes can be mandatory or optional: A mandatory attribute MUST be defined for all objects of the class; optional attributes can be skipped. Attributes can also be single or multiple-valued. Multiple-valued attributes may have several attribute-value records in an object, while a single valued attribute may appear only once. Each object is uniquely identified by a set of attributes, referred to as the class primary key.

The value of an attribute has a type, which defines the syntax of the attribute value. Please refer to Appendix A1 "Object attributes" for a detailed description of the attributes supported in the AFRINIC Database.

  2 Object types

This section describes object types (classes) supported in the AFRINIC Database along with the object templates. The following definitions are used in the templates:

[mandatory]

At least one instance of this attribute must be defined in an object of the class.

[optional]

Attribute is optional in the objects of the class and can be omitted.

[generated]

Attribute is automatically generated by the server.

[single]

An object MUST NOT contain more than one instance of this attribute.

[multiple]

An object MAY contain more than one instance of this attribute.

[look-up key]

Attribute is indexed.

[inverse key]

Attribute is in the "reverse" index.

[primary key]

Attribute is (part of) the primary key.

[primary/lookup key]

Attribute is both indexed and is (part of) the primary key.

In an object template the first column represents an attribute, the second and third columns specify the type of the attribute and the fourth column tells whether the attribute is (part of) a database key for the object.

  2.1 as-block

An as-block object is needed to delegate a range of AS numbers to a given repository. This object may be used for authorisation of the creation of aut-num objects within the range specified by the "as-block:" attribute. The template of as-block class is shown in Figure 2.1.

as-block: [mandatory] [single] [primary/lookup key]

descr: [optional] [multiple] [ ]

remarks: [optional] [multiple] [ ]

tech-c: [mandatory] [multiple] [inverse key]

admin-c: [mandatory] [multiple] [inverse key]

notify: [optional] [multiple] [inverse key]

mnt-lower: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.1 as-block template

  2.2 as-set

An as-set object defines a set of aut-num objects. The attributes of the as-set class are shown in Figure 2.2. The "as-set:" attribute defines the name of the set. It is an RPSL name that starts with "as-". The "members:" attribute lists the members of the set. The "members:" attribute is a list of AS numbers, or other as-set names. The name of an as-set object can be hierarchical. A hierarchical as-set name is a sequence of as-set names and AS numbers separated by colons ":". At least one component of such a name must be an actual as-set name (i.e. start with "as-").

as-set: [mandatory] [single] [primary/lookup key]

descr: [mandatory] [multiple] [ ]

members: [optional] [multiple] [ ]

mbrs-by-ref: [optional] [multiple] [inverse key]

remarks: [optional] [multiple] [ ]

tech-c: [mandatory] [multiple] [inverse key]

admin-c: [mandatory] [multiple] [inverse key]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig..2.2 as-set template

  2.3 aut-num

An object of the aut-num class is a database representation of an Autonomous System (AS), which is a group of IP networks operated by one or more network operators that has a single and clearly defined external routing policy.

Objects of this class are used to register as number and specify routing policies. The attributes of the aut-num class are shown in Figure 1.2.3. The value of the "aut-num:" attribute is the AS number of the AS described by this object. The "as-name:" attribute is a symbolic name (in RPSL name syntax) of the AS. As AFRINIC is not running a routing registry yet, the import, export and default attribute (routing policies) are removed in AFRINIC database and should be provided as remarks only.

aut-num: [mandatory] [single] [primary/lookup key]

as-name: [mandatory] [single] [ ]

descr: [mandatory] [multiple] [ ]

member-of: [optional] [multiple] [inverse key]

remarks: [optional] [multiple] [ ] --- put in your routing policy.

admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]

notify: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]

mnt-routes: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Fig. 2.3 aut-num template

  2.4 domain

The domain object represents Top Level Domain (TLD) and other domain registrations. In AFRINIC's case it is ONLY used for Reverse Delegations. The domain name is written in fully qualified format, without a trailing ". The template of this class is shown in Figure 2.4.

domain: [mandatory] [single] [primary/lookup key]
descr: [mandatory] [multiple] [ ]

admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
zone-c: [mandatory] [multiple] [inverse key]

nserver: [optional] [multiple] [inverse key]

sub-dom: [optional] [multiple] [inverse key]

dom-net: [optional] [multiple] [ ]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

mnt-lower: [optional] [multiple] [inverse key]

refer: [optional] [single] [ ]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.4 domain template

  2.5 inet6num

An inet6num object contains information on allocations and assignments of IPv6 address space. The template of this class is shown in Figure 2.5.

inet6num: [mandatory] [single] [primary/lookup key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]

org: [optional] [multiple] [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-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Fig. 2.5 inet6num template

  2.6 inetnum

An inetnum object contains information on allocations and assignments of IPv4 address space. The template of this class is shown in Figure 2.6.

inetnum: [mandatory] [single] [primary/lookup key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]

org: [optional] [multiple] [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-routes: [optional] [multiple] [inverse key]
mnt-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Fig. 2.6 inetnum template

  2.7 key-cert

A key-cert object is a database public key certificate that is stored on the server and may
be used with a mntner object for authentication when performing updates. Currently only
keys compliant with the proposed Open PGP Internet standard [RFC 2440] are supported.
The template of this class is shown in Figure 2.7.

key-cert: [mandatory] [single] [primary/lookup key]

method: [generated] [single] [ ]

owner: [generated] [single] [ ]

fingerpr: [generated] [single] [ ]

certif: [mandatory] [multiple] [ ]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.7 key-cert template

  2.8 limerick

The limerick object represents a humorous poem that has five lines and the rhyme scheme
"aabba". The template of this class is shown in Figure 2.8.

limerick: [mandatory] [single] [primary/lookup key]

descr: [optional] [multiple] [ ]

text: [mandatory] [multiple] [ ]

admin-c: [mandatory] [multiple] [inverse key]

author: [mandatory] [multiple] [inverse key]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.8 limerick template

  2.9 mntner

Objects in the AFRINIC Database may be protected using mntner (pronounced "maintainer")
objects. A mntner object specifies authentication information required to authorise creation,
deletion or modification of the objects protected by the mntner. mntner objects are not created
automatically, but are forwarded to the AFRINIC Database Administration for manual processing.
The template of this class is shown in Figure 2.9. ¹

mntner: [mandatory] [single] [primary/lookup key]

descr: [mandatory] [multiple] [ ]

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] [ ]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.9 mntner template

  2.10 person

A person object contains information about technical or administrative contact responsible
for the object where it is referenced. Once the object is created, the value of the "person:"
attribute cannot be changed. The template of this class is shown in Figure 2.10.

person: [mandatory] [single] [lookup key]

address: [mandatory] [multiple] [ ]

phone: [mandatory] [multiple] [ ]

fax-no: [optional] [multiple] [ ]

e-mail: [mandatory] [multiple] [lookup key]

nic-hdl: [mandatory] [single] [primary/lookup key]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [optional] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.10 person template

  2.11 role

The role class is similar to the person class. However, instead of describing a human being,
it describes a role performed by one or more human beings. Examples include help desks,
network monitoring centres, system administrators, etc. A role object is particularly useful
since often a person performing a role may change; however the role itself remains. The
"nic-hdl:" attributes of the person and role classes share the same name space. Once the
object is created, the value of the "role:" attribute cannot be changed. The template of this
class is shown in Figure 2.11.

role: [mandatory] [single] [lookup key]

address: [mandatory] [multiple] [ ]

phone: [optional] [multiple] [ ]

fax-no: [optional] [multiple] [ ]

e-mail: [mandatory] [multiple] [lookup key]

admin-c: [mandatory] [multiple] [inverse key]

tech-c: [mandatory] [multiple] [inverse key]

nic-hdl: [mandatory] [single] [primary/lookup key]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [optional] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.11 role template

  2.12 organisation

The organisation class provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the whois database. The template of this
class is shown in Figure 2.12.

organisation: [mandatory] [single] [primary/look-up key]
org-name: [mandatory] [single] [lookup key]
org-type: [mandatory] [single] [ ]
descr: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
address: [mandatory] [multiple] [ ]
phone: [optional] [multiple] [ ]
fax-no: [optional] [multiple] [ ]

country: [mandatory] [multiple] [ ]
e-mail: [mandatory] [multiple] [lookup key]
org: [optional] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [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]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]


Fig. 2.12 organisation template

 

This document details the process of registering LIR network infrastructure and customer IP address assignments in the AFRINIC whois database. It is important to register an assignment in any or all of the following cases: 

  • IP addresses have been issued to a customer (or end-site) from your allocation.
  • IP addresses are in use by any section/unit of the LIRs network infrastructure, for example − Office LAN, Dial-UP access server, DSLAM/DSL access server, a WiFi access point(s), WiMAX cell, etc.

The current IPv4 policy requires that 80% of the most recent allocation be verified as efficiently utilised before an LIR can request for more IP addresses. We verify this by looking at the valid registered assignments in the AfriNIC whois database. If they work out to 80% or more, the policy requirement will have been met. If not, AfriNIC asks the LIR to register these assignments before anything else can be done.

The policy also indicates that an additional allocation can be sought if the LIR has an immediate IP address requirement outnumbering the free IPs remaining in the most recent allocation.

 

Recording network assignments

 An assignment is basically an inetnum object, containing a range of 4 or more IP addresses, whose status attribute must have the value "ASSIGNED PA". To create a new inetnum in the database, you can use any of the following methods:

 

1.0 Using MyAFRINIC

To register such address assignment, here's the quick process to do it using MyAFRINIC:

  1. Browse to https://my.afrinic.net
  2. Go to the "Resources" tab and click on "IPv4 Resources"
  3. Click the "+" to expand the target allocation, and select "Add Assignment" and use the resultant form to add any prefix/space from your allocation that has been issued to any internal subnet or any end-user.

Once finished, you may go back to manage your rDNS.

 

2.0 Using e-mail

To get the inetnum template, please use the methods as listed here:

You will get a template that looks something like the following:

inetnum: [mandatory] [single] [primary/lookup key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
org: [mandatory] [multiple] [inverse key]
rev-srv: [optional] [multiple] [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-routes: [optional] [multiple] [inverse key]
mnt-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Copy this template and paste it in your email editor, and replace values using help as follows:

1. Delete everything to the right of the colon and fill in attribute values.

You must complete the attributes listed as mandatory and should delete optional attributes that you do not use. An example is below

inetnum: 10.11.12.0−10.11.12.255

The IP range of your assignments should be inserted here. It may be the range assigned to a dial-up access server, DSL pool or even a customer/end-site.

netname: Example-Network

The netname of this IP range.

descr: short description.

Please duplicate this attribute if more than one line.

country: MU

The country code should be inserted here.

admin-c: ZA4-TEST

The nic-handle of the admin-c

tech-c: ZA4-TEST

The nic-handle of the tech-c

status: ASSIGNED PA

Use ASSIGNED PA

notify: 
This email address is being protected from spambots. You need JavaScript enabled to view it.

Insert the email to which notifications will be sent

mnt-by: EXAMPLE-MNT

Enter your mntner object here

mnt-lower: EXAMPLE-MNT

Enter your mntner object here

changed: 
This email address is being protected from spambots. You need JavaScript enabled to view it.

Enter your email address here.

source: AFRINIC

 

2. When a new object is created that has a "mnt-by:" attribute, the mntner must authorise the creation. Add the appropriate password for the mntner in the "mnt-by:" attribute:

password: your_cleartext_password_here

 

3. Send the completed object template in plain text to auto-dbm[at]afrinic.net using the above example, the template should look like the one below:

notify: 
This email address is being protected from spambots. You need JavaScript enabled to view it.

 

4. Wait for the acknowledgement to come back from the database. If your update was successful you will get a reply containing something like the following:

Your update was SUCCESSFUL.

The following objects were processed.

New OK: [inetnum] 10.11.12.0 - 10.11.12.255

If there was an error, the acknowledgement will indicate failure of the object creation along with the errors encountered. For example, it may contain the following:

Part of your update FAILED.

Objects without errors have been processed.

Update FAILED: Syntax error in object

You need to follow the procedure above in order to register all the different assignments.

Should you require help from us, please write to afrinic-dbm[at]afrinic.net

 

on 2020 Jan 27
Was this helpful?
Date and time in Mauritius -