WHOIS DB

What is Lame Delegation?

A DNS name server is considered lame when it does not adequately respond to DNS queries either by:

  • Not responding at all.
  • Responding in some way, but not for the specific domain queried.
  • Responding to the correct domain, but without the authority bit set.

 

Lame delegations can lead to:

  • Denial of certain services and delays due to DNS malfunctions.
  • Timeouts from unresponsive servers that can increase DNS traffic between caching and authoritative DNS servers, resulting in possible load on infrastructure and increased operating costs.

 

What can a member do to resolve Lame Delegation?

Objects with lame delegations can be corrected or updated:

  • Through MyAFRINIC, under the "Reverse Delegation" tab in the "Resources" Menu.
  • Via the WHOIS server update section of the AFRINIC website - https://www.afrinic.net/services/whois-query
  •  Through e-mail, where the domain objects can be submitted to This email address is being protected from spambots. You need JavaScript enabled to view it. for automatic processing.

 

Members can always contact This email address is being protected from spambots. You need JavaScript enabled to view it. for any additional assistance.

DNS troubleshooting best practices are recommended in RFC 1912 at https://www.ietf.org/rfc/rfc1912.txt

 

on 2018 Sep 18
Was this helpful?

WHOIS DB - Getting Started

 Introduction

This document is intended for users who have no previous experiencewith the AFRINIC Database. It is a hands-on tutorial that walks the reader through the basic concepts and techniques that are needed to use the AFRINIC Database using examples and exercises.

This document is not intended to be a complete reference. Full information on the AFRINIC Database may be found in the AFRINIC Database.

Objectives

This document should give the reader a basic understanding of the following concepts:

  • What the AFRINIC Database is
  • How to get information from the AFRINIC Database
  • How to maintain information in the AFRINIC Database

 

2.1 The AFRINIC Database

The AFRINIC Database is a public database that contains information about registered IP address space and AS numbers, routing policies,and reverse DNS delegations in the AFRINIC region. It is used for Internet network management.

 2.1.1 Database objects

Records in the AFRINIC Database are called "objects". Each object is a list of "attribute-value" pairs displayed in plain text. An example:

  • Person: Zola Abalo
  • Address: Example LTD 12, Akuna Matata Street Flic-en-Flac, MU
  • phone: +230 123 2323
  • e-mail: zola.abalo@example.com
  • nic-hdl: ZA4-AFRINIC
  • mnt-by: AFRINIC-MNT
  • remarks: ************************
  • remarks: This object is only an example!
  • remarks: *************************
  • changed: zola.abalo@example.com 20050127
  • changed: zola.abalo@example.com 20050128
  • source: AFINIC

This is a person object for Zola Abalo. The attributes are "person:", "address:", "phone:", and so on. An attribute name always starts on the first column, and ends with a colon. Everything after the colon is the value.  Objects can store information about different resources. For example:

Network management resource Object types
IP address ranges inetnum,inet6num
Autonomous system number aut-num, route, etc.
Reverse DNS delegations domain
Contact information person, role
Authentication information mntner

2.1.2 TEST Database [not yet available]

The AFRINIC will provide a test database where users may learn how to use the database software. The TEST Database uses the same software as the AFRINIC Database but changes in the TEST Database do not affect the AFRINIC Database. The data in the TEST database is not a copy of the data in the AFRINIC Database and is provided purely for learning purposes.

All examples below use the TEST Database. However all procedures described are the same for the AFRINIC Database. In the last section, we will explain what the differences are when using the AFRINIC Database. Please do not use the AFRINIC Database for testingpurposes. We would also appreciate if you delete all objects you have created in the TEST Database when you have finished performing the exercises described below.

 2.2 How to get information from the AFRINIC Database

  2.2.1 Web queries

The simplest way to get information from the TEST Database is to use a web interface available at: https://www.afrinic.net/en/services/whois-query

  2.2.2 Making simple queries

To query for a particular object the user specifies its "primary key". A primary key is an attribute that uniquely identifies this type of the object.

Object type Primary attribute Example
inetnum inetnum 196.0.0.0-196.0.0.255
inet6num inet6num 2001:0610:0240::/42
person nic-hdl: ZA4-TEST

You will get a reply that includes the object in section 2.1.1.

 2.3 How to maintain information in the AFRINIC Database

The AFRINIC Database is used for storing information about Internet resources. You will need to create objects in the database to document your usage of these resources.

Objects in the AFRINIC Database must reflect the current state of the resources they describe. Therefore, it is also important to update objects as the details of resources change, or delete objects if resources are no longer used. If IP addresses are assigned to customers, or new staff members are appointed as contacts, it is important to create new objects to reflect this in the database.

Updates to the database are submitted via e-mail. Objects to be created, modified, or deleted are sent to a special address where they get processed automatically. A reply is e-mailed back to the sender with the results of the operation. If there are any errors when processing the e-mail submission, the e-mail message mailed back to the sender will include an error report. If the report does not help locate the problem, the sender should forward a copy of the original e-mail and the error report to <AFRINIC-dbm@AFRINIC.net>. An AFRINIC staff member can then help to locate the problem.

The following sections describe the process of creating and maintaining objects in the AFRINIC Database. By the end of the document, you will have learned how to create and protect an object representing a network assignment.

  2.3.1 Creating objects

The inetnum object contains information about registered IP address space: the range of numbers, status, and responsible contacts. Before this object can be created in the database, information that is referenced by this object must be created in the database first. This requires the creation of the following objects: 1. A person object representing a responsible administrative and technical contact for this network, referenced from the "admin-c:" and "tech-c:" attributes of the inetnum object. 2. A mntner object containing authentication information about who can modify contents of this object, referenced from the "mnt-by:", "mnt-lower:", and "mnt-routes:" attributes of the inetnum object. The mntner object protects the inetnum object. 3. After that we can create the inetnum object.

  2.3.2 Registering contact information

Contact information, such as a phone number and e-mail address, is stored in the person object. To create a new person object in the database:

1. Copy the person object template. The template lists the possible attributes in an object and some information about each attribute. To get the template, please use the link below

 You will get a reply that looks something like this:

  • person: [mandatory] [single] [lookup key]
  • address: [mandatory] [multiple] [ ]
  • phone: [mandatory] [multiple] [ ]
  • fax-no: [optional] [multiple] [ ]
  • e-mail: [optional] [multiple] [lookup key]
  • nic-hdl: [mandatory] [single] [primary/look-up key]
  • remarks: [optional] [multiple] [ ]
  • notify: [optional] [multiple] [inverse key]
  • mnt-by: [optional] [multiple] [inverse key]
  • changed: [mandatory] [multiple] [ ]
  • source: [mandatory] [single] [ ]

2. Copy the text into a text editor (e.g. notepad or vi). Delete everything to the right of the colon and fill in attribute values. You must complete the attributes listed as "mandatory." An attribute that is "multiple" can be used more than once in an object. You may choose not to complete the optional attributes. However, if you choose not to include optional attributes, you must delete the optional attribute entirely, rather than leaving the value empty. Use "AUTO-1" for the "nic-hdl:" attribute, your e-mail address for the "changed:" attribute, and "TEST" for the "source:" attribute.

  • person: Zola Abalo
  • address: Example LTD 12, Akuna Matata Street Flic-en-Flac, MU
  • phone: +230 123 2323
  • e-mail: zola.abalo@example.com
  • nic-hdl: AUTO-1
  • mnt-by: EXAMPLE-MNT
  • remarks: *******************************
  • remarks: This object is only an example!
  • remarks: *******************************
  • changed: zola.abalo@example.com 20050127
  • changed: zola.abalo@example.com 20050128
  • source: TEST

3. Send the completed object template in plain text to test-dbm@AFRINIC.net. For real object send the template to auto-dbm@AFRINIC.net

4. Wait for the acknowledgement to come back from the Database. This may take several minutes. 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: [person] ZA4-TEST

Note the text after the [person] tag. This is the NIC handle of the person, and the "AUTO-1" text is changed to this value. It is guaranteed to be unique and is the primary key of this person object. Any references to this person object will use this NIC handle.

You can use the new "nic-hdl:" attribute to query for this object. If you do this, you can also see that the "changed:" attribute has had the date of the creation added.  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

  2.3.3 Registering authentication information

"Authentication" is when you prove that you are who you claim to be. This information is needed to prevent other users from modifying your data. In the database, the information needed for verifying authentication is stored in the mntner object (also called the maintainer object). To create a new mntner object in the database, do the following:

1. Copy the mntner object template. You will get a reply that looks something like the following:

  • mntner: [mandatory] [single] [primary/look-up 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] [ ]

The content of the attributes of the mntner class are defined below:

mntner

A unique identifier of the mntner object.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.

2. As with the person object, 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. Use "TEST-MNT" for the "referral-by:" attribute for test environnment.

3. You must choose your own mntner value, which is EXAMPLE-MNT in the example. This is the rule to follow when choosing mtner value:

  • mntner is a unique identifier of the mntner object. 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 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.
  • use -v option for mntner to have more details

4. For the "admin-c:" and "tech-c:" you should use the value of the "nic-hdl:" in the person object created beforehand. The database will not allow you to create a mntner object unless this person object already exists.

5. The "auth:" attribute begins with a keyword identifying the authentication method and is followed by the authentication information needed to enforce that method. In the example given, the MD5-PW method is used. For both the MD5-PW and CRYPT-PW methods, a password is used to authenticate database operations. To encrypt your password to MD5-PW, you can use the web tools here: https://www.afrinic.net/en/services/ip-tools/whoiscrypt

6. Send the completed object template in plain text to test-dbm@AFRINIC.net for test ennvironment and auto-dbm@AFRINIC.net for real environment.

7. 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: [mntner] EXAMPLE-MNT

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

8. The e-mail address in the "mnt-nfy" attribute of the mntner will be sent an e-mail of the details of the new object. You can now query the server and see your new mntner object. Type the following in the query window, substituting your mntnername:

EXAMPLE-MNT

You will get back your new mntner object, as well as the person object referenced.

  • mntner: EXAMPLE-MNT
  • descr: Sample maintainer for example
  • admin-c: ZA4-TEST
  • tech-c: ZA4-TEST
  • upd-to: zola.abalo@example.com
  • mnt-nfy: zola.abalo@example.com
  • auth: MD5-PW #FILTERED
  • mnt-by: EXAMPLE-MNT
  • referral-by: TEST-MNT
  • changed: zola.abalo@example.com 20020827
  • source: TEST
  • person: Zola Abalo
  • address: Example LTD 12, Akuna Matata Streat Flic-en-Flac, MU
  • phone: +230 123 2323
  • e-mail: zola.abalo@example.com
  • nic-hdl: ZA4-TEST
  • mnt-by: EXAMPLE-MNT
  • remarks: *******************************
  • remarks: This object is only an example!
  • remarks: *******************************
  • changed: zola.abalo@example.com 20050127
  • changed: zola.abalo@example.com
  • source: TEST [must be AFRINIC in real case]

Please note that md5 and crypt hash output is filtered to prevent guessing attacks of the passwords that were used to create the hashes. If you would like to modify a mntner object, please create a new hash of the same plain text password (if you do not have the previous hash handy) and submit your update. Deleting a mntner requires the exact hash used to create it, which you can get by sending an email to hostmaster@afrinic.net.

Also, by default, a query returns the contact information associated with an object. This is why the person object is returned. If you do not want the referral contact information, use the "disable recursion" flag on the query, "-r". You can see this by typing the same query into the query window, putting the flag in front: 

-r EXAMPLE-MNT

Now you will get only the mntner object. Disabling recursion can result in a smaller, easier to understand reply if you do not care about contact information. This is often the case when managing your own objects.

  2.3.4 Protecting your contact information

 Now that you have a mntner, you can protect objects in the database. An object is protected by a mntner if it references the mntner in the "mnt-by:" attribute. Only a mntner listed as "mnt-by:" is authorised to make changes to an object. Most objects types require that you protect them with your mntner. However, person objects do not. It is recommended that you protect them. To protect your person object:

1. Get a copy of your current person object. In the query window type the "nic-hdl:" of your person object:

ZA4-TEST [or ZA4-AFRINIC]

You will get back your current object in the database. You can also search by typing in a name. In this case, the database will return all person objects that have that name. For common names there may be many objects returned.

2. Copy the object returned by the query.

  •  person: Zola Abalo
  • address: Example LTD 12, Akuna Matata Streat Flic-en-Flac, MU
  • phone: +230 123 2323
  • e-mail: zola.abalo@example.com
  • nic-hdl: ZA4-TEST
  • mnt-by: EXAMPLE-MNT
  • remarks: *******************************
  • remarks: This object is only an example!
  • remarks: *******************************
  • changed: zola.abalo@example.com 20050127
  • source: TEST [must be AFRINIC in real case]

3. Add your mntner as the "mnt-by:" for your person object. The database will not allow you to use a "mnt-by:" unless the mntner object already exists.

4. Add a "changed:" line to reflect the fact that you are updating the object.

  • person: Zola Abalo
  • address: Example LTD 12, Akuna Matata Streat Flic-en-Flac, MU
  • phone: +230 123 2323
  • e-mail: zola.abalo@example.com
  • nic-hdl: ZA4-TEST
  • mnt-by: EXAMPLE-MNT
  • remarks: *******************************
  • remarks: This object is only an example!
  • remarks: *******************************
  • mnt-by: EXAMPLE-MNT # new "mnt-by:" attribute
  • changed: zola.abalo@example.com 20050127
  • changed: zola.abalo@example.com # new "changed:" attribute
  • source: TEST [must be AFRINIC in real case]

 5. When you add a mntner to an object that does not have one, you must authenticate yourself as the new mntner. Since the example uses the MD5-PW method, add a password line to your e-mail. This must start on the first column but can occur anywhere within the body of the message: password:

your_cleartext_password_here

6. Send the updated object template to test-dbm@AFRINIC.net (or auto-dbm@AFRINIC.net).

7. Wait for the acknowledgement to come back from the database. It will indicate ssuccess or failure of your update.

 2.3.5 Locating network assignments

Network assignments are represented by inetnum objects. Before you can create a new inetnum you must find a range of IP addresses that are not currently assigned. This section describes how you can query the database for this information. You can also use the queries for any other purpose when you want to get IP address information from the database. By default, the database returns the smallest range that includes the entire range queried. This is a "less specific" query. For example, if you query the following:

10.11.12.0 - 10.11.13.255

You might get something like this:

  • inetnum: 10.0.0.0 - 10.255.255.255
  • netname: IANA-ABLK-RESERVED1
  • parent: 0.0.0.0 - 255.255.255.255
  • descr: Class A address space for private internets
  • descr: See https://www.ripe.net/db/rfc1918.html for details
  • country: NL
  • admin-c: role1-TEST
  • tech-c: role1-TEST
  • status: ALLOCATED UNSPECIFIED
  • remarks: Country is really worldwide
  • remarks: This network should never be routed
  • remarks: outside an enterprise.
  • remarks: See RFC1918 for further information
  • mnt-by: TEST-DBM-MNT
  • mnt-lower: TEST-DBM-NONE-MNT
  • mnt-routes: TEST-DBM-NONE-MNT
  • changed: AFRINIC-dbm@AFRINIC.net 20020902
  • source: TEST [must be AFRINIC in real case]

