Sun, 17 May 2015 07:23:54 +0200
The problem was resolved during the course of yesterday afternoon. We have received the following explanation from AFRINIC:
QUOTE(AFRINIC @ May 16 2015, 20:44 PM)
During today we had an issue with the system that provisions reverse DNS delegation data for many of the *.in-addr.arpa zones associated with legacy IPv4 addresses.
This problem affected reverse DNS for a number of allocations to AFRINIC members from some of the legacy /8 blocks that are shared between multiple RIRs. For these shared /8 ranges, the majority RIR manages the relevant xxx.in-addr.arpa zone, using input from the other, minority, RIRs.
The legacy /8 blocks where AFRINIC is in the minority, have reverse DNS delegation data stored and managed in the AFRINIC WHOIS database like any other resources. This information is then extracted, reformatted and shared with the systems of the relevant majority RIR automatically.
Earlier today, we were alerted to a problem with this process whereby the DNS zone information provided to the other RIRs was, in some cases, missing records.
This was traced to a recently provisioned testing system which was erroneously synchronising test data into our DNS provisioning system (and FTP) in parallel with valid WHOIS data.
This also slipped past existing monitoring and built in error checking; the leaking test data was not valid in content and very minimal, but it was never malformed or corrupt.
The testing system in question has been fixed. None of the AFRINIC production systems had any technical issues apart from having incorect data inputs.
We will be reviewing our processes of systems provisioning and configuration management. And we sincerley apologise for any and all inconvieniences that may have resulted.