Summary

  • Denis Walker described a 2013 RIPE Database change that let the maintainer of an NCC-issued address resource authorize deletion of subordinate operational records, even when that maintainer was absent from the child object’s mnt-by.
  • The rule covered more-specific inetnum and inet6num objects, route and route6 records, and reverse-DNS domain objects. It did not let a holder edit those records, delete the parent allocation or assignment, or seize an AS number.

The route object that would not leave

The network operator has the address space. The old route object has the exact prefix. A new route object cannot be created while that old one occupies the slot, yet its mnt-by names somebody else. The administrator’s next move used to be a request to RIPE NCC for manual intervention. That is a strange way to discover who really holds the keys to your own address records.

Denis Walker, then working on the RIPE Database, described the escape in April 2013. The database’s new reclaim function let a resource holder delete an operational object under an address allocation or assignment issued by RIPE NCC. It was an authorization change at the update service, not a special command-line instrument. Add delete: reason to the object and submit the usual update. The software checks the parent resource object and accepts the relevant mnt-by or mnt-lower maintainer as an additional authorizer for deletion.

The everyday failure was not exotic. Two parties could share an object’s mnt-by; either could remove the other. A perfectly routine handover could also strand an object behind a maintainer no longer under the holder’s control. A route object with an exact matching prefix then blocked creation of a replacement. The registered holder had accountability for the resource while a subordinate database entry held up operations. Walker’s proposal put a lever at the point where that mismatch hurt.

It was a sharply cut key. The holder could delete, then recreate a suitable record under its own authorization; reclaim supplied no right to edit the child in place or change its authentication. It reached more-specific inetnum and inet6num entries; route and route6 objects with matching or more-specific prefixes; and reverse delegations under in-addr.arpa or ip6.arpa. It did not reach the parent resource itself, aut-num objects, ENUM domains, or secondary person and role entries. Nor did a holder of a mere sub-allocation inherit this top-level power: the resource had to be issued by RIPE NCC to the authorizing holder.

The distinction is more than database housekeeping. Deleting a route object changes what the registry says and what future updates it accepts; it does not magically change a router’s forwarding table. But an address holder who cannot clear a blocking registry record is dependent on an administrator’s discretion at precisely the moment it needs to act. Walker did not invent that dependency; he made one part of it executable by rule.

The RIPE NCC’s 2013 annual report lists reclaim among the year’s new database features and describes the authorization override for deleting related operational objects. Walker’s own explanation supplies the edges of that power. A small delete button, properly fenced, can be a large answer to the question: whose address record is this to manage?

RIPE originals