This is the less specific match. The 10.11.12.0 - 10.11.13.255 inetnum fits entirely within the 10.0.0.0 - 10.255.255.255inetnum. This is the smallest such block. The parent attribute give you the address block from which this inetnum derived from. In a clear term, it gives you the in the same inetnum object what an '-L' option will give you. If you want the server to give you only an exact match, then you can request this using the "-x" flag. An exact match is one where the IP range of the inetnum are the same as the IP range of the query.

-x 10.11.12.0 - 10.11.13.255

In this case you will get only an exact match, or an error indicating that no such inetnum exists:

 %ERROR:101: no entries found

%

% No entries found in the selected source(s).

Sometimes you want to see all of the less specific inetnum to a range. In this case, you can use the "-L" flag. If you do this, you will see all inetnum that include the entire range queried. For example, if you query the following:

 -L 10.11.12.0 - 10.11.13.255

You might get something like this (which is details of the parent line):

  • inetnum: 0.0.0.0 - 255.255.255.255
  • netname: IANA-BLK
  • descr: The whole IPv4 address space
  • country: NL
  • admin-c: role1-TEST
  • tech-c: role1-TEST
  • status: ALLOCATED UNSPECIFIED
  • remarks: Country is really worldwide
  • remarks: This address space is assigned at various
  • remarks: other places in the world.
  • mnt-by: TEST-DBM-MNT
  • mnt-lower: TEST-DBM-NONE-MNT
  • mnt-routes: TEST-DBM-NONE-MNT
  • changed: AFRINIC-dbm@AFRINIC.net 20010418
  • source: TEST [must be AFRINIC in real case]
  • inetnum: 10.0.0.0 - 10.255.255.255
  • netname: IANA-ABLK-RESERVED1
  • parent: 0.0.0.0 - 255.255.255.255
  • descr: Class A address space for private internets
  • descr: See https://www.ripe.net/db/rfc1918.html for details
  • country: NL
  • admin-c: role1-TEST
  • tech-c: role1-TEST
  • status: ALLOCATED UNSPECIFIED
  • remarks: Country is really worldwide
  • remarks: This network should never be routed outside
  • remarks: an enterprise
  • remarks: See RFC1918 for further information
  • mnt-by: TEST-DBM-MNT
  • mnt-lower: TEST-DBM-NONE-MNT
  • mnt-routes: TEST-DBM-NONE-MNT
  • changed: AFRINIC-dbm@AFRINIC.net 20020902
  • source: TEST [must be AFRINIC in real case]

You can also look for smaller inetnum contained within a given range. This is a "more specific" query. You can use this on an allocation to look for ranges that have no other assignments. To do this, use the "-m" flag: -m 10.0.0.0 - 10.255.255.255

You will get a reply that ressembles something like this:

  • inetnum: 10.11.13.0 - 10.11.13.255
  • netname: Example-Network
  • parent: 10.0.0.0 - 10.255.255.255
  • descr: This is a fictitious assignment
  • country: MU
  • admin-c: ZA4-TEST
  • tech-c: ZA4-TEST
  • status: ASSIGNED PA
  • notify: john.smith@example.com
  • mnt-by: EXAMPLE-MNT
  • mnt-lower: EXAMPLE-MNT
  • mnt-routes: EXAMPLE-MNT
  • changed: zola.abalo@example.com 20020827
  • source: TEST [must be AFRINIC in real case]
  • inetnum: 10.11.11.0 - 10.11.11.255
  • netname: Example-Network-2
  • parent: 10.11.13.0 - 10.11.13.255
  • descr: This is a fictitious assignment
  • country: GB
  • admin-c: ZA4-TEST
  • tech-c: ZA4-TEST
  • status: ASSIGNED PA
  • notify: zola.abalo@example.com
  • mnt-by: EXAMPLE-MNT
  • mnt-lower: EXAMPLE-MNT
  • mnt-routes: EXAMPLE-MNT
  • changed: zola.abalo@example.com 20020903
  • source: TEST [must be AFRINIC in real case]

 This is a "one-level more specific" query. This means that the largest inetnum that are within the given range are returned. In this example the IP addresses 10.11.12.0 - 10.11.12.255 are not assigned and are available. You will need to find an available range to be able to do the next exercise. If you want to see all inetnum smaller than a given range, you can use the "-M" flag:

-M 10.0.0.0 - 10.255.255.255

This will return all levels of inetnum in the range. This can return an extremely large number of objects, but can be useful for finding all of the inetnum for a portion of the Internet.

  2.3.6 Recording network assignments

Now that all of the objects necessary for an inetnum have been created and protected and you have located an appropriate range of IP numbers, you can create the inetnum object itself. To create a new inetnum in the database:

1. Copy the inetnum object template.

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

  • inetnum: [mandatory] [single] [primary/look-up key]
  • netname: [mandatory] [single] [lookup key]
  • parent: [Auto generate] [single]
  • descr: [mandatory] [multiple] [ ]
  • country: [mandatory] [multiple] [ ]
  • admin-c: [mandatory] [multiple] [inverse key]
  • tech-c: [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] [ ]

2. 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. Use "ASSIGNED PA" for the "status:" attribute, and your e-mail address for the "notify:" attribute. The e-mail address specified in the "notify:" attribute will get mailed when the object changes. You must choose your own "netname:", using the same rules as you did to choose a mntner name.

  • inetnum: 10.11.12.0 - 10.11.12.255
  • netname: Example-Network
  • descr: This is a fictitious assignment
  • country: MU
  • admin-c: ZA4-TEST
  • tech-c: ZA4-TEST
  • status: ASSIGNED PA
  • notify: zola.abalo@example.com
  • mnt-by: EXAMPLE-MNT
  • mnt-lower: EXAMPLE-MNT
  • mnt-routes: EXAMPLE-MNT
  • changed: zola.abalo@example.com
  • source: TEST [must be AFRINIC in real case]

 Note here that the parent attribute is missing because this attribute is not mandatory and is not store in the Data Base. the parent attribute in generated by the system at query time.

3. 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

4. Send the completed object template in plain text to test-dbm@AFRINIC (or auto-dbm@AFRINIC.net).

5. 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

6. The e-mail address in the "mnt-nfy" attribute of the mntner will be sent an e-mail of the details of the new object.

  2.3.7 Updating the inetnum object

Suppose you later need to update information in your inetnum object. For instance, the technical contact has changed and is now represented by the person object "VA1-TEST". (You must create a new person object before you can follow this example.) To update an existing object, do the following:

1. Query the AFRINIC Database for the object.

10.11.12.0 - 10.11.12.255

2. Copy the object returned by the query without the parent attribute:

  • inetnum: 10.11.12.0 - 10.11.12.255
  • netname: Example-Network
  • descr: This is a fictitious assignment
  • country: MU
  • admin-c: ZA4-TEST
  • tech-c: ZA4-TEST
  • status: ASSIGNED PA
  • notify: zola.abalo@example.com
  • mnt-by: EXAMPLE-MNT
  • mnt-lower: EXAMPLE-MNT
  • mnt-routes: EXAMPLE-MNT
  • changed: zola.abalo@example.com 20020828
  • source: TEST [must be AFRINIC in real case]

3. Change the "tech-c:" attribute. Add a "notify:" attribute so the new technical contact will be notified when the inetnum is modified.

  • inetnum: 10.11.12.0 - 10.11.12.255
  • netname: Example-Network
  • descr: This is a fictitious assignment
  • country: GB
  • admin-c: ZA4-TEST
  • tech-c: VA1-TEST # changed to new nic-hdl
  • status: ASSIGNED PA
  • notify: zola.abalo@example.com
  • notify: victor.aby@example.com # added new notify
  • mnt-by: EXAMPLE-MNT
  • mnt-lower: EXAMPLE-MNT
  • mnt-routes: EXAMPLE-MNT
  • changed: zola.abalo@example.com 20020828
  • changed: zola.abalo@example.com # new changed line
  • source: TEST [must be AFRINIC in real case]

Please note that you cannot change the primary attribute of the object (inetnum: 10.11.12.0 - 10.11.12.255). The database will consider this to be a creation of a new object.

 4. To change an object that is protected by a "mnt-by:" attribute, you must add the appropriate authentication:

password: your_cleartext_password_here

5. Send the updated object template to test-dbm@AFRINIC.net (or auto-dbm@AFRINIC for live data)

6. Wait for the acknowledgement to come back from the database. It will indicate success or failure of your update.

7. The e-mail address in the "notify:" attribute of the original object will be sent a message with the details of the change.

  2.3.8 Deleting objects

 Sometimes you no longer need objects you maintain. These should be deleted. For example, if the assignment is no longer used you should delete the inetnum object and all person objects that are only referenced from that object.

To delete an existing object:

1. Query the database for your object.

2. Copy the object returned by the query without the parent attribute

3. Add a special "delete:" attribute to the object explaining why the object should be deleted. For example:

4. To delete an object that is protected by a "mnt-by:" attribute, you must add the appropriate password:

password: your_cleartext_password_here

5. Send the object to be deleted to test-dbm@AFRINIC.net (or auto-dbm@AFRINIC.net for live data).

6. Wait for the acknowledgement to come back from the database. It will indicate success or failure of your deletion. 

7. The e-mail addresses in the "notify:" attribute of the object will be sent a message with the details of the deletion.Objects that are referenced by other objects cannot be deleted. For example, a mntner object cannot be deleted while is used as an "mnt-by:" or a "mnt-lower:". You can find the references to a mntner object by using an inverse query. Type the following in the query window, substituting your mntner object:

  • -i mnt-by,mnt-lower,mnt-routes -r EXAMPLE-MNT

This will return all of the objects that reference EXAMPLE-MNT. The "-i" flag requests the inverse query, and the "mnt-by,mnt-lower,mnt-routes" specify which attributes you want to look for. There must not be a space after the comma. The "-r" disables recursion, as seen in section 2.3.3. Since an organisation usually uses one mntner, you can use this query to locate all of the objects for an organisation. Before you can delete a mntner, you must remove all references to it. For example, if you have the following mntner and person:

  •  mntner: EXAMPLE-MNT
  • descr: Sample maintainer for example.
  • admin-c: ZA4-TEST
  • tech-c: ZA4-TEST
  • upd-to: zola.abalo@example.com
  • mnt-nfy: zola.abalo@example.com
  • auth: MD5-PW $1$WKwrFYYt$.oop28gKMiamE52SVHjyn0
  • mnt-by: EXAMPLE-MNT
  • referral-by: TEST-MNT
  • changed: zola.abalo@example.com 20020827
  • source: TEST [must be AFRINIC in real case]
  • person: Zola Abalo
  • address: Example LTD 12, Akuna Matata Streat Flic-en-Flac, MU
  • phone: +230 123 2323
  • e-mail: zola.abalo@example.com
  • nic-hdl: ZA4-TEST
  • mnt-by: EXAMPLE-MNT
  • remarks: *******************************
  • remarks: This object is only an example!
  • remarks: *******************************
  • mnt-by: EXAMPLE-MNT
  • changed: zola.abalo@example.com 20050127
  • changed: zola.abalo@example.com 20050128
  • source: TEST [must be AFRINIC in real case]

The mntner "EXAMPLE-MNT" cannot be deleted because it is referenced by the person "ZA4-TEST", and the person "ZA4-TEST" cannot be deleted because it is referenced by the mntner "EXAMPLE-MNT". To delete these objects, do the following:

1. Update the person object, and remove the "mnt-by:" attribute. This removes all protection, but this is not a security issue because the object will be deleted soon.

2. Delete the mntner object.  

3. Delete the person object.

(Please remember to delete all objects you created in the TEST Database while doing these exercises.)

 2.4 Using the production AFRINIC Database

You should now have an understanding of the basic concepts of the AFRINIC Database and be able to maintain your own data and perform queries. This section details the differences between the TEST Database and the AFRINIC Database.

 1. Queries use a different search tool: https://www.afrinic.net/en/services/whois-query

 2. Objects in the AFRINIC Database use AFRINIC instead of TEST for both the "source:" attribute and the suffix appended to "nic-hdl:" attributes.

3. Updates to the AFRINIC Database should be sent to <auto-dbm@AFRINIC.net> rather than <test-dbm@AFRINIC.net>.

 4. You cannot create your own mntner object in the AFRINIC Database. You should send your update to <auto-dbm@AFRINIC.net> but it will be processed by an AFRINIC staff member. mntner objects are only created for users who are referenced as the "admin-c:" or "tech-c:" for inetnum, inet6num, aut-num, or domain objects. 

5. You should not create inetnum objects in the AFRINIC Database unless you have received authorisation by the LIR that holds the responsibility for that address range.

 2.5 Where to learn more

The following resources are available to help you as you use the AFRINIC Database.

  2.5.1 Whois help

A query for "help" will return a full list of all of the flags that you can use to query the database. While some of these have been covered in this document, many have not.

  2.5.3 AFRINIC Database Reference Manual

The definitive source of information for the AFRINIC Database is the AFRINIC Database Reference Manual. The latest version of this is available from the AFRINIC Document Store at: https://www.afrinic.net/en/library/membership-documents/197-database-afrinic-database-reference-manual-

It contains detailed specifications on all of the topics covered in this guide, as well as every aspect of using the AFRINIC Database.

  2.5.4 LIR Training Courses

The AFRINIC provides training for Local Internet Registries. More information about the AFRINIC LIR Training Courses will be available soon.

  2.5.5 Specific questions

If you have a specific question that has not been answered in this guide, you may e-mail your question to <AFRINIC-dbm@AFRINIC.net>

WHOIS DB - Reference Manual

Reviewed for AFRINIC usage by: Adiel Akplogan
Document ID: afsup-dbref200501-Draft
Date: 20 January 2005


Abstract

This document describes the functionality of the AFRINIC Database that uses the Routing Policy Specification Language (RPSL) [1] to represent all Database objects. Though this document tends to be self-contained, the reader is encouraged to read the RPSL [ 1 ] and RPSS [ 2 ] specifications for more detailed information, examples of usage and definitions. For a tutorial on RPSL, the reader should read the RPSL applications document [ 3 ]


Tabel of content

