[DBWG] stale route6 and domain objects for removed inet6num

Frank Habicht geier at geier.ne.tz
Thu Aug 20 15:04:30 UTC 2020

Thanks James.

hoping that the general check, capture of orphans and clean up can be
done by mid next week.


On 20/08/2020 17:19, James wrote:

> Dear Frank,


> Thanks for the inquiry.


> The mechanism being referred to is implemented within the WHOIS  and the

> bug has been reported with our software team. As soon as I have an ETA

> you shall be kept in the loop.


> Before removing the objects you highlighted, we are running a general

> check to establish the extent of the issue and ensure we capture any

> other orphan objects that may exist so that the clean up is done at

> once. Furthermore, the proactive monitory tool in this regard was

> something already requested internally and is under development with an

> ETA of Monday.


> My previous update was in the interest of keeping you updated as the

> team works in the background to resolve the issue.


> Regards,


> James


> On 19/08/2020 22:14, Frank Habicht wrote:

>> Dear James,


>> Thanks for your email.


>> I want to respond as an AfriNIC member, *not* as DBWG co-chair.

>> Also, I'm known to be sometimes a bit too blunt, and i'm currently not

>> sure if i can avoid this here. Apologies in advance.


>> We (non-staff outsiders) probably don't need to know all the internals,

>> but in this case i think it would comfort me if we had some indication

>> that internal details are being looked at (critically) and this and more

>> bug(s) get fixed. with intention of pro-activeness.

>> We don't know whether the 'mechanisms that checks for child objects' is

>> a script for a human to follow and a passage should be more highlighted,

>> or whether that's a script for a machine where a '6?' is missing in a

>> regular expression right after 'route' .


>> And we shouldn't be involved in this. I just want to express that it

>> would be very comforting if we could get to see - by results, of course

>> - that this is taken seriously and being looked at.


>> Maybe there should or could be some incentives to find issues. and to

>> fix them. Anything i can think of can probably be "gamed", and i

>> shouldn't get into details.

>> [I included Arthur for that. he had asked me ages ago for feedback, took

>> me long to give some;-)]


>> So I wanted also to mention:

>> If I found an embarrassing bug or mistake in my database, I would really

>> try hard to fix it, if not before sending the response email, then at

>> least immediately after.


>> If not done 2.5 hours after the email is sent, a troublesome outsider

>> (named Frank) could already think the issue gets neglected or forgotten.


>> the route6 object is still there:

>> $ whois -h whois.afrinic.net -- -T route6 2c0f:f370::/32 | egrep -A 4

>> '^rout'

>> route6: 2c0f:f370::/32

>> descr: Auvionics-v6

>> origin: AS328097

>> mnt-by: AA96-MNT

>> source: AFRINIC # Filtered


>> Since the bug existed when the inet6num was deleted, the route6 wasn't

>> deleted during inet6num deletion, I would believe that manual

>> intervention is required.


>> And it seems to me that it still wasn't done.


>> I simply don't want to do the same check for the domain object for the

>> same prefix - I leave that to staff. [maybe I can ask Arthur to drop me

>> a note when both are removed]



>> Now about an idea for a way forward:

>> [and I hope that's obvious, but i request forgiveness that I don't want

>> to assume too much]

>> Someone could volunteer to find additional objects that were orphaned

>> through the same process as the objects in this case i discovered.


>> - go through all existing domain objects ending in 'ip6.arpa' and see if

>> the covering (or equal) inet6num objects exist -

>> and are *not* equal to ("2c00::/12" or "2001:4200::/23")

>> - go through all existing route6 objects, and do the same test.


>> I strongly believe that we shouldn't look for a volunteer from the

>> community for this - AfriNIC staff is just much better equipped (and

>> paid) to do that.



>> Finally I want to mention a word about impact.


>> [we can't thank Job enough for some of the great tools he's

>> contributing, nevertheless: Thank you, Job Snijders!!!]


>> http://irrexplorer.nlnog.net/search/328097

>> currently shows 3 AS-SETs in RIPE and one AS-SET in AfriNIC that include

>> AS328097, which means that real operators are putting 2c0f:f370::/32

>> into real filters, eating up resources ...

>> <sarcasm>...and leading to earlier upgrade requirements, spending money

>> that we all would rather spend on AfriNIC fees...... </sarcasm>


>> Now I'm co-guilty; and I will fix 2 of these AS-SETs within 15 minutes

>> after sending this email, and make an email to someone to fix the 3rd

>> within 30 minutes....


>> So maybe http://irrexplorer.nlnog.net/search/328097 will already look

>> better by the time you guys check.


>> Thanks,

>> Frank



>> On 19/08/2020 17:52, James wrote:

>>> Dear Frank,


>>> Thank you for bringing this forward.


>>> When resources are being de-registered by staff, we have mechanisms that

>>> checks for child objects and prevents the deletion where any still exist.


>>> However, based on the issue you have raised, we have noted that there is

>>> a bug in the implementation and this bug led to the issues observed.


>>> We will be  taking this up with our software team to fix the issue and

>>> also look for better monitoring.


>>> Regards,


>>> James



>>> On 18/08/2020 08:53, Frank Habicht wrote:

>>>> On 17/08/2020 22:02, Nishal Goburdhan wrote:

>>>>> On 17 Aug 2020, at 16:31, Frank Habicht wrote:



>>>>>> Sure: *these* were created by the member, not by AfriNIC.

>>>>>> But should these not have been removed whilst removing the inet6num ?

>>>>> assume for a minute that the member did not pay their fees.  afrinic

>>>>> themselves, would have happily removed the domain objects as part of

>>>>> “suspending the resources”  (heh!)  even though they were “created by

>>>>> the member”.

>>>> didn't know. good to know. so deleting the domain objects is part of

>>>> that process.


>>>>> so, i’m not sure why you felt it necessary to say:  “ *these* were

>>>>> created by the member”.  as if that confers some sort of special power

>>>>> onto them?

>>>> wanted to get confirmation that they're not that special.



>>>>>> I believe the process of deleting an inet6num is rarely happening, but

>>>>>> a) it sure did and b) it should include taking care of these "dependant"

>>>>>> objects....... right?

>>>>> yes.

>>>> thanks.



>>>>> i seem to remember that there a policy that helps with this .. like

>>>>> “lame delegation” something-or-the-other that’s meant to deal with

>>>>> long-term occurrences of this.  so, even if the db-admin, for reasons

>>>>> unknown, deigned to remove the domain objects, said objects _should_

>>>>> have been reported, and acted on.  iirc, the details were left to

>>>>> afrinic to implement, but i stand to correction.

>>>> there's no lameness (yet). domain in question is served by my ($dayjob)

>>>> servers. And I was looking to clean that up and that got me to this case.



>>>> I wish we could get a confirmation (from AfriNIC staff) that deleting

>>>> the domain and route objects is (or will from now on be) part of the

>>>> process of de-registering any inetnum / inet6num object.



>>>> Frank



>>>> _______________________________________________

>>>> DBWG mailing list

>>>> DBWG at afrinic.net

>>>> https://lists.afrinic.net/mailman/listinfo/dbwg

>> _______________________________________________

>> DBWG mailing list

>> DBWG at afrinic.net

>> https://lists.afrinic.net/mailman/listinfo/dbwg


More information about the DBWG mailing list