Search RPD Archives
[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