Introduction
   1.0 Queries in the AFRINIC Database
      1.1 Queries using primary and lookup keys
      1.2 IP address lookups
         1.2.1 Default lookup for IP ranges in the AFRINIC Database
         1.2.2 More and less specific queries
      1.3 Inverse queries
      1.4 Getting all the members of set objects
      1.5 More/less specific lookups for in-addr.arpa and ip6.arpa domains
      1.6 Referral mechanism for domains
      1.7 Access control for queries
      1.8 Other server features
   2.0 Updates in the AFRINIC Database
      2.1 Format of an update message
      2.2 Creating, modifying and deleting an object
         2.2.1 Object processing
         2.2.2 Creating a new object
         2.2.3 Modifying an existing object
         2.2.4 Deleting an object
      2.3 E-mail updates
         2.3.1 MIME support
         2.3.2 PGP support
         2.3.3 Subject line processing
      2.4 Updates using networkupdate utility
      2.5 Acknowledgements and Notifications
         2.5.1 Acknowledgements
         2.5.2 Notifications
      2.6 Data protection
         2.6.1 Authorisation model
         2.6.2 Protection of individual objects
         2.6.3 Protection of aut-num object space
         2.6.4 Protection of address space
         2.6.5 Protection of objects with hierarchical names
         2.6.6 Protection of domain object space
         2.6.7 Protecting membership of a set [**]
   3.0 Mirroring of the AFRINIC Database 
   Appendices

Conventions used in this document

Within this document, the following conventions are used:

<label> indicates a placeholder or syntax specification [option] indicate an optional text or command argument.

Please note that in object templates the square brackets "[ ]" are used to specify type of an attribute. "attribute:" indicates an attribute.


Introduction  

The AFRINIC Network Management Database contains information about IP address space allocations and assignments. Routing registry in the AFRINIC region will be performed at this point by RIPE NCC.This Database does not contain any information about Domain Name. Please see the IANA ccTLD Database for a full list of the ccTLD administrators.

The information in the AFRINIC Database is available to the public for agreed Internet operation purposes, but is under copyright. Please see Appendix A3 "Copyright information".

The phrase "AFRINIC Database" is often used to refer to the interface software rather than the information that is stored in the database. In ambiguous situations, this reference manual will make clear what is being discussed.

This document describes the functionality of AFRINIC database (bases on version 3.0 of the RIPE NCC WHOIS). This version uses the Routing Policy Specification Language (RPSL) [1]. It also integrate the Routing Policy System Security(RPSS) [2] to provide authorization mechanisms to enable a higher level of security for the routing registry. Note that this last functionality is not yet used by AFRINIC.

This document is self-contained. However, it does not contain examples of usage and illustrations of principles and concepts related to the AFRINIC Database functionality and implementation. The "AFRINIC Database User's Manual" [5] and the "AFRINIC Database Operations Manual" [5] will fill this gap and provide examples and detailed information on how to interact with the AFRINIC Database and how to configure and run AFRINIC Database server software. The reader is also encouraged to read the RPSL [1] and RPSS [2] specifications for more detailed information, examples of usage and definitions. For a tutorial on RPSL, the reader should read the RPSL applications document [3].

 

1.0 Queries in the AFRINIC Database

This section describes the functionality provided in the AFRINIC Database to enable users to retrieve database objects. Querying the database is done using a client who uses the Whois protocol [12] to query and get the responses.

This database incorporated mechanism to enable the whois server to automatically track query responses and limit the retrieval of contact information from the AFRINIC Database is also described in this section. The intention is to limit non-operational uses of the data (such as advertising) while permitting the operational uses of the database to be carried out.

There is a set of general rules about server responses:

* Output starting with the % sign is either a server response code or an informational message. A comment contains a white space after the % sign, while server messages start right after the % sign. Please see Appendix A2 "AFRINIC Database response codes and messages" for more information.

* An empty line ("\n\n") is an object delimiter.

* Two empty lines mean the end of a server response.

* When using the referral mechanism, the output of the referred server is passed to the client without modification. See section 1.6"Referral mechanism for domains" for more information.

The general format of a query is:

[-query_flags [query argument]] <lookup-key>

1.1 Queries using primary and lookup keys  

Normal queries are performed using primary and lookup keys as an argument to a query. These queries are presented in Table 1 . Please refer to the document "Object types in AFRINIC database " for primary and lookup keys definition for a class.

1.2 IP address lookups  

Probably, the most important service provided by the AFRINIC Database is to provide information about IP networks in the Internet. This information is stored in the database in the form of inetnum.

The inetnum and inet6num store information about ranges of IP addresses.

For IPv4, the prefix is a 32-bit integer written in dotted quad notation and having the value of the lowest IP address in the range. The prefix length is an integer number in the range 0-32 (e.g. 193.0.0.0/22 specifies the range of 1024 IPv4 addresses starting with, and including, 193.0.0.0).

The inetnum objects represent an IPv4 address space in range notation where the range is explicitly specified as two 32-bit integers written in dotted quad notation separated by a dash ("-") (e.g. 93.0.0.0-193.0.3.255, which specifies the same range as above).

When dealing with IPv6 address ranges, only the standard IPv6 prefix notation is allowed (prefix length must be in the range 0-128 and the prefix is a 128-bit integer, written in hexadecimal groups of 2 bytes separated by colons and with the possible use of shorthand notation for strings of consecutive 0s).

When querying the database for information about a range of IP addresses, the user can use as search keys the following range notations:

* a prefix, which has the same meaning as above;

* an explicit range, also as above;

* a single IP number, which when used as an argument to a query is interpreted as a range of exactly 1 address.

These types of queries are presented in Table 2 . The remainder of this section describes how a user can request different types of information to be returned, relative to a particular range of IP addresses.

Before going into details, it is useful to define three concepts frequently used in this type of queries and which are defined relative to the user-specified (reference) range:

* A less specific range is a range that contains the whole of the reference range and is bigger (contains more IP addresses) than the reference range.

* A more specific range is a range contained within the reference range and contains less IP addresses than the reference range.

* An exact match refers to a range that is identical to the reference range.

1.2.1 Default lookup for IP ranges in the AFRINIC Database 

When no flags are specified and the query key sent to the whois server is a range of IP addresses (either IPv4 or IPv6, expressed as a single IP address, two IP addresses separated by a hyphen ("-") or a range of IP addresses in prefix notation), the AFRINIC whois server will try to find an exact match for that range.

If an exact match is found, it is returned. If not, a lookup for the smallest less specific range is performed and this is returned.

1.2.2 More and less specific queries 

Sometimes the exact match is not the desired information. In that case there is a set of flags that modify the response of the whois server. This set of 4 flags ("-M", "-m", "-L" and "-l" ) provides two generic types of queries known as more and less specific queries.

1.2.2.1 Less specific queries 

These refer to queries triggered by the use of the "-l" and "-L" flags. These queries will return information about ranges of IP addresses that fully contain the user-supplied range and may contain more addresses.

The "-L" flag requests that the server return the exact match, if any, and all the objects containing information about IP ranges that are bigger than the user-supplied range and fully contain it.

The "-l" flag requests that the server NOT return the exact match but only the smallest of the IP ranges that is bigger than the user-supplied range and that fully contains it. This is usually referred to as the one level less specific range.

1.2.2.2 More specific queries 

These refer to queries triggered by the use of the "-m" and "-M" flags. These queries will return information about ranges of IP addresses that are fully contained in the user-supplied range and contain fewer addresses.

The "-M" flag requests that instead of returning the exact match, the server should return all the sub-ranges completely contained within the user-provided range no matter what their size is.

The "-m" is the more specific equivalent of the "-l" flag. It requests that instead of returning the exact match, the server should return sub-ranges that are fully contained within the user-provided range. But instead of reporting all existing sub-ranges, it will only return the biggest ranges contained in the user range. These are usually called one level more specific.

1.3 Inverse queries 

Inverse queries are performed on inverse keys as defined in the AFRINIC Database object templates. For a complete listing of these templates, please refer to the document "Object types in AFRINIC database". By issuing this type of query, the client requests all objects that reference

the object with the key specified as a query argument to be returned by the Database. One can also request an inverse query for several attributes (e.g. find out which objects reference a specific mntner object by "mnt-by:", "mnt-lower:" attributes).

In such case, the query flag should be represented by a comma-separated list of attributes to be searched. No white space is allowed in the list.

Please refer to Table 4 for a complete list of supported inverse queries.

1.4 Getting all the members of set objects 

In RPSL[3] there are two ways in which an object can be a member of a set object.

The first one is by listing objects in a "members:" attribute in the set object. This is the kind of member relationship present in "Representation of IP Routing Policies in a Routing Registry"[4] (e.g. "as-list:" attribute in as-macro objects).

The other way of specifying a membership relation is through the use of the "member-of:" attribute. This attribute can be used in the route, aut-num and inet-rtr classes. The value of the "member-of:" attribute identifies a set object that this object wants to be a member of.

However, specifying member-of is not enough. The set object must also have a "mbrs-by-ref:" attribute listing the maintainer of the object wanting to be a member of the set. That is, the set owner must validate the membership claim of an object with a "member-of:" attribute, and it does that by matching the mnt-by line of the object with one of the maintainers in the "mbrs-by-ref:" attribute of the set object.

1.5 More/less specific lookups for in-addr.arpa and ip6.arpa domains 

AFRINIC Database supports IP lookups including the "-x", "-m", "-M", "-l" and "-L" functionality for reverse delegation domains. To request that reverse delegation domains are to be looked up, use the "-d" flag in your Whois IP lookup query.

1.6 Referral mechanism for domains 

The referral mechanism provides a way for administrators of domain registries to instruct the whois server to reply to the user by fetching data from the domain registry database rather than from local data. Its implementation consists of two different parts:

1. Domain name stripping: When no matching domain object is found in the database with the name specified in the query, the domain name is stripped towards higher-level domains (xxx.yyy.zzz becoming yyy.zzz) and the lookup is repeated until a domain object is found or the search string becomes empty.

For backwards compatibility, if the domain object found by domain stripping does not contain a "refer:" attribute, then it is considered that no objects are found and an appropriate message is displayed. Please see Appendix A2 "AFRINIC Database response codes and messages" for more information.

2. The "refer:" attribute: The "refer:" attribute gives domain name administrators the possibility to point the whois server to an authoritative server for information about the domain name. This attribute specifies the hostname, port and referral type that the server should use to redirect the query. Please see Appendix A1 "Object attributes" for the syntax of this attribute.

If a query to the whois server results in the retrieval of a local object that contains a "refer:" attribute, the server will connect to the remote server and issue a whois query for the requested domain name. Whatever is returned is then sent to the user. This mechanism is disabled by including the "-R" flag in the original query.

1.7 Access control for queries 

This section describes the mechanism for controlling how many database objects a particular whois client can retrieve from the whois server. The objective is to control and prevent abusive use of the Database done by systematic queries for contact information potentially used for non-agreed purposes (e.g. spam).

Therefore, the access control system is limiting only the amount of contact information (number of person and role objects) that can be retrieved in a certain amount of time. No limitations exist on the number of other objects.

However, one should keep in mind that many lookups for object types, other than person and role, also return contact information by default. To avoid being blocked in such cases, it is advisable to use the "-r" query flag.

Every time a person or role object is retrieved, a counter is decreased. When it reaches zero, the query execution is aborted and the connection is terminated, displaying an error message to the client (see "Access errors" in Appendix A2 "AFRINIC Database response codes and messages"), also a counter of exceeds (denials) is incremented. The Database may limit the number of denials, after which the host is permanently blocked from access to the AFRINIC Database. The Database Administration may also block a client

manually in case any abusive behaviour is discovered.

The counter recovers in time. The host can resume querying contact information after the counter has recovered so that the host gets a non-zero limit for contacts next time. Accounting is based on the IP address of a client.

The AFRINIC Database server provides a facility for proxy clients (for example, web servers running cgi interfaces to the AFRINIC Database) that allows accounting to be based not on the IP address of the proxy, but rather of the clients that use this proxy to query the AFRINIC Database. The "-V" flag supports this feature. In such case, the format of the query is as follows:

-V <version>,<ipv4-address>

where

<version> is a client tag that usually represents the software version that the proxy uses;

<ipv4-address> is the IPv4 address of the client that queries the Database using the proxy.

Note that the proxy's IP address should be registered in the access control list of the AFRINIC Database. Please contact AFRINIC Database Administration if you need this option.

1.8 Other server features 

The AFRINIC Database server supports the retrieval of certain information about itself and the data sets served using a "-q" query flag.

The "-q " flag takes arguments that make the server reply with information that is not extracted from the Databases it serves but rather about the system setup. This flag can currently take two arguments:

* version (usage: -q version). Display version information for the server software.

* sources (usage: -q sources). List all available sources. The

format of the output is:

< source>:<NRTM_protocol_version_#>:<mirroring>:<first>-<last>

Where

<source> - is the string that identifies the Database

(e.g. AFRINIC); <NRTM_protocol_version_#> identifies the version of the mirroring protocol.

<mirroring> can take one of the following values:

-- Y/N/X - can mirror/cannot mirror/obscured

<first> is the lowest serial number available

<last> is the most recent serial number available.

The following semantics apply:

Y:<first>-<last> mirroring allowed, serials from range first-last available.

N:<first>-<last> mirroring not allowed for administrative reasons. Ask Database Administration for permission.

N:0-<last> mirroring physically not possible (e.g. static snapshot of serial last).

X:<message> no mirroring allowed. An explanation is given in the <message>.

Tables 1 to 6 contain all query types supported by the AFRINIC Database:

 Table 1    Queries using primary and lookup keys

Flag

Lookup Key(s)

Effect

 

<ip-lookup> (IPv4 address prefix, range or single address)

Returns 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 a single address is specified, an inet-rtr object whose "ifaddr:" attribute matches the query argument is also returned.

 

<ip-lookup> (IPv6 address or IPv6 prefix)

Returns an inet6num object with exact match on a specified key. If the exact match does not exist, the object with the smallest less specific match is returned.

 

<as-number>

Returns an 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> (range of <as-number> separated by "-")

Returns an as-block object whose primary key defines a range that matches or fully contains the range specified in the query argument.

 

<domain-name>

Returns domain and inet-rtr objects whose primary keys match the query argument. For domains, a referral query may be performed. In such case the actual query is performed by the referred server and the results are transparently passed to the client. See section 2.7 "Referral mechanism for domains" for more information.

 

<irt-name>

Returns an irt object whose primary key matches the query argument.

 

<Person-name>

Returns all person and role objects whose "person:" or "role:" attributes contain the name specified in the query argument.

 

<set-name>

Returns a set whose primary key matches the query argument.

 

<nic-handle>

Returns a person or role object whose "nic-hdl:" attribute matches the query argument.

 

<mntner-name>

Returns a mntner object whose primary key matches the query argument.

 

 Table 2    IP address lookups

Flag

Lookup Key(s)

Effect

-l

<ip-lookup>

Returns first level less specific inetnum , inet6num or route objects, excluding exact matches.

-L

<ip-lookup>

Returns all level less specific inetnum , inet6num or route objects, including exact matches.

-m

<ip-lookup>

Returns first level more specific inetnum , inet6num or route objects, excluding exact matches.

-M

<ip-lookup>

Returns all level more specific inetnum , inet6num or route objects, excluding exact matches.

-x

<ip-lookup>

Requests that only an exact match on a prefix be performed. If no exact match is found, no objects are returned.

