[NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations
dougb at dougbarton.us
Sun Mar 19 04:27:11 UTC 2017
Thanks for the response, John. Some thoughts below.
On 03/18/2017 08:58 PM, John Curran wrote:
> On 18 Mar 2017, at 9:58 PM, Doug Barton <dougb at dougbarton.us
> <mailto:dougb at 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.)
I have used the latter type of system with good results, for what it's
worth. And funny you should mention 10%, as that's what I've found to be
fairly commonly at least a yellow flag, if not a big red one.
> 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,
If you're not already having ongoing discussions about said changes well
in advance, your system is broken.
> 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.)
See above. Also, not putting in place *new* changes on a scale
sufficient to trip the heuristics is far superior to automatically
putting in place changes that take huge chunks of address space off the
network. Or am I missing something?
And if you're having regular conversations with your "customers" in this
scenario about upcoming major changes, tripping the alarm should only
happen if someone, somewhere, made a mistake. Thus, human intervention
is required regardless.
But, see below.
> 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.)
Already did, thanks. :) Meanwhile, one could make a legitimate argument
that even absent specific guidance from RIPE, ARIN should have a
sufficient level of concern for the health of the larger Internet to
consider unilateral action here. At least in the form of delaying
implementation until some human coordination takes place.
Personally, I don't buy, "They told us to do it!" as a legitimate
> 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
Yes, deeply familiar with that problem. Are you dealing with any address
blocks smaller than a /24? If the answer is no (which it almost
certainly is), what challenges are you facing that you haven't figured
out how to overcome yet? (Even < /24 blocks can be dealt with,
obviously, but I'd be interested to learn that there are problems with
/24 and up that are too difficult to solve.)
Personally, I would be happy to donate my time to help y'all sort this
out, and I'm sure there are others who would also be willing to help.
More information about the NANOG