Managing objects in the APNIC Whois Database
Modifying objects
To update or modify an existing object by email, you must:
- Obtain a copy of the existing object
- Update the object template
- Add a new changed attribute to the object
- Send the object to the appropriate mailbox
Obtain a copy of the existing object
Query the APNIC Whois Database to obtain a copy of the existing object.
Web-based whois query
Query the APNIC Whois Database and copy the results into the update email.
Command line whois query
Use the command line whois query to save the results directly into a file. Use the query format:
whois h whois.apnic.net <search string> <file>
Then use a text editor to update the object in the file.
Update the object template
When updating objects you can:
- Make changes to existing attributes
- Delete optional attributes included in the original object
- Add new optional attributes not included in the original object
NOTE: If you attempt to update an attribute that is a primary key of an object, a new object will be created and the existing object will remain unchanged. To change the primary key of an object, create a new object with the updated primary key attribute and delete the existing object.
Special cases: person, role, mntner, and route objects
If you need to update an attribute that is a primary key for an object, first delete the existing object then create a new object in its place. This has an effect on the following object types in particular:
- person
- role
- mntner
- route
Person and role objects
If you change the NIC-handle of an existing person or role object, a new object will be created and the existing object will remain unchanged.
In particular, if you attempt to change the person or role attribute of a person or role object, your update will also fail.
To prevent a large number of unreferenced person and role objects in the APNIC Whois Database, APNIC strongly recommends deleting the original object and submitting a new object to the database.
mntner objects
If you attempt to change the mntner attribute of an existing mntner object, the database software will assume you are trying to create a new mntner object and, because only APNIC Hostmasters can authorize new mntner objects, the submission will fail.
To create a new maintainer with the updated mntner attribute, you must send an email to:
In the email please include:
- A copy of both the existing and new mntner objects
- A brief explanation why you would like your old mntner replaced with a new mntner with a modified mntner attribute
Please note that if you do this, you must remember to replace the mntner referenced in database objects with the new mntner.
Route objects
Sometimes it is necessary to update the origin attribute of a route object. However, if you try to update the existing route object, a new route object will be created and the existing object will remain unchanged. Each route object will have the same prefix specified in the route attribute, but different Autonomous Systems specified in the origin attributes. This is a useful function if you are multihoming. However, if you wish to replace the object completely, you first must delete the existing route object and then submit a new route object to the database.
Deleting objects
To delete an existing object via email, you must:
- Obtain a copy of the existing object
- Add a special delete attribute to the object
- Send the object to the appropriate mailbox
To obtain a copy of the existing object, query the APNIC Whois Database. A special attribute called delete must be added to the end of the existing object. The delete attribute uses the format:
delete: <free-text>
Where:
| Field | Description |
| Free-text | Reason for deleting object |
NOTE: If the object you are deleting is protected by a maintainer object with an authentication method other than NONE, you will need to supply the appropriate password or other authentication information.
Example of deleted object
person: Ky Xander
address: ExampleNet Service Provider
address: 2 Pandora St Boxville
address: Wallis and Futuna Islands
country: WF
phone: +680-368-0844
fax-no: +680-367-1797
e-mail: kxander@example.com
nic-hdl: KX9-AP
remarks: -----------------------------
remarks: Send abuse reports to
remarks: abuse@example.com
remarks: -----------------------------
mnt-by: MAINT-WF-EXAMPLENET
changed: kxander@example.com 20020821
source: APNIC
delete: duplicate person object
password: privatepassword02
An object will only be deleted if the object in the email exactly matches the object in the database.
Caution: Before deleting a person or role object, make sure it is not referenced by other objects. To find objects where the role or person object is referenced, perform an inverse query using the '-i' flag.
Example:
whois -h whois.apnic.net -i tech-c,admin-c,zone-c KX9-AP
If you are not sure whether other objects reference the person or role object to be deleted, do NOT delete that object.
Special cases: person, role and mntner objects
Before deleting a person, role, or mntner object, make sure it is not referenced by other objects. To find objects where the role or person object is referenced, perform an inverse query using the '-i' flag.
If you are not sure whether other objects contain references to the person or role object to be deleted, do NOT delete that object.
NOTE: The database software will not allow you to delete a person, role or mntner object that is referenced by any other object. However, as all person and role objects must refer to a maintainer, and all maintainers must refer to NIC-handles in the tech-c and admin-c attributes, the database software will not permit you to delete your person object while it is still referenced by your mntner object.
Therefore, to delete a person or role object along with its mntner object, you must:
1. Update the mntner you wish to delete with a different person object's NIC-handle in the tech-c and admin-c attributes.
- If you have another person or role object, please refer to that object.
- You do not have another person or role object you can use for this purpose, create a new person object, specifying MAINT-NEW in the mnt-by attribute. Once the temporary person object has been created, specify this person object's NIC-handle in the mntner object to be deleted.
2. Once the mntner no longer references the person object you wish to delete, you can delete that person object.
3. Delete the mntner.
4. If you created a temporary person object, delete it.
Protecting objects
Because the APNIC Whois Database is an important source of information for the Internet community, it is important that the information in the database is accurate and not vulnerable to unauthorized changes or additions. To protect objects, the APNIC Whois Database uses maintainer objects.
The mntner object is used to authorize changes to:
- Objects directly protected by the maintainer
- Objects in a hierarchical structure beneath the object protected by the maintainer. For example, a route object must pass the mntner authorization of the aut-num and inetnum objects it refers to.
Objects can refer to maintainer object in the following attributes:
- mnt-by
- mnt-lower
- mnt-routes
- mbrs-by-ref
- cross-mnt
The maintainer contains one or more authentication (auth) attributes. Each auth attribute consists of:
- A keyword to identify the authentication method
- The authentication information needed to use that method
This is displayed in the format:
auth: <auth-keyword> <auth-info>
Example:
auth: CRYPT-PW /3xnXDDY/auyg
When submitting an object that requires authorization from a mntner to the database, you must supply the authentication information for that mntner in the submission. The type of authentication information you must provide depends on the authentication method specified in the mntner object.
Authentication methods currently supported by the database are described below:
| Authentication keyword | Description |
| NONE | No authorization checks are performed on objects protected by a maintainer with this authentication method. APNIC strongly discourages the use of this method as it allows anyone to change objects protected by maintainers with this method. |
| CRYPT-PW | Stored in the auth attribute as a fixed encrypted password in UNIX crypt format. This is a relatively weak form of authentication. Disadvantages of this method include:
To authenticate changes to objects protected by maintainers using this method, the object must contain the pseudo-attribute password anywhere in the object in the format: password: <clear-text-password> Example: password: secret02NoW The pseudo-attribute cannot appear in mail headers and cannot continue over more than one line. |
| PGPKEY | Stored in the auth attribute as a signature identity pointing to a public key certificate. The public key certificate is stored in a separate key-cert object. To authenticate changes to objects protected by maintainers using this method, the submission must be signed by the corresponding private key. Advantages of this method:
Disadvantages of this method:
APNIC does not guarantee that any public key stored in the APNIC Whois Database belongs to any specific entity. The APNIC Whois Database is not a certificate authority. |
Important points to note:
1. You may include more than one auth attribute in a maintainer object. However, be aware that the authentication is only as secure as the weakest authentication method listed.
2. You may include more than one mnt-by, mnt-lower, mnt-routes, or mbrs-by-ref attribute in an object.
- This is useful if you do not wish to reveal your auth method information to another person or organization. The other person or organization can still have the ability to update objects, but has their own separate mntner and auth method information.
- To include multiple mntners in an object, you need to include the appropriate authentication information for the existing mntner referenced in the object. You do not need to pass the auth method of the additional mntner object.
3. If there are multiple mntners mentioned in the same attribute type of an object, you need to pass the authentication of only one of those maintainers. This has two major implications:
- If you are the original maintainer of an object and decide to insert additional mntners in the same attribute for the object, the additional mntners can delete your mntner at any time without passing your auth method.
- The security on the protected object is only as strong as the weakest auth method used by the mntner objects. For example, if one mntner uses NONE and the other uses PGPKEY, it is possible for anyone to change objects protected by both these maintainers.