-d

<ip-lookup>

Enables lookups on reverse delegation domains. Can be used with "-x", "-m", "-M", "-l" and "-L" flags.

-c

<ip-lookup>

Returns the smallest, less specific inetnum or inet6num object containing the reference to an irt object. The result of this lookup is an inetnum or inet6num object and referenced contacts, if name recursion is not disabled ("-r" flag). It does not contain the referenced irt object, nor contact information about the team. Please refer to [11] for more information about the irt object.

 

 Table 3    Inverse queries

Flag
(alternative form)

Lookup Key(s)

Effect

-i ac
(-i admin-c)

<nic-handle> or
<person-name>

Returns all objects whose "admin-c:" attributes match the query argument.

-i ah
(-i author)

<nic-handle> or
<person-name>

Returns all limerick objects whose "author-c:" attribute matches the query argument.

-i pn
(-i person)

<nic-handle> or
<person-name>

Returns all objects whose "admin-c:", "tech-c:", "zone-c:", "author:" or "cross-nfy:" attribute matches the query argument.

-i ct
(-I cross-mnt)

<mntner-name>

Returns all route and aut-num objects whose "cross-mnt:" attributes matches the query argument.

-i cn
(-i cross-nfy)

<nic-handle> or
<person-name>

Returns all route and aut-num objects whose "cross-nfy:" attribute matches the query argument.

-i iy
(-i irt-nfy)

<e-mail>

Returns all irt objects whose "irt-nfy:" attribute matches the query argument.

-i la
(-I local-as)

<as-number>

Returns all inet-rtr objects whose "local-as:" attribute matches the query argument.

-i mi
(-i mnt-irt)

<irt-name>

Returns all inetnum and inet6num objects whose "mnt-irt:" attribute matches the query argument.

-i mr
(-i mbrs-by-ref)

<mntner-name>

Returns all set objects ( as-set , route-set and rtr-set ) whose "mbrs-by-ref:" attribute matches the query argument.

-i mo
(-i member-of)

<set-name>

Returns all 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
(-i mnt-by)

<mntner-name>

Returns all objects whose "mnt-by:" attribute matches the query argument.

-i ml
(-i mnt-lower)

<mntner-name>

Returns all objects whose "mnt-lower:" attribute matches the query argument.

-i mn
(-i mnt-nfy)

<e-mail>

Returns all mntner objects whose "mnt-nfy:" attribute matches the query argument.

-i mu
(-i mnt-routes)

<mntner-name>

Returns all aut-num , inetnum and route objects whose "mnt-routes:" attribute matches the query argument.

-i ny
(-i notify)

<e-mail>

Returns all objects whose "notify:" attribute matches the query argument.

-i ns
(-I nserver)

or  (IPv4/IPv6 address)

Returns all domain objects whose "nserver:" attribute matches the query argument.

-i or
(-i origin)

<as-name>

Returns all route objects whose "origin:" attribute matches the query argument.

-i rb
(-i referral-by)

<mntner-name>

Returns all mntner objects whose "referral-by:" attribute matches the query argument.

-i rz
(-i rev-srv)

or  (IPv4/IPv6 address)

Returns all inetnum and inet6num objects whose "rev-srv:" attribute matches the query argument.

-i sd
(-i sub-dom)

<domain-name>

Returns all domain objects whose "sub-dom:" attribute matches the query argument.

-i tc
(-i tech-c)

<nic-handle> or
<person-name>

Returns all objects whose "tech-c:" attribute matches the query argument.

-i dt
(-i upd-to)

<e-mail>

Returns all mntner objects whose "upd-to:" attribute matches the query argument.

-i zc
(-i zone-c)

<nic-handle> or

<person-name>

Returns all objects whose "zone-c:" attribute matches the query argument.

 Table 4    Query support for tools

Flag

Lookup Key(s)

Effect

-F

 

Produces output using shorthand notation for attribute names. Produces slower responses.

-K

 

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

(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. Note that the server implements a "stop-and-wait" protocol, where 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.

-g

(mirroring request)

Request a NRTM stream from the server. See section 4.0 "Mirroring of the RIPE Database" for more information.

Table 5    Miscellaneous queries

Flag Argument

Effect

-R

 

Switches off use of the referral mechanism for domain lookups, so that the database returns an object in the RIPE database with the exact match with the lookup argument, rather than doing a referral lookup.

-r

 

Switches off recursion for contact information after retrieving the objects that match the lookup key.

-T

(comma separated list of object types, no white space is allowed)

Restricts the types of objects to lookup in the query.

-a

 

Specifies that the server should perform lookups in all available sources. See also "-q sources" query.

-s

(comma separated list of sources, no white space is allowed)

Specifies which sources and in which order are to be looked up when performing a query.

Table 6    Informational queries

Flag

Argument

Effect

-q

sources

Returns the current set of sources along with the information required for mirroring. See section 2.9 "Other server features" for more information.

-q

version

Displays the current version of the server.

-t

<object-type>

Requests a template for the specified object type.

-V<client-tag>

 

Sends information about the client to the server.

-v

<object-type>

Requests a verbose template for the specified object type.

The following notations are used in this table:

<object-type> means full or abbreviated name of a specific class;
<client-tag> is a string without a white space that usually bears the name of the client's software.

Please refer to section 2.8 "Access control for queries" for more information about using this flag for proxy clients. Other notations are explained in Table A1.

2.0 Updates in the AFRINIC Database 

To create a new object, update an existing one, or delete an object from the AFRINIC Database, an update message should be sent to the Database for processing. Two types of submissions are possible:

* Updates via e-mail which is the main public interface, and on-line;

* Updates via "networkupdate" interface. This method is internal, and is only used from authorised nodes; typically, nodes belonging to the internal office LAN of the AFRINIC.

2.1 Format of an update message 

If sending the message via e-mail, the message may also be a MIME encoded message. The update is normally in plain text. In the former case, each valid MIME part is treated as a separate message. The update message may contain more than one object. Please see section 2.3.1 "MIME support" for more information.

In an update message an object should be textually represented as a list of attribute-value pairs. Each attribute-value pair is written on a separate line. The attribute name starts at column 0, followed by character ":" and followed by the value of the attribute. The attribute, which 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. No empty attributes (an attribute with empty value) are allowed, unless the type of an attribute value is <free-form>. Object definition starts with the

class attribute and ends with the first blank line ("\n\n"). No blank lines are allowed within the object.

An object's definition may contain comments. A comment can be anywhere in an bject'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.

For more information on the format of the objects, please see document "AFRINIC Database bjects and attributes".

Each part of the message that is not recognised as a database object is ignored and the error message is issued in the acknowledgement.

2.2 Creating, modifying and deleting an object 

To create, update or delete objects, a message containing the objects should be prepared following object templates and sent to the database for processing. One message may contain several objects, each of them may require different operation: creation, modification or deletion.

2.2.1 Object processing 

As a general rule, the order of objects in the message is not changed. The database processes objects one by one, so it is the user's responsibility to ensure that all references can be resolved. The only exception is related to using "AUTO" NIC handles for automatic assignment of a value for the "nic-hdl:" attribute in the person or role objects. In such cases, objects with "AUTO" NIC handles are processed before any other object that can reference them is processed.

While processing an object, the server performs the following checks:

* Verifies that the syntax of an object is correct.

* Verifies that the object passes authorisation checks.

* Verifies that all references can be resolved without conflicts.

* Verifies that the operation does not compromise referential integrity. This is performed for the deletion of an object to ensure that it is not referenced from any other object in the AFRINIC Database.

* Verifies that the requested NIC handle is not in use and can be allocated. This is performed only for the creation of person or role objects that request a particular NIC handle.

If all checks were passed successfully, the server creates the object in the AFRINIC Database. If one of these steps fails, the operation fails for the object. This is reflected in the acknowledgement message and, under certain conditions, in notification messages.

After the database finishes processing the whole message, an acknowledgement message is composed and sent to the sender of the original update as specified in the "Reply-to:" field or "From:" field in the update message, if "Reply-to:" was not specified.

Also in some cases, notification messages are sent. Please see section 2.5.2 Notifications" for more information.

2.2.2 Creating a new object  

If an object with the same primary keys as the object in the update message does not exist in the database, the assumed operation is object creation. For person and role objects creation, one can use "AUTO NIC handles", requesting the server to automatically assign a NIC handle. In such case, the value of the "nic-hdl:" attribute should be:

nic-hdl: AUTO-1[<initials>]

If the <initials> (2 to 4 characters) are specified, then the server will try to use them for constructing the NIC handle. If the <initials> are omitted, the server will guess the initials from the "person:" or "role:" attribute.

2.2.3 Modifying an existing object 

If an object with the same primary keys as the object in the update message already exists in the database, the assumed operation is object modification. The server compares the old and new versions of the object and reports a no-operation error if they are identical. When comparing the versions, white space characters are not considered.

2.2.4 Deleting an object 

The object deletion is requested by adding a special attribute "delete:" to the object:

delete: <comment>

The deletion is only accepted if the object in the message is exactly the same as the one in the database about to be deleted. When comparing the versions, white space characters are not considered. Also, operation cannot succeed if the object is referenced from any other objects in the Database.

2.3 E-mail updates 

A mail message containing an update should be sent to the e-mail address of the AFRINIC Database robot: auto-dbm@AFRINIC.net. After processing the message, an acknowledgement is sent back to the user, containing information about which object updates succeeded and which failed, along with the reason for failure. In some cases notification messages are sent to relevant users. Please see section 3.5.2 "Notifications" for more information.

2.3.1 MIME support 

The Database software supports MIME. This feature is meant mainly to make the cryptographic signing of the message easier when using mail agents that place the signature in a separate MIME part, not included in the body of the message.

It also allows the definition of scopes of authorisation within the message (e.g. parts where different passwords apply) and nested signing of messages which may be necessary under some conditions when updating objects whose authorisation must be derived from more than one party.

The following rules apply when submitting updates using MIME encapsulation.

A. The software recognises the following headers and appropriate actions are taken:

* multipart/signed
* multipart/alternative
* multipart/mixed
* multipart/unknown
* application/pgp-signature
* text/plain

All other content-types are treated as text/plain.

B. Each MIME part is treated as a separate message with the following implications:

* Authorisation information is valid only within a single part, except for MAIL-FROM type, which is valid across the entire message.

* AUTO NIC handle assignment is made only within a single part (see next section 2.3.2 "PGP support").

2.3.2 PGP support 

The Database supports PGP-signed messages. The following rules apply when submitting updates using this authorisation scheme.

When using MIME encapsulation a PGP-signed portion of an update message should be submitted using multipart/signed composite type. In this case the first body part contains the update message (which may also be a MIME encapsulated message), and the second body contains a PGP-signature encapsulated with application/pgp-signature MIME discrete type. Regarding AUTO NIC handle assignment, the PGP-signed portion is treated as a separate message. If one of the signatures fails in a nested signed portion, the whole portion is rejected.

2.3.3 Subject line processing 

The three keywords valid in a subject line of an update message are NEW, HELP and HOWTO. Use NEW keyword by itself if you want the database to only accept new objects. HOWTO and HELP keywords can be used to get a help text that contains information about how to query and update the database (in this case the body of the message is ignored). If there is more than one keyword or there is a non-keyword in the subject line, then all the subject line is ignored.

2.4 Updates using networkupdate utility 

No MIME encapsulation is possible when using networkupdate. No PGP authentication is possible when using networkupdate.

2.5 Acknowledgements and Notifications 

2.5.1 Acknowledgements  

Processing of every valid object in the submission message (that is every object in plain text parts, supported MIME parts and/or valid PGP signed portions) is reflected in the acknowledgement message. This message contains information about whether the creation, modification or deletion has been successful or not. When there is a MIME part with an unsupported type in the incoming message, a warning will be added to the acknowledgement, saying that that MIME part is ignored. The acknowledgement message is sent back to the sender's e-mail address ("Reply-To:" or "From:", if the former is not specified).

The acknowledgement message starts with the header of the original update message as a quotation followed by the results of the updates performed for every valid object of the message.

The format of a successful operation report is:

<operation_name> OK: [ <object_type> ] <object_key>

where

<operation_name> may be New, Update, Delete, depending on the operation performed.

<object_type> is the class of the object that was processed.

<object_key> is the primary key of the object.

For example:

Update OK: [person] FOO12770-AFRINIC

Failed updates are reported as:

<operation_name> FAILED: [ <object_type> ] <object_key>

followed by the text of the object with more detailed explanation of what caused the failure.
There are several reasons why the operation may fail for the object. They are:

* syntax error
The submitted object is syntactically incorrect. Please consult Appendix A1 for the description of attributes.

* referential integrity violation
If an object references objects (by means of "admin-c:", "tech-c:", "zone-c:", "mnt-by:", etc. attributes) that do not exist in the database, creation or modification operations will fail. For the deletions, it is not allowed to delete an object that is referenced from any other object.

* authorisation failure
When authorisation checks fail, the operation fails. Please refer to section 2.6 "Data Protection" for more information.

2.5.2 Notifications 

There are three types of notifications:

* normal notifications
* forward messages
* cross notifications.

2.5.2.1 Normal notifications  

Normal notifications are sent:

* when an object with a "notify:" attribute is updated. The "notify:" attribute of the old version of the object is used if the object was already in the database, and the "notify:" attribute of the new object is used if the object is a new one.

* when an object that is maintained (that is, it has a "mnt-by:" attribute) is updated, and the maintainer(s) have "mnt-nfy:" attributes. The e-mail boxes mentioned in the "mnt-nfy:" attributes of the relevant maintainers must be used.

* When an inetnum, route or a domain object is created in a space protected by a less specific object (by "mnt-lower:" attribute of the object).

* when a reference to an irt object is added to or removed from an inetnum or inet6num object (by means of "mnt-irt:" attribute), and the irt object contains an "irt-nfy:" attribute(s). The e-mail boxes mentioned in the "irt-nfy:" attributes are used.

2.5.2.2 Forward messages 

When an update fails to pass authorisation checks, that object in the update message is forwarded to the e-mail address specified in the "upd-to:" attribute of the relevant maintainer(s).

2.5.2.3 Cross notifications 

Cross notifications are sent:

* when a new or deleted route object overlaps with another route object. A notification will be sent to the sender of the route object.

* When a new or deleted route object overlaps with another route object that has a "cross-nfy:" or "cross-mnt:" attribute. Notification must be sent to the "mnt-nfy:" attributes of the maintainers mentioned in the "cross-mnt:" attribute and to the "e-mail:" attributes of the person and role objects whose NIC handle is mentioned in the "cross-nfy:" attribute of the overlapping route objects.

* When a new or deleted route object overlaps with another route object whose "origin" is an aut-num object that has "cross-nfy:" or "cross-mnt:" attributes. Notification must be sent to the "mnt-nfy:" attributes of the maintainers mentioned in the "cross-mnt:" attribute and to the "e-mail:" attributes of the person or role objects whose NIC handle is mentioned in the "cross-nfy:" attribute of the aut-num object.

2.6 Data protection  

The AFRINIC Database provides mechanisms to control who can make changes in the database and what changes they can make. The distinction of "who" vs. "what" separates authentication from authorisation.

* Authentication is the means to determine who is attempting to make a change.

* Authorisation is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.

Different portions of the database require different levels of protection. Some pplications require authentication based on strong encryption. In other cases strong encryption may not be necessary or may not be legally available. For this reason, multiple authentication methods are supported by the server.

2.6.1 Authorisation model 

The mntner objects serve as a container to hold authentication filters. A reference to a maintainer within another object defines authorisation to perform operations on the object or on a set of related objects. Such reference is provided by means of the "mnt-by:", "mnt-lower:", "mnt-routes:" and "mbrs-by-ref:" attributes. The maintainer contains one or more "auth:" attributes. Each "auth:" attribute begins with a keyword identifying the authentication method followed by the authentication information needed to enforce that method.

When submitting an update that requires authorisation from a mntner, authentication information valid for that mntner should be supplied. Different methods require different authentication information, as will be shown below.

Authentication methods currently supported include the following:

Method / Description

NONE

No authorisation checks are performed.

MAIL-FROM*

This is a very weak authentication check and is discouraged. The authentication information is a regular expression over ASCII characters. The maintainer is authenticated if the "From:" field in RFC 822 mail headers are matched by this regular expression. Since mail header forgery is quite easy, this is a very weak form of authentication.

CRYPT-PW

This is a relatively weak form of authentication. The authentication information is a fixed encrypted password in UNIX crypt format. The maintainer is authenticated if the transaction contains the clear text password of the maintainer. Since the password is in clear text in transactions, it can be captured by snooping. The encrypted form of the password is no longer displayed in the output of a query,in order to protect it from password guessing attacks. Authentication information is supplied using a "password:" pseudo-attribute. The value of this attribute is a clear-text password. It can appear anywhere in the body of the message, but not within mail headers. Line continuation is not allowed for this attribute.

MD5-PW

This scheme is based on the MD5 hash algorithm and provides stronger authentication than CRYPT-PW. The authentication 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 8-character salt and an almost unlimited passphrase, this scheme is more stable against dictionary attacks. The encrypted form of the password is filtered from whois query output to protect it from cracking attacks. Authentication information is supplied using a "password:" pseudo-attribute. The value of this attribute is a clear-text passphrase. 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 the key gets split across multiple lines this will be treated as a syntax error.

PGPKEY

Strong form of authentication. The authentication information is a signature identity pointing to a public key certificate, which is stored in a separate object. The maintainer is authenticated if the transaction is signed by the corresponding private key. AFRINIC does not guarantee that a key belongs to any specific entity; it is not a certificate authority. Anyone can supply any public keys with any ownership information to the database and these keys can be used to protect other objects by checking that the update comes from someone who knows the corresponding secret key.

* MAIL-FROM authentication scheme is not valid in the AFRINIC Database.

2.6.2 Protection of individual objects  

Individual objects can be protected with a mntner object. The mntner is referenced by the "mnt-by:" attribute in the object. The attribute type is multiple, so several mntners can protect the object. Only those mntners referenced by the "mnt-by:" attributes are authorised to modify or delete the object. Note that authentication checks are OR-ed, so if at least one mntner is authenticated, the operation is authorised. That means that object protection is as weak as the weakest authentication method used in the mntners referenced by the 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 authentication checks for the mntner(s) referenced by this attribute.

2.6.3 Protection of aut-num object space 

Protection of aut-num object space is done using an as-block class. The mntner that authorises the creation of more specific as-block objects or aut-num objects is specified by the "mnt-lower:" attribute of the as-block object. When no "mnt-lower:" attribute is specified, the "mnt-by:" attribute is used.

2.6.4 Protection of address space 

Address space allocations and assignments are represented by the inetnum and inet6num objects. The "mnt-lower:" attribute is used to reference a mntner that authorises the creation of more specific inetnum or inet6num objects. When no "mnt-lower:" attribute is specified, the address space is unprotected.

2.6.5 Protection of objects with hierarchical names 

Many RPSL objects do not have a natural hierarchy of their own but allow hierarchical names. Some examples are the object types as-set and route-set. An as-set may have a name corresponding to no naming hierarchy such as "AS-Foo" or it may have a hierarchical name of the form "AS1:AS-BAR". When a hierarchical name is not used, authorisation for objects such as as-set and route-set corresponds to the rules for individual objects described in section 3.6.2 "Protection of individual objects".

If hierarchical names are used, then the addition of an object must be authorised by the object whose key is named by everything to the left of the rightmost colon in the name of the object being added.

Authorisation is determined by first using the "mnt-lower:" maintainer reference or, if absent, by using the "mnt-by:" reference.

2.6.6 Protection of domain object space 

Protection of the domain object space is done with the "mnt-lower:" attribute. When used in the domain object, this attribute references the mntner that authorises the creation of domain objects directly below in the domain tree registered in the AFRINIC Database. For example, a top-level domain object (ccTLD) protects the creation of the second-level domain objects, third-level domain objects if there is no corresponding second-level domain object, etc. Note that the top-level domain object (ccTLD or gTLD) cannot be created in the AFRINIC Database by users, only by the Database administrator.

2.6.7 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 updating an object-member. This "member-of:" attribute can be used in the route, aut-num and inet-rtr classes. The value of the "member-of:" attribute identifies a set object that this object wants to be a member of.

However, specifying "member-of:" is not enough. The set object must also have a "mbrs-by-ref:" attribute listing the maintainer of the object wanting to be a member of the set. That is, the set owner must validate the membership claim of an object with a "member-of:" attribute, and it does that by matching the mnt-by line of the object with one of the maintainers in the "mbrs-by-ref:" attribute of the set object. If the claim is not valid at the time when the server creates or modifies an object-member (route, aut-num or inet-rtr), the operation fails. If the "mbrs-by-ref:" attribute is missing, the set is defined explicitly by the "members:" attribute.

3.0 Mirroring of the AFRINIC Database 

Near real time mirroring (NRTM) is a mechanism that enables whois servers, other than the primary for a given database, to have an up to date copy of all the data in the main server by getting modifications as they are processed by the main server.

Periodically (defined by configuration, usually around every 15 minutes) the remote server connects to the main server and requests all the modifications that have been processed since the last connection. When all the data is retrieved the connection is closed, until it is time for a new connection.

In AFRINIC Database the NRTM server listens on a port that is different from the whois port (43).

The AFRINIC whois server generates a sequence number every time it processes an update in the database. For the purpose of generating this serial numbers, the server describes all modifications to the database in terms of two atomic operations: deletion and addition.

When sending data to a mirror server, the main server will send one of two strings (ADD or DELETE) followed by two newline characters and the corresponding object (either the object as it was before deletion or the object as it should be added or modified). If the "ADD" string is followed by an object already existing in the database, then this operation is considered as a modification. Near real time mirroring is requested with the "-g" flag. The arguments to this flag are:

-g < source> :<NRTM_Protocol_version_#>:<first>-<last>

where

* <source> is the string that identifies the Database (e.g. AFRINIC).

* <NRTM_protocol_version_#> a version of the mirroring protocol that the <source> supports (2 for AFRINIC).

* <first> is the lowest serial number requested.

* <last> is the most recent serial number requested or the keyword LAST that tells the main server to send all updates up to the most recent one available at the time of the query. Note that the server will never yield the last object processed, or display that it is available for mirroring. This is done to protect secondary servers in case the last update causes database corruption and server crash.

A client may request a persistent connection by including the "-k" flag with a mirroring request ("-g" query). In this case, the last argument is ignored and the new objects are supplied by the server as soon as they are processed. The client is responsible for closing the connection.

The "-q sources" flag may be used with the mirror server to retrieve information regarding available mirroring possibilities. Please see section 2.9 "Other server features" for more details.

Note that the server never returns the latest serial when serving a mirroring request. So, if the latest serial causes a server crash and database corruption, it never propagates to the secondary servers. The latest serial is not displayed with the "-q sources" query as well.

At the beginning of the data stream, the main server will send the following string:

%START Version: NRTM_Protocol_version_# source first-last

For example: %START Version: 2 AFRINIC:1539595-1539597

After the last piece of data is sent to the mirror server, the main server will send the string:

%END source to signal the end of transmission.

For example:

%END AFRINIC

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

 

WHOIS DB - Publishing Abuse Contact Information

1) Introduction

