Dear Cedrick, It is ok with me if you use one of the 2 VMs in Dar es Salaam for auth DNS to also do the digging for the lameness, ie as a second node.
I trust these are sufficiently diverse from your 1st node, they are in AS327844, with upstreams AS37084 and AS30844. Hope that can help. Regards, Frank On 10/09/2020 21:20, Cedrick Adrien Mbeyet wrote: > Dear dbwg, > > > Referring to the previous email from my colleague Simon. > > We indeed delayed the deletion of the lame records for multiple reason > among them the absence of a second nodes. We had some security > challenges that needed to be addressed before being able to plan the > second nodes. > > We do apologize for the delay on the second node implementation and rest > tune as deployment will be scheduled very soon. And usual, announced on > the usual channels. > > Thanks and regards, > > > -- > _______________________________________________________________ > Cedrick Adrien Mbeyet > IT Infrastructure Unit Manager, AFRINIC Ltd. > t: +230 403 5100 / 403 5115 | f: +230 466 6758 | tt: @afrinic | w: > www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > ______________________________________________________ > > On 07/09/2020 16:59, Simon Seruyinda wrote: >> Hi Frank, >> >> The e-mail attribute was made mandatory in July 2012. >> I have done a quick check in the database and we have 1048 person objects >> without the email attribute. >> Most of these objects belong to legacy resource holders and were imported >> into the database during the initial setup. >> Many are referenced in different objects. Below are some stats regarding >> number of objects that are referencing these person objects as >> admin-c,tech-c or zone-c. >> >> zone-c: >> =============== >> 51 domain objects >> >> tech-c >> =============== >> as-block 248 >> as-set 11 >> domain 35 >> inetnum 574 >> mntner 60 >> org 162 >> role 7 >> route-set 6 >> >> admin-c: >> ============== >> as-block 248 >> as-set 11 >> aut-num 2 >> domain 49 >> inet6num 1 >> inetnum 731 >> mntner 71 >> org 137 >> role 4 >> route-set 6 >> >> There is an ongoing project internally focused on contacting these legacy >> holders in order to update their contact details in the database. Another >> activity, under the scope of the whois business rules inconsistencies is >> also planned to get the emails updated for any resource members who may be >> having no emails in the any of their person objects. Incases where efforts >> to get in touch with the resource holder proves futile, a temporary measure >> using AFRINIC’s placeholder email accounts is undertaken. These activities >> are expected to decrease the number significantly. >> >> With regards to the lame delegation handling, we are not doing deletion yet >> since we are running only one node to do the lame delegation checks. Once >> the second node is setup, we shall begin the deletion otherwise for now we >> run the risk of a few false positives. >> >> Regarding the rdns objects size, thanks for bringing this up for discussion. >> Currently we have a limit for IPv4 set to minimum of /24, but there is no >> limit implemented for IPv6, so it will go up to 128. >> I agree this could lead to unnecessary db growth and i think a limit should >> be set. Input from the DBWG members on what would be the appropriate minimum >> would highly be appreciated. >> >> Regards; >> Simon >> >>> On 6 Sep 2020, at 22:22, Frank Habicht <[email protected]> wrote: >>> >>> Hi AfriNIC staff, >>> >>> since when is the 'e-mail:' attribute for 'person' objects mandatory? >>> >>> I just found >>> nic-hdl: SE1-AFRINIC >>> that does not have an email. >>> >>> It's got a GENERATED maintainer, and I'm also wondering how these new >>> maintainer credentials were communicated to the "person". >>> >>> Yes, I don't want to rely on 'changed:' attributes. >>> >>> Staff: >>> How many 'person' objects don't have an 'e-mail:' attribute ? >>> >>> >>> [slowly getting to another issue....] >>> >>> Why did I get to check this person object at all....? >>> >>> Because in a domain object it is >>> tech-c: SE1-AFRINIC >>> zone-c: SE1-AFRINIC >>> >>> >>> Also, the domain object is since "2020-02-02 02:02" >>> ( nice time stamp!! ;-) ) marked as all 'nserver' being *lame*. >>> So when is it meant to get deleted? >>> I hope we're not waiting for the tech-c or zone-c to respond to the >>> email, which we could not send, because the 'person' doesn't have an >>> email address? >>> >>> But what really got me to check the domain object: >>> >>> domain: >>> 0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.f.3.4.1.0.0.2.ip6.arpa >>> >>> yes, it's a bit long. a reverse DNS delegation for a /128 >>> >>> This is probably "legal". >>> But: >>> a) if disputable 'usefulness', and >>> b) I see "tremendous' potential for growth in the DB - in a bad way >>> >>> >>> All, Staff and WG: >>> >>> should creation of domain objects be limited to certain prefix sizes? >>> >>> >>> Thanks, >>> Frank >>> >>> _______________________________________________ >>> DBWG mailing list >>> [email protected] >>> https://lists.afrinic.net/mailman/listinfo/dbwg >> _______________________________________________ >> DBWG mailing list >> [email protected] >> https://lists.afrinic.net/mailman/listinfo/dbwg _______________________________________________ DBWG mailing list [email protected] https://lists.afrinic.net/mailman/listinfo/dbwg
