[Community-Discuss] Yet more data base problems/inconsistancies

[Ronald F. Guilmette]

My apologies for having failed to report to this recent message
sooner.

In message <9E14BB14-159B-4877-A1F6-3B436FF8832D at afrinic.net>, 
AFRINIC Communication <comms at afrinic.net> 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