Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

[Doug Barton <dougb () dougbarton us>]

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 () dougbarton us
> <mailto: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.)

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 
response here.

> 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.

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.

Doug