The AFRINIC  Board  has  recently  ratified  a  policy  proposal  (AFPUB-­‐2010-­‐GEN-­‐006)  which  specifies  a dedicated object to be used by AFRINIC members to publish information about the contacts responsible for addressing abuse inquiries from the number resources which the member is issued. This policy was implemented by AFRINIC on 05 May 2012. Previously, it has not been possible to explicitly declare abuse contacts for AfriNIC Whois resource data.


Although the referral to the IRT object is optional in the resources objects, AFRINIC encourages all members to actively start making use of this policy to publish abuse contact information. This chiefly ensures that complaints from anyone about abuse issues emanating from a given number resource are redirected to the appropriate individual(s).
This document recommends guidelines that concerned organizations could use while making use of this policy to avail contact persons responsible for network abuse related queries pertaining to their IP addresses and other number resources.

 

2) Specifying Abuse Contacts

The “irt” (Incident Response Team) Whois database object has been introduced for the purposes of availing abuse contact information for any given number resource.
IRT objects provide information about a CSIRT (Computer Security Incident Response Team), which is basically a group of individuals responsible for handling network security incidents and reports for any given organization or entity.

 

3) Adding the IRT to the Whois database

Once created/formed by the members or concerned organization, the following information about an IRT should be available before attempting to create the object:

  • Name of the Incident Response Team. 
  • Physical address, telephone and fax contacts. 
  • E-­‐Mail address: An e-­‐mail address for contacting the IRT. This should be a role email address which delivers e-­‐mail to several individuals in the IRT. It should not be any one
  • individual’s e-­‐mail address. This is such that if one individual is not available, another can receive and act on the issue.
  • Abuse E-­‐Mail Address: A specific e-­‐mail address to which all security incidents should be sent. This should also be a role e-­‐mail address that delivers to several individuals.
  • Administrative contact: The person(s) handling admin matters for the IRT.
  • Technical contact: The person(s) handling technical matters for the IRT.

The IRT Whois database template

 

4) Using PGP with the IRT object

“Signature” and “encryption” attributes in the IRT object require PGP keys. PGP key can also be used as authentication scheme in the object. Although PGP use is optional in the IRT object, we strongly recommend its usage when managing IRT data.

PGP is the preferred method of use for secure e-­‐mail communication. In order to send secure communication to the IRT and for the IRT to send out secure communication, it is necessary to use PGP by creating “key-­‐cert” objects in the Whois database, which are basically public keys to be used for this purpose.

The public key in the “signature” attribute is for authenticating all correspondence from the Incident Response Team (IRT), while the key in the “encryption” attribute is for encrypting correspondence to the IRT.

As associating the IRT object to the resources objects requires the authentication through the authentication scheme of the IRT object, using PGP avoids sharing the IRT password with resources holders/maintainers

 

5) Finding abuse contacts for resources in AFRINIC Whois

Anyone using AFRINIC database to look for abuse contacts for resources allocated by AFRINIC should use contact information from the IRT object associated to the concerned objects before proceeding as described at https://www.afrinic.net/Registration/spam.htm.

 

6.0 Assistance & Additional Information

Please address any issues or concerns to hostmaster@afrinic.net

 

 

WHOIS DB FAQs

AFRINIC doesn't provide geolocation services and has no control over how this information is obtained from other databases. But please send us a snapshot of the site showing the wrong information and we will try our best to help you.

on 2018 Mar 10
Was this helpful?

If you are having challenges updating an object in the database, you may want to re-examine the way your email is formed. Recent research we conducted indicates that people encounter challenges while interacting with our auto-dbm robot because of how their e-mail is formed. Please always ensure that the content of your email is in plaintext (no formatting at all before submitting to This email address is being protected from spambots. You need JavaScript enabled to view it.).

on 2018 Mar 10
Was this helpful?

AFRINIC and RIPE NCC are two different WHOIS databases. Objects in AFRINIC database will have the suffix "-AFRINIC" while in RIPE will have the suffix "-RIPE". So, the objects can't be used interchangably and you must create your own objects at each one separately.

on 2018 Mar 10
Was this helpful?

The RIPE NCC database does not synchronise with the AFRINIC database. In this regard, there is a need to register the person, maintainer & aut-num objects on the RIPE NCC database before our members can register their route objects.

on 2018 Mar 10
Was this helpful?

Create and verify a person object

A person object contains information about technical or administrative contact responsible for the object where it is referenced. Each object has a unique Nic-handle attribute ("nic-hdl:"). Nic-handle is a unique identifier of a PERSON object. Whenever a PERSON object is referenced in another database object, it is referenced by its Nic-handle and not by the person’s name. Once the object is created, the value of the "person:" attribute cannot be changed.


Note: An auto-generated mntner object will be added in person objects which do not have a "mnt-by" attribute. The password of the auto-generated mntner will be sent to the email address(es) specified in the person object at the time of creation.

Follow the steps below:

  • On the AfriNIC Whois Web Interface, click on "Create Object" tab.
  • You will have to load the person object template into the web whois client. To do this, tick the checkbox next to "person" and click on "Load"

6

  • The person object template will load as below.

7

  • Fill in the information that is mandatory, an example is shown below:

8

  1. "person" -Specifies the full name of an administrative, technical or zone contact person for other objects in the database. (e.g. person: John Smith)
  2. "address" -Full postal address of a contact
  3. "phone" -Specifies a telephone number of the contact.
  4. "e-mail" - The e-mail address of a person, role or organisation.
  5. "nic-hdl" - This will be auto-filled with AUTO-1, which will be replaced with a system generated NIC-HDL upon creation.
  6. "changed" - You will need to specify the e-mail address of the person who submitted the update
  7. "source" - This will be auto-filled with AFRINIC and should not be changed.
  8. You may add other attributes by using ‘drag-n-drop’ method into the template text area.
  9. Click on “Create” when you have filled in all the mandatory attributes
  • After successful creation of the Person object, you shall get the message below which would include the "nic-hdl". In this example the nic-hdl is JS42-AFRINIC.

5

  • The password of the auto-generated mntner will be sent to the e-mail address(es) specified in the "e-mail" attribute(s). You will need to provide this password when updating/deleting the person object.10
  • You may query the Whois to verify the Person object. E.g "-rB john smith" or "-rB JS42-AFRINIC".
on 2018 Mar 10
Was this helpful?

Create and verify a person object

A person object contains information about technical or administrative contact responsible for the object where it is referenced. Each object has a unique Nic-handle attribute ("nic-hdl:"). Nic-handle is a unique identifier of a PERSON object. Whenever a PERSON object is referenced in another database object, it is referenced by its Nic-handle and not by the person’s name. Once the object is created, the value of the "person:" attribute cannot be changed.


