On 18 Mar 2017, at 9:58 PM, Doug Barton <dougb@dougbarton.us> wrote:
My eyebrows reacted to this the same way Bill's did. It sounds like this is at least a semi-automated system. Such things should have sanity checks on the receiving side when told to remove large gobs of data, even if the instructions validate correctly.
More fundamentally, according to the RIPE report they are sending you something called "zonelets" which you then process into actual DNS data. Can you say something about the relative merit of this system, vs. simply delegating the right zones to the right parties and letting the DNS do what it was intended to do?
At minimum the fact that this automated system was allowed to wipe out great chunks of important data calls it into question. And sure, you can all 3 fix the bugs you found this time around, but up until these bugs were triggered you all thought the system was functioning perfectly, in spite of it ending up doing something that obviously was not intended.
Doug - We could indeed decide to ignore correctly formatted and signed information if it doesn’t match some heuristics that we put in place (e.g. empty zone, zone with only 1 entry, zone that changes more than 10% in size, etc.) Some downsides with this approach is that that: 1) we’d be establishing heuristics for data that originates with a different organization and absent knowledge of their business changes, and 2) this would be mean that there could be occasions where proper data cannot be installed without manual intervention (because the changes happens to be outside of whatever heuristics have previously been put in place.) Despite the associated risk, we are happy to install such checks if RIPE requests them, but are this time are processing them as we agreed to do so – which is whenever we receive correctly formatted and properly signed requests from them. (You should inquire to RIPE for more detail regarding their future intentions in this regard.) As to why DNS-native zone operations are not utilized, the challenge is that reverse DNS zones for IPv4 and DNS operations are on octet boundaries, but IPv4 address blocks may be aligned on any bit boundary. Thus, a single IPv4 octet range may contain IPv4 address blocks that are administered by multiple RIRs, making it is necessary for one RIR to be authoritative for the entire zone and other RIRs to send information seperately on their IPv4 address blocks in that same range so that it gets included in the appropriate zone file. Excellent questions - thanks! /John John Curran President and CEO ARIN