Policy Pre-CPM

Last Modified on -

Details
  • Ref. Name:
    AFPUB-2012-DNS-001
  • Old Ref:
    NA
  • Status:
    Implemented
  • Date:
    30 Nov 2012
  • Author:
    Tim McGinnis
  • Staff Assessment

1) Introduction

The purpose of a Public Network Information Database such as the AfriNIC Database is so that contact information about public networks is made public by registering assignments as they are made in the database.

It is the author's experience that AfriNIC members are not as diligent about registering assignments of IPv4 space as they could be. AFPUB-2005-v4-001 says, inter alia:

"9.5 Validity of an assignment Assignments remain valid as long as the original criteria on which the assignment was based are still in place and the assignment is registered in the AfriNIC whois database. An assignment is therefore invalid if it is not registered in the database and if the purpose for which it was registered has changed or no longer holds. "

This proposal is an enforcement mechanism of that long-standing policy.

 

2) Summary of How this Proposal Addresses the Problem

This proposal limits LIRs and End-Users from obtaining reverse delegation (rDNS) from AFRINIC unless the address space is assigned or sub-allocated in the AfriNIC Database.

 

3) Situation in other RIRs

3.1) AfriNIC will no longer grant reverse delegation of IP address space that it administers unless an assignment or sub-allocation of the specific address space is registered appropriately in the AfriNIC Database. For a /24 reverse delegation, at least one assignment or sub-allocation must be registered in the AfriNIC Database for that specific /24. The entire /24 does not have to be assigned in order for the reverse delegation to be allowed.

 

3.2) AfriNIC will contact those LIRs who currently have reverse DNS for allocations, but have not registered any assignments or sub-allocations under those allocations to remind them of the above text from AFPUB-2005-v4-001. It is envisioned that this will be done using MyAfriNIC and email, but specific details will be left to the Secretariat staff to implement. These LIRs will have 12 (twelve) months from the date of the reminder to register their assignments or sub-allocations.

 

3.3) AfriNIC may remove reverse delegation of any LIRs allocation beginning 12 (twelve) months from the date of the reminder.

 

 

History

  • 30 Nov 2012 - Second Draft AFPUB-2012-DNS-001-DRAFT-02 submitted by author.
  • 29 Nov 2012 - Discussed at AFRINIC-17, deferred to list for more discussion.
  • 10 Apr 2012 - Initial Draft AFPUB-2012-DNS-001-DRAFT-01 submitted by author.

 

Last Modified on -

 

Details
  • Ref. Name:
    AFPUB-2010-GEN-006
  • Old Ref:
    AFPUB-2010-v4-003-draft-02 (GPP-IPv4-2010)
  • Status:
    Implemented
  • Date:
    12 May 2012
  • Author:
    Tobias Knecht | abusix.org | tk [at] abusix.org

1) Introduction

This proposal specifies a dedicated object which shall be used as the preferred place to publish abuse public contact information within the AfriNIC service region.

The mentioned object can be referenced 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.

 

2) Summary of current problem

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 service region, the abuse reports are sent to e-mail address specified in the e-mail field, as encouraged on the AfriNIC website.[1] These addresses are used because the AfriNIC Whois Database currently has no specialised contact object for abuse departments. Instead, all abuse reports are sent to contact that is has broader responsibilities or different responsibilities.

 

3) Situation in other RIRs

APNIC:

APNIC found consensus on introducing a mandatory IRT Object for all inet(6)nums and aut-nums at APNIC 29 in Kuala Lumpur March 4th 2010. Further information about the APNIC policy proposal can be found at [2]

ARIN:

An abuse-POC exists for Organizational ID identifiers.[3]

LACNIC:

An abuse-c exists for aut-num, inetnum and inet6num objects.[4]

RIPE:

An optional IRT (Incident Response Team) object can be linked to inetnum and inet6num objects.[5]

 

4) Details of the proposal

It is proposed that the AfriNIC create a new or uses an already existing object, which implements the following properties:

(a) A unique reference by inetnum, inet6num and aut-num

(b) Contains 2 email attributes:

(i) "e-mail:" for personal communication

(ii) "abuse-mailbox:" for automatic report handling

The object should be accessible through Whois. AfriNIC publishes a Best Practice Paper and informs all their members actively to encourage them to use the object to publish abuse contact information.

 

5) Advantages and disadvantages of the proposal

5.1 Advantages

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

5.1 Disadvantages

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. Nevertheless it is suggested to AfriNIC to offer a way to receive reports about not working or not accurate objects. But this is part of another proposal.

 

6) Effect on AfriNIC members

There will be no immediate impact. The only effect is the opportunity to publish a dedicated abuse contact object and benefit by the advantages.

 

7) References:

 

 

History

Previous Versions

  1. AFPUB-2010-v4-002
  2. AFPUB-2010-v4-006
  3. AFPUB-2010-v4-003-draft-02 (GPP-IPv4-2010)

 

Page 3 of 12