Note: An auto-generated mntner object will be added in person objects which do not have a "mnt-by" attribute. The password of the auto-generated mntner will be sent to the email address(es) specified in the person object at the time of creation.

 

Follow the steps below:

  • On the AfriNIC Whois Web Interface, click on "Create Object" tab.
  • You will have to load the person object template into the web whois client. To do this, tick the checkbox next to "person" and click on "Load"

create person object 6

  • The person object template will load as below.

create person object 7

  • Fill in the information that is mandatory, an example is shown below:

create person object 8

  1. "person" -Specifies the full name of an administrative, technical or zone contact person for other objects in the database. (e.g. person: John Smith)
  2. "address" -Full postal address of a contact
  3. "phone" -Specifies a telephone number of the contact.
  4. "e-mail" - The e-mail address of a person, role or organisation.
  5. "nic-hdl" - This will be auto-filled with AUTO-1, which will be replaced with a system generated NIC-HDL upon creation.
  6. "changed" - You will need to specify the e-mail address of the person who submitted the update
  7. "source" - This will be auto-filled with AFRINIC and should not be changed.
  8. You may add other attributes by using ‘drag-n-drop’ method into the template text area.
  9. Click on “Create” when you have filled in all the mandatory attributes

 

  • After successful creation of the Person object, you shall get the message below which would include the "nic-hdl". In this example the nic-hdl is JS42-AFRINIC.

create person object 5

  • The password of the auto-generated mntner will be sent to the e-mail address(es) specified in the "e-mail" attribute(s). You will need to provide this password when updating/deleting the person object.

    create person object 10

  • You may query the Whois to verify the Person object. E.g "-rB john smith" or "-rB JS42-AFRINIC".

 

on 2018 Mar 10
Was this helpful?

Choose a new password and encrypt it as BCRYPT using this link. Then send the encrypted password to This email address is being protected from spambots. You need JavaScript enabled to view it. requesting for mntner password update.

on 2018 Mar 10
Was this helpful?

AFRINIC whois database is a public database which is open for anyone to use. If your person object (nic-hdl) is not protected then anybody can alter it. We advise you to create personal maintainer or use your organisation maintainer to protect your object.

Note: As from the 31st of August 2017, an individual auto-generated maintainer object was linked to all the unprotected person and role objects. The passwords were sent by e-mail to the email address(es) in the person/role object.

on 2018 Mar 10
Was this helpful?

There are two methods to query the whois database:

  1. The AFRINIC Whois web interface which can be accessed here.
  2. Command Line Interface: using whois client which can be downloaded from here.
on 2018 Mar 10
Was this helpful?

 

The AFRINIC Whois Database is an official record that contains information regarding organisations that hold IP addresses and AS Numbers in the African region. The database is public and users can query it to determine who is responsible for an IP address range or an AS Number.

on 2018 Mar 10
Was this helpful?

Membership Fees for End Sites are collected for three (3) years on the anniversary of the membership period. However, End Sites members may elect to be billed for a period of not less than 12 months at a time. AFRINIC is reviewing the possibility of End Sites membership fees to an annual basis.

 

For End Sites ASN only, the Membership fee shall be collected for three (3) years in the first instance and subsequently every six (6) years.

on 2018 Mar 10
Was this helpful?

Creating a key-cert object

A key-cert object holds the public part of your key in the Whois Database. To use the key you just generated in the AFRINIC Database, you should create it in the form of a key-cert object.

Note that first you will have to generate a gpg key pair on your computer. Use any GPG tool of your choice, in this example we are using GPGTools on Mac OS X. The step to generate the Key depends on the tool being used and might differ from the example.

Follow the steps below to create a key-cert object:

  1. On your terminal: $ gpg --gen-key and follow the instructions.
    faq create keycert object 1
  2. faq create keycert object 1 2
  3. faq create keycert object 1 3A
  4. PGP key with ID 7C943FC1 has been created.
  5. Export your key to a text file: $gpg -a --export “key-ID” > gpg_key
    WHOIS7
  6. Prepend the certif attribute to every line of your key as illustrated below;
    WHOIS8
  7. Load the key-cert object template into the whois web client;
    WHOIS9
  8. The key-cert object template will be shown. Fill the object template with specific data and replace the “certif:” attribute with the entire contents of the modified public key above. Your template should look something like this: (you have to protect the object using an exising mntner that typically uses MD5 and supply the password of that mntner)
    WHOIS10
  9. After successful creation of the key-cert object, you shall get the screen below;
    WHOIS11

 

on 2018 Mar 25
Was this helpful?

 How to Update/Delete Unprotected Object on Afrinic Whois.

Update/Delete an Unprotected Object

An unprotected object is one which can be modified or deleted without any authentication method. It is recommended to protect individual objects with a mntner object. The mntner is referenced by the "mnt-by:" attribute in the object (creation of mntner object is not explained on this page).

Note: After it has been created, the “person:” attribute cannot be updated. Same applies for the “role:” attribute. To update these attributes, you will have to delete the object and re-create it with the new value.

 

Follow the steps below to update an Unprotected object:

 

  1. Search for and load the object you want to update. On the Afrinic Whois client, click on "Query" tab. Type in the object you are looking for, click on the Checkbox next to "I'm not a robot", select the appropriate images and click on "Verify". After the human check is completed, click on "Search".
    WHOIS37
  2. Hover your cursor over the "Serch Result" and click on "Update".
    WHOIS38

 

3. In the example below we will update the address and add a second phone number.

WHOIS39

4. After the changes has been made, click on "Submit". You should see "Object Successfully Update!" below;

WHOIS40

 

5. You may query the Whois to verify the Person object. E.g the query "-rB john smith" now gives the output below;

 

WHOIS41

 

Follow the steps below to delete an Unprotected object:

 

Note that if the object is referenced in another object, you must first de-reference it from the object by modifying the object that contains it to remove the primary key of the object you want to delete. For example, you cannot delete a person object if it is still referenced in a role object, you must first modify the role object, remove the primary key of the person object, then you can delete the person object.

 

  1. Search for and load for modification the object you want to delete.
  2. Hover your cursor over the "Serch Result" and click on "Delete".
  3. You will get the screen below, enter your comment in the "Reason for Deletion" field at the bottom and click on "Delete".
    WHOIS42
  4. If ever the object is referenced in another object, you will get the error message "Oh! You got an error!".
    WHOIS43
  5. You must first de-reference it from the object by modifying the object. You need to do an inverse query with the 'primary key'(E.g JS37-AFRINIC) to find the other object.
  6. After you have de-referenced the object from the other object, perform step 3 again after which you will the "Object successfully deleted" message.
    WHOIS44

 

on 2018 Mar 25
Was this helpful?

A mntner object is a whois database object that will contain the credentials needed to authorise creation, deletion or modification of any objects that it protects. The update is usually done by a person, who therefore shall have the credentials (password, PGP key or X.509 certificate). Objects are protected by a mntner, and they shall contain a reference to the mntner usually in the form of mnt-xxx (examples are mnt-by, mnt-lower, mnt-routes, mnt-domains etc)

 

