[DBWG] stale route6 and domain objects for removed inet6num
geier at geier.ne.tz
Wed Aug 19 18:14:47 UTC 2020
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
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!!!]
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.
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.
> 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?
>>> 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.
>> DBWG mailing list
>> DBWG at afrinic.net
More information about the DBWG