Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] reverse delegation

Jaco Kroon jaco at uls.co.za
Thu Oct 22 22:16:01 UTC 2026


Hi All,

Section 10 (Reverse delegation) of the CPM relates, specifically 10.5 
"Validity of the Reverse Delegation".

10.5.2 No Reverse DNS service absent of registered assignments:

 1. No reverse delegation of administered/allocated IP address space is
    allowed unless an assignment or sub-allocation from the specific
    address allocation is registered appropriately in the AFRINIC whois
    database.
 2. 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.

Herein lies a problem when one needs to update inet(6)num objects.

For example, if in the db you have:

inetnum: 10.0.0.0/22
domain: 0.0.10.in-addr.arpa
domain: 1.0.10.in-addr.arpa
domain: 2.0.10.in-addr.arpa
domain: 3.0.10.in-addr.arpa
route: 10.0.0.0/22

Now assume you want to delete inetnum for 10.0.0.0/22, at this point 
(whether you're deleting by way of email update, whois web or via 
my.afrinic) you will get the following errors:

This object can not be deleted because a child object [domain] 
0.0.10.in-addr.arpa exists.
This object can not be deleted because a child object [domain] 
1.0.10.in-addr.arpa exists.
This object can not be deleted because a child object [domain] 
2.0.10.in-addr.arpa exists.
This object can not be deleted because a child object [domain] 
3.0.10.in-addr.arpa exists.
This object can not be deleted because a child object [route] 
10.0.0.0/22AS64512 exists.

I'm not sure what part of the policy dictates that the route: object 
must block the inetnum deletion, but it's plain that when removing the 
inetnum object for 10.0.0.0/22 the 4 domain: objects would be in 
violation of 10.5.2.

There is no specific constraint that I can find in the policy (although 
I would consider this obvious) that an entity may only submit domain: 
objects for ranges that has been allocated to it (ie, for which it's the 
org).

The operational problem is that in order to bring your assignments and 
sub-allocations up to date, you have to temporarily delete the domain: 
(and presumably the route: - in some cases) objects.

I would like to propose that the entirety of 10.5 be removed, such that 
afrinic staff can update the rules in the whois database to not enforce 
the above.

Before doing so, does anybody have any recollection of why this was put 
in place in the first place?  Or potentially have any reason for wanting 
to keep it in place?

Kind regards,
Jaco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20261023/39823dda/attachment-0001.html>


More information about the RPD mailing list