Follow the steps below:

  • Generate the BCRYPT hash of your password. Use the tool at https://www.afrinic.net/en/services/ip-tools/whoiscrypt
  • Note: The clear text password will be required whenever you update objects that are protected by the maintainer. Please retain this password, if the maintainer belongs to your organisation, please ensure that it forms part of your organisation's password policy.
  • Load the mntner object template into the whois web client
  • The mntner object template will be shown.
  • Fill and submit the object template with specific data. (If in doubt what to fill for a specific attribute value, hover your cursor over the templates' attributes on the right for more details)

 

  1. The "mntnr" attribute is a unique identifier of the mntner object. Recommended format is three words separated by hyphens(e.g AFRINIC-JS42-MNT)
  2. The "descr" attribute: A short description of the mntner object and the name of the organization associated with it.
  3. The "admin-c:" attribute: The NIC-handle of an on-site contact 'person' object.
  4. The "upd-to:" attribute: The email address to be notified when attempts to update objects protected by the mntner is rejected due to a lack of authentication.
  5. The "auth:" attribute: Scheme used to authenticate update requests. Available options are BCRYPT and PGP key(Accepted format BCRYPT-PW <your_bcrypt_hash> or PGPKEY-<your_pgp_key_id>)
  6. The "mnt-by" attribute use the same as "mntner" field.
  7. Fill in "password" field with your clear text password.
  8. complete the "changed:" attribute with the email and date of the person making the changes (e.g. changed: This email address is being protected from spambots. You need JavaScript enabled to view it.20130731). If the date is not specified, it will be system generated.
  9. The "source" field is already filled for you.
  10. Click on "Create" when all the required attribute values have been filled.
  • After successful creation of the Mntner object, you shall get the screen below;
  • You may query the Whois database to verify the Maintainer object. E.g the query "AFRINIC-JS39-MNT" with the "-rB" flags will output the current version of the object in the database.

 

on 2018 Mar 25
Was this helpful?

The AFRINIC whois database is a public database and we recommend that all the objects therein are protected (usually by a maintainer object) to prevent unauthorised modifications.

 

It is recommended that all objects are protected. This is done using a mntner(maintainer) object. Practically, this means that in a certain object – such as a person – you refer to this mntner with the "mnt-by:" attribute. Follow the steps in the "Create a Mntner Object" page if you have not yet created a mntner object.

Note: In the new Whois Database version 2.3, person and role objects which at the time of creation do not have a "mnt-by" attribute, will have an auto-generated mntner which will protect the object. The password of that maintainer will be sent to the email address(es) specified in the "e-mail:" attribute(s) upon creation of the object.

 

Follow the steps below to protect your objects from unauthorised modifications:

  1. Search for and load the object you want to protect. On the AfriNIC Whois client, click on "Query" tab. Type in the object you want to protect, click on the Checkbox next to "I'm not a robot", select the appropriate images and click on "Verify". After the human check is completed, click on "Search".
    16
  2. Hover your cursor over the "Serch Result" and click on "Update".
    17
  3. In the example below, we will protect the Person object with the mntner AFRINIC-JS39-MNT. Drag the "mnt-by" from the template on the right into the text area and add the mntner. You will need to enter the clear text password of the maintainer at the bottom before submitting.
    18
  4. You should see "Object Successfully Update!"
    19
  5. You may query the Whois to verify the Person object. E.g the query "-rB john smith" now gives the output below;
    20 
on 2018 Mar 25
Was this helpful?

CREATE ROUTE OBJECT – AFRINIC WHOIS Database

To begin with go to: https://afrinic.net/whois

  1. Click on “Create Object”
  2. Select “route” to specify the type of object you want to create.
  3. Click on “Load” to load the route object template.

WHOIS23

 

The route object template will load. Fill in the information that is mandatory, an example is show below:

WHOIS24

Refer to the next page for more details on the route object attributes.

 

Description of Attributes Specific to the Route Object

(1) “route:” – This specifies the IPv4 or IPv6 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(in CIDR notation).

(2) “descr:” - A short description related to the object.

(3) “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 must already exist in the AFRINIC Database.

(4) “mnt-by:” – Specifies the maintainer of your organization to protect the route object. In most cases the “mnt-by” will be same as the “mnt-lower” in the inetnum/inet6num and the “mnt-routes” in the aut-num object. You may identify the mnt-lower/mnt-routes by querying the AFRINIC Whois(https://whois.afrinic.net/) with your inetnum/inet6num or ASN.

(5) “changed:” - The email address of the person creating/updating the route object.

(6) “source:”– This is already filled for you.

(7) Password – You will need to specify the password in clear-text of the maintainer specified as the “mnt-by”.

(8) You may add other attributes by ‘drag-n-drop’  into the text area;

(i) “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).

(ii) “org:” – the ORG-HDL of the organisation responsible for this resource.

(iii) “member-of:” – This attribute identifies a set object that this route object wants to be a member of.

(iv) “aggr-mtd:” – This attribute specifies how the aggregate is generated.

(9) Click on “Create” when you have filled in all the mandatory attributes and provided the maintainer password.

 

Note: You may hover your cursor on the attributes in the right-pane to get more details and information on the syntax to be used.

WHOIS25

 

Special Cases

There are certain cases in which you will not be able to create routes objects:

Case 1: AS numbers not existing in the AFRINIC’s database and belonging to a third party

In this case, please contact AFRINIC via e-mail to This email address is being protected from spambots. You need JavaScript enabled to view it..

 

Case 2: AS numbers existing in the AFRINIC’s database and belonging to a third party.

In this case, it will be better to ask the organisation who has been assigned the ASN to create the route object for you as their aut-num object will be having a mnt-lower or mnt-routes which must authorise creation of routing information.

 

on 2018 Mar 25
Was this helpful?

Protecting your data

This document provides recommendations on how to use the various methods available to AFRINIC Database users to enable protection of data against unauthorised deletion or modification (and in some cases also against unauthorised creation). Obtaining your maintainer object other objects, by sending an e-mail to auto-dbm@AFRINIC.net.

When using a maintainer to protect your data, you will have to choose one or more of the available authentication methods. These are defined in the "auth:" attributes of the mntner object. You can have any combination of the different methods and as many instances of each as you wish in a mntner object. However, be aware that authentication is a logical 'OR' of all the supplied instances of the "auth:" attributes values. Authorisation is passed when any one of the "auth:" attributes values
match any one of the credentials supplied in an update.

 

Three authentication methods are currently available:

 

BCRYPT-PW:

This method takes an argument consisting of a bcrypt-hashed password.

When requesting a mntner object, the user must include an "auth:" attribute with a value corresponding to a Unix style encrypted password and the BCRYPT-PW keyword:

 

auth: BCRYPT-PW

When submitting an update by e-mail to create, modify or delete an  object protected by a maintainer using this method, the message sent to the database server must include a line containing: "password:"

This pseudo attribute must be in the body of the e-mail message. If it is a multipart mime message it must also be in the same mime part as the  object. Other than these restrictions, it may appear anywhere in the  message in relation to the objects. It only needs to appear once in the  message even if the update contains several objects protected by the  same maintainer.

If this password, when hashed, matches the one stored in the mntner  object, the update will be allowed. Otherwise it will be refused.

We recommend you to use the Whois Crypt tool to generate a BCRYPT-PW password. bcrypt is not vulnerable to rainbow tables or  brute-force attacks and it is unbroken to date. However, it is crucial  that you choose a good password that is not easy to guess. Note that  there are two types of attacks:

* Password cracking. An attacker might guess the password either by  checking it against dictionaries or by trying all possible combinations.

* Mail snooping. As the update message contains the password in  clear text, there is a chance that the password will be seen if the  message is intercepted in transit between the user's system and the  database server machine. To avoid that, you might want to use PGP or X509 (see below).

 

Important:

Please note that CRYPT-PW and MD5-PW are now deprecated. As such they  may not be used in new DB objects or any future updates. For the time  being, existing CRYPT-PW or MD5-PW secured maintainer objects can still  be used for authentication. Future releases of the WHOIS DB may remove  support completely. If you have a CRYPT or MD5 protected password in your maintainer object, please update it to a BCRYPT-PW as soon as possible.

 

PGPKEY:

This is one of the strongest protection methods available. The user specifies a PGP key-id pointing to a key-cert object in the database that stores a PGP public key.

When sending updates to the database, the user must sign the message using his/her PGP private key. The database software will check the signature using the public key stored in the key-cert object referenced in the "auth:" attribute of the relevant mntner object. If the cryptographic signature is correct,  the update will proceed, otherwise it will be refused.

Note: This type of usage of PGP is considered as commercial use by PGP Inc. A commercial software license must be obtained if PGP software is used. Alternatively users may utilise the GnuPG software to generate and manage keys that are compatible with PGP software.

 

Note: AFRINIC makes no claims about the identity of the owner of the PGP key used. It just checks that the signature in the e-mail message was made using the private key corresponding to the public key  stored in the database.

Read more about PGP Authentication in AFRINIC Database

 

X.509:

This method too is one of the strongest protection methods available. The user specifies an X.509 certificate pointing to a key-cert object in the database that stores an X.509 certificate public key.

When sending updates to the database, the user must sign the message using his/her X.509 certificate private key. The database software will check the signature using the public key stored in the key-cert object referenced in the "auth:" attribute of the relevant mntner object. If the cryptographic signature is correct the update will proceed, otherwise it will be refused.

Note1: AFRINIC makes no claims about the trust path of the certificate or of the revocation status of the certificate. It just checks that the signature in the e-mail message was made using the private key corresponding to the public key stored in the database.

Note2: At this point AFRINIC does not provide tool for Certificate Generation. If you don't already have one, you will have to generate a self signed certificate for yourself.

Read more about how to setup a X.509 authentication

 

Simultaneous Use of Several Authentication Schemes

It is enough to match only one of the "auth:" attributes in the mntner object in order to update an object.

We recommend using only one type of authentication method in one mntner object. It should be the strongest type practical for the user.

The best possible protection method is to have either PGPKEY or X.509 authentication. If, for whatever reason, a user does not feel comfortable with only PGPKEY or X.509 and prefers to leave a "backdoor", please use CRYPT-PW or MD5-PW as an addition, choosing a good password. For daily operations,
always apply a signature to the updates.

 

More information

For a complete description of how to interact with the AFRINIC Database, including data protection, please see the following documents:

* AFRINIC Database Reference Manual
* All AFRINIC Database documentation

An empty template can be obtained using a whois client pointed to whois.AFRINIC.net

PGP Authentication

The key-cert object is used for storing PGP public keys on the server. The object template has the following attributes:

key-cert:       [mandatory]  [single]     [primary/look-up 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]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

The "key-cert:" attribute is defined as PGPKEY-XXXXXXXX where XXXXXXXX is the PGP key ID of the public key included in the object in the usual eight digit hex format without "0x" prefix.

The public key should be supplied in the "certif:" attributes. Usually this is easily done by exporting the key from your local key ring in ASCII armored format and prepending each line of the key with a string "certif:". Remember to include all the lines of the exported key and also the "Begin" and "End" markers and the empty line which separates the header from the key body.

The attributes marked as generated ("method:", "owner:" and "fingerpr:") are generated by the software. They may be omitted by the user when supplying a key. The software will then derive these attributes from the actual key and a warning will be added to the acknowledgement message informing the user that these attributes have been added. If they are included, the software will still derive them and compare the derived values with the supplied ones. If there are any differences, the derived values will replace the incorrect ones supplied. Another warning will be added to the acknowledgement about the replacement.

The other attributes have their usual meanings as defined in the AFRINIC Database Reference Manual. This is an example of a valid key-cert object as it might appear in the database:

key-cert: 	        PGPKEY-4B8AE00D 
method: 		PGP 
owner: 		Zola Abalo  
fingerpr: 	        9D 82 4B B8 38 56 AE 12 BD 88 73 F7 EF D3 7A 92 
certif: 		---BEGIN PGP PUBLIC KEY BLOCK--- 
certif: 		Version: 2.6.3ia 
certif: 
certif: 		mQA9AzZizeQAAAEBgJsq2YfoInVOWlLxalmR14GlUzEd0WgrUH9iXjZ 
certif: 		a/uqWiLnvN59S4rgDQAFEbQeSm9lIFRoZSBVc2VyIDxqb2VAZXhhbXB 
certif: 		iQBFAwUQNmLN5ee83n1LiuANAQFOFQGAmowlUYtF+xnWBdMNDKBiOSy 
certif: 		YvpKr05Aycn8Rb55E1onZL5KhNMYU/gd 
certif: 		=nfno 
certif: 		---END PGP PUBLIC KEY BLOCK--- 
mnt-by: 		EXAMPLE-MNT 
changed:  	        zola.abalo@example.net 19981117 
source: 		AFRINIC 

If you do not already have a maintainer (mntner) object to be used in the mandatory "mnt-by:" attribute, you need to create a new mntner with some other authentication method (for example MD5-PW), then create the key-cert object which references the maintainer just created. After that, you can change the maintainer to use PGP authentication with the key-cert object as an authentication key. These key-cert objects can be queried in the usual ways by searching for a specific key as defined in the "key-cert:" attribute or using the inverse option with -i fingerpr.

AFRINIC does not guarantee that a key belongs to any specific entity; we are not a certificate authority. Anyone can supply any public keys with any ownership information to the database and these keys can be used to protect other objects by checking that the update comes from someone who knows the corresponding secret key.

Please also note that signatures in the keys are ignored. We kindly ask you to limit the number of key signatures to a minimum.

 

Use in the maintainer object

PGP authentication can be activated by setting the value of an "auth:" attribute to PGPKEY- where 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 no security advantage in using PGP authentication with an object which can also be updated with a crypted password authentication.

If you specify a non-existent key-cert object, or someone else's key-cert object, you will have locked your mntner. You will then have to contact afrinic-dbm@afrinic.net for assistance to unlock 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: 		ZA4-RIPE 
upd-to:   		zola.abalo@example.net 
auth: 		PGPKEY-4B8AE00D 
mnt-by: 		EXAMPLE-MNT 
changed:   	zola.abalo@example.net 19981117 
source: 		AFRINIC 

 

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 PGP-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 only be used with updates submitted by e-mail (and not through MyAFRINIC for example).

 

Legal issues

Please note that encryption technology is subject to legal restrictions in some countries. PGP signatures are based on public key encryption. Consult a lawyer if you are uncertain about your local situation.

 

More information:

 

X509 Authentication supporting document

Introduction

You can use X.509 authentication with all the methods of sending updates to the Whois Database. Whichever method you use you will need to have a certificate and private key. If you already have a certificate issued by another Certificate Authority you can use that. If not and you are an LIR you can create one with RIPE NCC as AfriNIC do not run CA yet. Otherwise you will have to generate a self signed certificate for yourself. AfriNIC implementation of X.509 for signing updates to the Whois Database is not concerned with the trust path of a certificate. The certificate is only used to store the public key in a key-cert object to match your private key. No account is taken of certificate revocation lists. This is why a self-signed certificate will work well for the purposes of signing database updates.

If you wish to send your updates from a mail client that supports S/MIME, you can import your certificate into the mail client and use it to sign the update messages. If your preferred mail client does not support S/MIME, you can sign messages from the command line using OpenSSL and cut and paste the signed message into the mail client's compose window. As AfriNIC Database is based on RIPE NCC database, they have carried out tests on some mail clients for S/MIME compliance. The results of these tests can be found in the document E-mail Client Testing for S/MIME Compliance .

Set up your mail client

First you need to generate a certificate.

Once the certificate has been generated, select an option to export or backup the certificate and private key from your browser. Some guidelines for this are given in RIPE NCC Documentation Appendix A1.2.

Import the backed up certificate and private key into your e-mail client.

Set up the database

You are now ready to sign messages from your mail client. The next step is to set up the AfriNIC Database end. For this you need to create a new X509 key-cert object and set the authorisation in the mntner object to use X509.

Creating the key-cert object

You need to create a key-cert object according to the following template:

key-cert: [mandatory] [single] [primary/look-up key]
method: [generated] [single] [ ]
owner: [generated] [multiple] [ ]
fingerpr: [generated] [single] [inverse key]
certif: [mandatory] [multiple] [ ]
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]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

You will need to use OpenSSL to convert the certificate into an ascii text format. The backup file exported from your browser containing your certificate and private key is in binary format and the file extension should be .p12. Use OpenSSL to convert this binary file into an ascii file which will have the file extension .pem.

The command to do this is:

openssl pkcs12 -clcerts ascii.pem 

Now open the ascii.pem file in a text editor. Remove everything from the file except for the certificate. This is contained within the lines:

-----BEGIN CERTIFICATE----- 
......
-----END CERTIFICATE-----

You must also keep these BEGIN and END lines. This will now form the certificate data for your key-cert object. Add to the start of each of these lines the attribute name "certif:"

For example:

certif: -----BEGIN CERTIFICATE-----
certif: MIID8zCCA1ygAwIBAgICAIIwDQYJKoZIhvcNAQEEBQAwcTELMAkGA1UEBhMCRVUx
certif: EDAOBgNVBAgTB0hvbGxhbmQxEDAOBgNVBAoTB25jY0RFTU8xHTAbBgNVBAMTFFNv
certif: ZnR3YXJlIFBLSSBUZXN0aW5nMR8wHQYJKoZIhvcNAQkBFhBzb2Z0aWVzQHJpcGUu
certif: bmV0MB4XDTAzMDkwODEwMjYxMloXDTA0MDkwNzEwMjYxMlowfTELMAkGA1UEBhMC
certif: TkwxETAPBgNVBAoTCFJJUEUgTkNDMRAwDgYDVQQLEwdNZW1iZXJzMRgwFgYDVQQD
certif: Ew91ay5idC50ZXN0LXVzZXIxLzAtBgkqhkiG9w0BCQEWIHRlc3QtdXNlckBsaW51
certif: eC50ZXN0bGFiLnJpcGUubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
certif: AQEArv3srxyl1QA3uS4dxdZbSsGrfBrMRjMb81Gnx0nqa6i+RziIf13lszB/EYy0
certif: PgLpQFdGLdhUQ52YsiGOUmMtnaWNHnEJrBUc8/fdnA6GVdfF8AEw1PTfJ6t2Cdc9
certif: 2SwaF+5kCaUDwmlOgbM333IQmU03l3I1ILs32RpQyZ+df/ovHNrVzeLc2P59isac
certif: bfjM2S0SXPQzHjuVLH40eOgVuXA/5LAYs51eXqwtKszSxFhqekf+BAEcRDrXmIT4
certif: e3zfiZOsXKe0UfaEABgHUMrYjsUCJ8NTMg6XiVSNwQQmXCdUbRvK7zOCe2iCX15y
certif: 9hNXxhY/q/IW54W5it7jGXq/7wIDAQABo4IBCDCCAQQwCQYDVR0TBAIwADARBglg
certif: hkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMBoGCWCGSAGG+EIBDQQNFgtSSVBF
certif: IE5DQyBDQTAdBgNVHQ4EFgQUzdajNaRorkDTAW5O6Hpa3z9pP3AwgZsGA1UdIwSB
certif: kzCBkIAUHpLUfvaBVfxXVCcT0kh9NJeH7ouhdaRzMHExCzAJBgNVBAYTAkVVMRAw
certif: DgYDVQQIEwdIb2xsYW5kMRAwDgYDVQQKEwduY2NERU1PMR0wGwYDVQQDExRTb2Z0
certif: d2FyZSBQS0kgVGVzdGluZzEfMB0GCSqGSIb3DQEJARYQc29mdGllc0ByaXBlLm5l
certif: dIIBADANBgkqhkiG9w0BAQQFAAOBgQByg8L8RaiIz5k7n5jVwM/0oHSf48KRMBdn
certif: YdN2+eoEjVQbz48NtjbBTsOiUYj5AQWRHJrKtDQ+odbog0x7UsvhXjjBo/abJ6vI
certif: AupjnxP3KpSe73zmBUiMU8mvXLibPP1xuI2FPM70Y7fgeUehbmT7wdgqs7TEtYww
certif: PeUqjPPTZg==
certif: -----END CERTIFICATE-----

The "method:", "owner:" and "fingerpr:" attributes will be automatically generated by the database update program so these can be ignored at this stage. The only attribute required before the "certif:" data is the "key-cert:". The name value of this attribute is auto generated so add this line at the start of the file:

key-cert: AUTO-1 

This name is only used as a tag in maintainer "auth:" attributes, therefore it was decided not to allow any choice in the name. The generated name will be of the type X509-nnn where nnn is the next available integer number. These numbers will not be re-used. Once a key-cert object is deleted, it is not possible to re-create one with the same name.

The remainder of the key-cert object after the "certif:" attributes looks something like this:

remarks: Sample Key Certificate
notify: you@your_domain.net
mnt-by: YOUR-MNT
changed: you@your_domain.net 20040101
source: AFRINIC

This gives a final key-cert object looking like this:

key-cert: AUTO-1
certif: -----BEGIN CERTIFICATE-----
certif: MIID8zCCA1ygAwIBAgICAIIwDQYJKoZIhvcNAQEEBQAwcTELMAkGA1UEBhMCRVUx
certif: EDAOBgNVBAgTB0hvbGxhbmQxEDAOBgNVBAoTB25jY0RFTU8xHTAbBgNVBAMTFFNv
certif: ZnR3YXJlIFBLSSBUZXN0aW5nMR8wHQYJKoZIhvcNAQkBFhBzb2Z0aWVzQHJpcGUu
certif: bmV0MB4XDTAzMDkwODEwMjYxMloXDTA0MDkwNzEwMjYxMlowfTELMAkGA1UEBhMC
certif: TkwxETAPBgNVBAoTCFJJUEUgTkNDMRAwDgYDVQQLEwdNZW1iZXJzMRgwFgYDVQQD
certif: Ew91ay5idC50ZXN0LXVzZXIxLzAtBgkqhkiG9w0BCQEWIHRlc3QtdXNlckBsaW51
certif: eC50ZXN0bGFiLnJpcGUubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
certif: AQEArv3srxyl1QA3uS4dxdZbSsGrfBrMRjMb81Gnx0nqa6i+RziIf13lszB/EYy0
certif: PgLpQFdGLdhUQ52YsiGOUmMtnaWNHnEJrBUc8/fdnA6GVdfF8AEw1PTfJ6t2Cdc9
certif: 2SwaF+5kCaUDwmlOgbM333IQmU03l3I1ILs32RpQyZ+df/ovHNrVzeLc2P59isac
certif: bfjM2S0SXPQzHjuVLH40eOgVuXA/5LAYs51eXqwtKszSxFhqekf+BAEcRDrXmIT4
certif: e3zfiZOsXKe0UfaEABgHUMrYjsUCJ8NTMg6XiVSNwQQmXCdUbRvK7zOCe2iCX15y
certif: 9hNXxhY/q/IW54W5it7jGXq/7wIDAQABo4IBCDCCAQQwCQYDVR0TBAIwADARBglg
certif: hkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMBoGCWCGSAGG+EIBDQQNFgtSSVBF
certif: IE5DQyBDQTAdBgNVHQ4EFgQUzdajNaRorkDTAW5O6Hpa3z9pP3AwgZsGA1UdIwSB
certif: kzCBkIAUHpLUfvaBVfxXVCcT0kh9NJeH7ouhdaRzMHExCzAJBgNVBAYTAkVVMRAw
certif: DgYDVQQIEwdIb2xsYW5kMRAwDgYDVQQKEwduY2NERU1PMR0wGwYDVQQDExRTb2Z0
certif: d2FyZSBQS0kgVGVzdGluZzEfMB0GCSqGSIb3DQEJARYQc29mdGllc0ByaXBlLm5l
certif: dIIBADANBgkqhkiG9w0BAQQFAAOBgQByg8L8RaiIz5k7n5jVwM/0oHSf48KRMBdn
certif: YdN2+eoEjVQbz48NtjbBTsOiUYj5AQWRHJrKtDQ+odbog0x7UsvhXjjBo/abJ6vI
certif: AupjnxP3KpSe73zmBUiMU8mvXLibPP1xuI2FPM70Y7fgeUehbmT7wdgqs7TEtYww
certif: PeUqjPPTZg==
certif: -----END CERTIFICATE-----
remarks: Sample Key Certificate
notify: you@your_domain.net
mnt-by: YOUR-MNT
changed: you@your_domain.net 20050101
source: AFRINIC

