Abuse Contact Information in the AfriNIC service region - AFPUB-2010-GEN-002
|Date||7 Apr 2010|
This is a proposal to introduce a mandatory reference to IRT objects in the inetnum, inet6num and aut-num objects in the AfriNIC Whois Database. It provides a more accurate and efficient way for abuse reports to reach the correct network contact.
Network owners increasingly operate dedicated abuse handling departments, distinct from the basic operations department.
More and more network owners and other institutions are also starting to exchange data about abusive behavior with each other, to more quickly allow networks to identify internal abuse, external abuse, and other security problems.
Currently within the AfriNIC region, the growing amount of abuse reports are sent to e-mail address specified in the e-mail field, as encouraged on the AfriNIC website. These addresses are used because the AfriNIC Whois Database currently has no mandatory, specialised contact object for abuse departments. Instead, all abuse reports are sent to contact that is has broader responsibilities or different responsibilities.
This policy proposal found consensus at APNIC 29 in Kuala Lumpur March 4th 2010. Further information about the APNIC policy proposal can be found at 
An abuse-POC exists for Organizational ID identifiers.
An abuse-c exists for aut-num, inetnum and inet6num objects.
An optional IRT (Incident Response Team) object can be linked to inetnum and inet6num objects. If the current proposal is successful in the APNIC and AfriNIC region, the author plans to submit a similar proposal for the RIPE region
It is proposed that AfriNIC:
4.1) Institute a mandatory reference to an IRT object in inetnum, inet6num and aut-num objects.
In terms of implementing a mandatory IRT reference, it is suggested that this be part of two, established actions:
- The next time an organization attempts to update an existing inetnum, inet6num or aut-num object
- When new inetnum, inet6num or aut-num objects are added to the database
4.2) Have a mandatory abuse-mailbox field in the IRT object.
4.3) Delete abuse-mailbox fields in all objects that do not define an IRT, and delete the trouble field everywhere mid 2011.
- Networks will be able to supply their own, direct contact information for abuse departments.
- Abuse complaints will not be sent to the "wrong" contact any more.
- This permits greater administrative and operational flexibility, and faster abuse handling will be possible.
- Since AfriNIC is using the same whois system as RIPE and APNIC, the IRT-Object and the abuse-mailbox attribute are already existant in the system. That makes implementing it very easy and fast.
- Introducing a mandatory reference to the IRT Object will establish a new object. This object, like all other existing objects, will face the data accuracy problem. This proposal aims to address the issue of a missing place for abuse contact information and will not improve data accuracy in the whois database. Data accuracy will be part of another proposal that is already being discussed on the APNIC and RIPE policy mailing list.
There will be no immediate affect for AfriNIC members with existing resource registrations already in the AfriNIC Whois Database.
However, members will need to add a reference to the mandatory IRT object in the following situations:
- The first time members attempt to update an existing inetnum, inet6num or aut-num object
- When members add new inetnum, inet6num or aut-num objects
- Finding contacts for an IP address http://www.afrinic.net/Registration/spam.htm
- prop-079: Abuse contact information http://www.apnic.net/policy/proposals/prop-079
- Introduction to ARIN's Database https://www.arin.net/knowledge/database.html#abusepoc
- There is no formal documentation on abuse-c in inetnum and inet6num objects, but for documentation on the abuse-c in ASN records, see LACNIC Policy Manual (v1.3 - 07/11/2009) http://lacnic.net/en/politicas/manual4.html
- IRT Object FAQ http://www.ripe.net/db/support/security/irt/faq.html
Le système hiérarchique des nom des domaines permet des noms de domaine à être associé à des adresses IP et la résolution inverse exécute la fonction contraire.