My apologies for having failed to report to this recent message sooner. In message <[email protected]>, AFRINIC Communication <[email protected]> wrote:
>Following your inquiry regarding the existence of inconsistencies >between reverse DNS delegation records within the WHOIS Database and the >published RDNS zone files at ftp://ftp.afrinic.net/pub/zones/ directory, >we have carried out further analysis and below are the findings. > >1. This situation is a result of the presence of overlapping records >in the WHOIS Database. The script that picks and publishes to the ftp >picks only the reverse DNS domain covering the less specific prefix, for >instance with reference to the example provided, the ftp file contains >the record for 203.196.in-addr.arpa and not any other more specific >reverse DNS records such as 35.203.196.in-addr.arpa > >2. These overlapping records are historical and date back to the >period between 2004 - 2007 and the whois at that time did not have the >checks that guard against creation of these overlaps. > >The issue regarding the existence of these overlaps in the WHOIS >Database was raised by staff during the first database working group >session at AIS-19 in Kampala, for the best way forward on resolving this >and the consensus was that nothing should be done. The DBWG session >report is available here: > >https://lists.afrinic.net/pipermail/dbwg/2019-June/000140.html > >Going forward, we intend to ensure that these overlapping records are >cleared and no longer present inconsistencies. I'm sorry, but I must take issue, in a modest way, with this chosen resolution. I believe that you have explained the "issue" of the "overlapping" reverse DNS delegations clearly, but I am not persuaded that there is actually any problem here, other than that some of the AFRINIC reverse DNS delegations were not being represented in the public AFRINIC zone file(s). I must ask the question: Why should it be considered to be either "bad" or even "a problem" if AFRINIC maintains reverse DNS delegations for, say, some /16 and also and separately, maintains a different reverse DNS delegation for some particular /24 block which is a part of that larger containing /16 block? It is certainly the case that if AFRINIC has allocated, for example, some large containing block to some party or entity and if it has also properly delegated to that party/entity responsibility for handling the reverse DNS for that entire block, then if the block registrant wishes to do so, he/she/it can then sub-delegate parts of this responsibility to others parties himself. But I see nothing which technically prevents AFRINIC itself from delegating reverse DNS athority for, say, some /16 block to some specific name servers even while it also and separately delegates the reverse DNS authority for some sub-block of that containing /16 block to some different set of name servers. In fact, I am going to go out on a limb here and assert that other Regional Internet Registries are in fact doing this exact thing, i.e. frequently delegating authority for reverse DNS for both contained blocks and, in some cases, for their containing blocks. (I will attempt to find and present some actual examples from each of the other RIRs if anyone thinks that may be helpful here.) I may be wrong in my assertion that other RIRs are themselves providing separate rDNS delegations for both blocks and sub-blocks thereof, but I don't think so. If I am correct, then there is really nothing for AFRINIC to "clean up" here, other than some slight tweeking of the code used to generate AFRINIC's public reverse DNS zone files. I would hasten to add that the question of whether any of the other five RIRs are or are not doing rDNS delegation for both blocks and (separately) for contained sub-blocks is almost irrelevant, and that AFRINIC is, I believe, free to choose whether it will do this or not do this as it wishes. As I have said above, I am not personally aware of any technical issue that would absolutely -prevent- AFRINIC from delegating to both blocks and also (and separately) to contained sub-blocks also. (And indeed, it sounds to me like this -is- already being done in some instances, so just from a technical perspective, it seems to work.) In any case, I wish to thank the technical staff for their attention to this set of issues, and in particular to the issue I originally raised which related just to the content of the public zone files, and which did not delve into the separate issue/question of what kinds of rDNS delegations AFRINIC should or should not be doing. (I think this latter stuff is a policy issue, not a tecnhical one, and I have no real opinion on the question of which rDNS delegations AFRINIC should or should not be doing, in general, other than to express my hope that it all continues to function at least as well as it currently does.... except, of course, for any of the still stolen blocks.) >Please note that the issue of duplicate domain objects in the database >was resolved last week. Excellent! Thanks also for that! Regards, rfg _______________________________________________ Community-Discuss mailing list [email protected] https://lists.afrinic.net/mailman/listinfo/community-discuss