This can now be submitted to the database update program by sending it in an e-mail to auto-dbm@afrinic.net, or using syncupdates or webupdates methods.

The final object created in the database will look something like this:

key-cert: X509-23
method: X509
owner: /C=NL/O=AFRINIC/OU=Members/CN=tg.dodo.administrator
\ /Email=you@your_domain.net
fingerpr: AC:B5:B1:36:95:F3:46:93:B1:2D:58:EB:E1:46:DA:3F
certif: -----BEGIN CERTIFICATE-----
certif: MIID8zCCA1ygAwIBAgICAIIwDQYJKoZIhvcNAQEEBQAwcTELMAkGA1UEBhMCRVUx
certif: EDAOBgNVBAgTB0hvbGxhbmQxEDAOBgNVBAoTB25jY0RFTU8xHTAbBgNVBAMTFFNv
certif: ZnR3YXJlIFBLSSBUZXN0aW5nMR8wHQYJKoZIhvcNAQkBFhBzb2Z0aWVzQHJpcGUu
certif: bmV0MB4XDTAzMDkwODEwMjYxMloXDTA0MDkwNzEwMjYxMlowfTELMAkGA1UEBhMC
certif: TkwxETAPBgNVBAoTCFJJUEUgTkNDMRAwDgYDVQQLEwdNZW1iZXJzMRgwFgYDVQQD
certif: Ew91ay5idC50ZXN0LXVzZXIxLzAtBgkqhkiG9w0BCQEWIHRlc3QtdXNlckBsaW51
certif: eC50ZXN0bGFiLnJpcGUubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
certif: AQEArv3srxyl1QA3uS4dxdZbSsGrfBrMRjMb81Gnx0nqa6i+RziIf13lszB/EYy0
certif: PgLpQFdGLdhUQ52YsiGOUmMtnaWNHnEJrBUc8/fdnA6GVdfF8AEw1PTfJ6t2Cdc9
certif: 2SwaF+5kCaUDwmlOgbM333IQmU03l3I1ILs32RpQyZ+df/ovHNrVzeLc2P59isac
certif: bfjM2S0SXPQzHjuVLH40eOgVuXA/5LAYs51eXqwtKszSxFhqekf+BAEcRDrXmIT4
certif: e3zfiZOsXKe0UfaEABgHUMrYjsUCJ8NTMg6XiVSNwQQmXCdUbRvK7zOCe2iCX15y
certif: 9hNXxhY/q/IW54W5it7jGXq/7wIDAQABo4IBCDCCAQQwCQYDVR0TBAIwADARBgl
certif: hkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMBoGCWCGSAGG+EIBDQQNFgtSSVBF
certif: IE5DQyBDQTAdBgNVHQ4EFgQUzdajNaRorkDTAW5O6Hpa3z9pP3AwgZsGA1UdIwSB
certif: kzCBkIAUHpLUfvaBVfxXVCcT0kh9NJeH7ouhdaRzMHExCzAJBgNVBAYTAkVVMRAw
certif: DgYDVQQIEwdIb2xsYW5kMRAwDgYDVQQKEwduY2NERU1PMR0wGwYDVQQDExRTb2Z0
certif: d2FyZSBQS0kgVGVzdGluZzEfMB0GCSqGSIb3DQEJARYQc29mdGllc0ByaXBlLm5l
certif: dIIBADANBgkqhkiG9w0BAQQFAAOBgQByg8L8RaiIz5k7n5jVwM/0oHSf48KRMBdn
certif: YdN2+eoEjVQbz48NtjbBTsOiUYj5AQWRHJrKtDQ+odbog0x7UsvhXjjBo/abJ6vI
certif: AupjnxP3KpSe73zmBUiMU8mvXLibPP1xuI2FPM70Y7fgeUehbmT7wdgqs7TEtYww
certif: PeUqjPPTZg==
certif: -----END CERTIFICATE-----
remarks: Sample Key Certificate
notify: you@your_domain.net
mnt-by: YOUR-MNT
changed: you@your_domain.net 20040101
source: AFRINIC

Updating the maintainer

The final step in order to use X.509 is to set the authorisation of your mntner object to accept X.509. It is advisable in the first instance to keep the existing authorisation method of your maintainer and add the X.509 as an additional method. After you have tested its use successfully, you can then delete any
less secure authorisation methods such as passwords.

If your existing mntner object looks something like this:

mntner: YOUR-MNT
descr: company maintainer object
admin-c: TP1-AFRINIC
upd-to: you@your_domain.net
referral-by: RIPE-DBM-MNT
mnt-by: YOUR-MNT
auth: CRYPT-PW dbOnSHFpKZTBU
changed: you@your_domain.net 20050101
source: AFRINIC

Add an additional authorisation line for X509-23 and submit the object to the database update program in the usual way, supplying the required existing authorisation. In this example it will be the crypt-pw password:

mntner: YOUR-MNT
descr: company maintainer object
admin-c: TP1-AFRINIC
upd-to: you@your_domain.net
referral-by: RIPE-DBM-MNT
mnt-by: YOUR-MNT
auth: CRYPT-PW dbOnSHFpKZTBU
auth: X509-23
changed: you@your_domain.net 20050101
source: AFRINIC

Using the X.509 authorisation

Everything is now in place to use X.509 authorisation. You can compose a message in your mail client containing the update. Sign the message with your certificate and private key. You may need to check with the documentation for your specific mail client to see how to do this. Then send the e-mail to auto-dbm@afrinic.net. Once you have submitted a successful update you can, if you wish, remove the weaker authentication method by removing the line in this example:

auth: CRYPT-PW dbOnSHFpKZTBU 

from your mntner object. Updates can now only be authorised by the stronger authentication method of X.509.

New mntner Object Format

 

1) Abstract

Consequent to the community's request in December 2012, the AFRINIC whois database will no longer display hashes of MD5 and CRYPT encrypted passwords in all mntner (whois database) objects.

Currently, majority of objects in the AFRINIC whois database are protected by and authenticate through a mechanism that uses clear text passwords encrypted with the md5 algorithm for authentication. There are two major concerns with this method:

  • The md5-hashed password has traditionally been visible in all mntner objects. This makes it vulnerable to crackers, given that computers these days are armed with more than enough processing power to unhash these passwords in a relatively short time.
  • When performing a whois database update, plain text passwords are attached into the objects to be updated and sent by email to the whois database. This introduces a possibility for the password to be sniffed in case there is no form of encryption between the sender, recipient and their relaying Mail Transfer Agents.

AFRINIC has enabled a filter in the whois database such that whois queries do not display those hashes again. This mitigates the potential for anyone to run a simple script or program that will crack these passwords, as they are no longer visible.

 

2) Updating objects in the whois database

There are basically two scenarios to consider:

  • Modifying an existing mntner whois database object, which already has the hash filters applied. 
  • Authenticating against a maintainer object to update its protected object, and, creating, modifying or deleting child objects protected by the parent object's mnt-lower or (mnt-domains).

2.1) Modifying a mntner object

The process to create a new mntner object remains completely unchanged. However, once created, modifying and deleting an existing mntner requires the object owner to have access to the md5 and/or CRYPT hash that was used to create the mntner in the first place if the modifications involve other attributes.

It is therefore important that the hash be kept by the object owner for future retrieval when updating existing mntner objects. Below are examples of mntner objects, showing the previously unfiltered hash in the top object, and the new format at the bottom object, showing the hashes filtered.

Below are examples of mntner objects, showing the previously unfiltered hash in the top object, and the new format at the bottom object, showing the hashes filtered.

whois md5

To modify an existing mntner:

a) Query the AFRINIC whois database for your object, add the hash to the result and send it to the server for updating, as follows:

whois md5_2

  • Go to https://afrinic.net/en/services/whois-query
  • Type your object into the search form with the "-B" option prepended, such that attributes containing e-mail addresses are not filtered (a default measure to fight e-mail harvesting).
  • The same web-based search can be used by the command line lovers by typing the following (using a Unix or Linux whois client): whois –h whois.afrinic.net –r –B ISP1-MNT
  • Copy the object into the body of a new-email.
  • Replace the "#FILTERED" text with your previously stored MD5 hash, add a password attribute whose value is your clear text password and submit the object by e-mail to auto-dbm@afrinic.net. 

b) If the e-mail returned by the server indicates that the update failed, there is a possibility that the hash was wrong (in which case a syntax error will appear in the bounce) or the clear text password was not correct (this will be shown as an authentication error)

c) In case you cannot retrieve your md5 hash (but know your plain text password that was used to generate the hash), it is possible to simply re-generate a new hash of the same password.

Please browse to the "Tools" section of our website, select the CRYPT/MD5 Password Tool, enter your plain text password and click "Generate".

whois md5_3

 

The generated hash can be copied and pasted into your mntner object and submitted for update as usual.

d) If your password is lost (irrespective of availability of the md5 hash), it is not possible to update the object. You must contact AFRINIC for the standard lost mntner password process, by simply mailing hostmaster@afrinic.net with a request for a new password. Please note that:

  • Your e-mail should contain an md5 hash of your preferred (new) password generated per step (c) above. 
  • The password change request must come from an authorized contact. If there has been change of contacts, we shall request an official signed letter from a senior executive of your organization detailing the new contacts. 

3) Using PGP authentication (instead of md5 and CRYPT-PW)

 

In addition to MD5, the AFRINIC whois database supports PGP for authenticating whois database updates. In contrast to MD5, PGP provides stronger encryption techniques and guarantees that the signed update message was not tampered with. It is works by using a pair of keys generated by the user. The public key is uploaded to the whois database inside a key-cert object, and the user's email updates are signed using the private key on the user's device.

Since most whois database updates are submitted by e-mail, the only way to guarantee security is by using PGP, which AFRINIC strongly recommends to our members and the community. 

This is because with the MD5 method, updates submitted by email are authenticated by the user inserting a clear text password in the e-mail body. Despite using technologies like SSL and TLS, AFRINIC has no control over all the stages that an e-mail goes through before final delivery to our whois server.

 

Combining different auth mechanisms

 

The whois database supports use of multiple authorization mechanisms in one mntner object. If an object is protected with a mntner that contains multiple md5 passwords and PGP keys, any one of the correct passwords or PGP-signed emails will authenticate. The mntner object captured below contains two "auth" attributes for both md5 and PGP authentication mechanisms. Either of the attributes can be used to authorize updates.

mntner:    TOTO-MNT
descr:     Maintainer Toto telecom
admin-c:   ABC1-AFRINIC
tech-c:    DEF1-AFRINIC
upd-to:    abc@afrinic.net
mnt-nfy:   def@afrinic.net
auth:      MD5-PW $1$09nxAH88$ZaDWuXGdly2boQi69atbN.
auth:      PGPKEY-476A541E
mnt-by:    TOTO-MNT
changed:   hostmaster@afrinic.net
source:    AFRINIC


4) FAQ: Filtered MD5 Hashes

  1. Why did AFRINIC decide to hide the MD5 hash? 
    Because some one can crack it using any computer or even smartphone. Hiding it provides a deterrent from crackers trying all sorts  of things on your hash.

  2. Can I update a mntner object without inserting the md5 hash?
    No. You must replace the "FILTERED" string in the auth attribute with the actual encrypted hash otherwise the update will fail.

  3. I have forgotten my md5 hash.
    If you remember the plain text password instead, please use our online md5 encrypted password generator. A different hash of the same password will be generated which can be used to update (but not delete) the object

  4. I know my plain text password. How can I get my md5 hash?
    By using our online encrypted password generator. Please note the hash will always be different, as it's generated based on a timestamp.

  5. MD5 seems insecure. Are there other options? 
    You can use PGP, which involves using a pair of keys. More information about using PGP with the AFRINIC whois database can be found here.

  6. I forgot my password. Can you reset it? 
    Please use the online md5 hash generator to create a hash of your new password, and submit that hash to hostmaster@afrinic.net. You must be the authorized contact for your company. 

  7. Can I still create customer assignments without knowing the hash? 
    Yes. All you need is to submit those assignments along with a clear text password to the whois database. You can even use MYAFRINIC for that.

  8. Does rDNS still work as before?
     Yes. All other objects as well as whois database update procedures remain unchanged. Only mntner objects are affected, in that you need to have that hash handy whenever you must edit your mntner (which is not very common).

  9. How do I use PGP with the AFRINIC whois database? 
    Having generated your PGP key-pairs, export your public key into the whois database using a key-cert object. Then sign all your database updates using your private key. Please look here for more information.

  10. Can I use both PGP and MD5 encryption concurrently?
    Yes. Either of the authenticated mechanisms will work if specified in a given mntner object.

  11. How can I get additional help? 
    Please mail afrinic-dbm@afrinic.net for any assistance with the AFRINIC whois database or call +230 403 5104. You can also use Skype to call us for free on regular Skype user "skype2afrinic". 

  

Creating Customer Assignments

Introduction

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, 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.  

ps. 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 following methods:

https://www.afrinic.net/en/library/membership-documents/219-objects-template#26

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: zola.abalo@example.com 

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: zola.abalo@example.com 

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: zola.abalo@example.com 

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

Mntner Guide (PDF)

Click here to download the PDF

 

This browser does not support inline PDFs. Please download the PDF to view it: Download PDF

 

// //