[rpd] reverse delegation

[Madhvi Gokool]

Hello Jaco

We take note of your concern below and will verify this behaviour upon 
deletion of an assigned PA.

Kind Regards

Madhvi

On 23/10/2026 02:16, Jaco Kroon via RPD wrote:
>
> 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
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20261102/e7d28144/attachment.html>