[dns-operations] if you're banning ANY queries, don't forget to ban SOA as well

[Damian Menscher]

On Mon, Sep 5, 2016 at 11:21 AM, Doug Barton <dougb at dougbarton.us> wrote:

>
> You're making the same mistake that a lot of people who are interested in
> fighting spam do. You're dismissing individual components of a larger
> solution because individually they don't solve the whole problem.
>

I'm not making any mistakes. :-)

You're also making a more subtle error in reasoning. You're modeling a
> specific (relatively sophisticated) type of attacker, and creating a plan
> to defeat *that* attacker. The problem is that DDOS instigators come in all
> shapes and sizes, and many of them are not very smart. They are simply
> using a prefab script, perhaps with one or two edits of their own, and they
> will keep using it till it stops working.
>
> Of course there are sophisticated actors out there, but that doesn't mean
> we should not plug all the holes we can, especially when the solutions are
> simple and thorough.


I was responding to Vixie's admonition to look at the problem from an
economic standpoint and not waste our time doing things that strain the
industry but have no impact in solving the problem.  I gave clear arguments
that disabling ANY, deploying RRL, and cleaning up open recursives all fall
into that category.  They all help, but fail Vixie's test of being
worthwhile to focus efforts on.

On 9/5/2016 7:47 AM, Damian Menscher wrote:
>
> 1) Bypassing ANY is trivial for the attacker, as they can switch to TXT
>> or any other record.
>>
>
> I think you're making the same point that Paul did in his OP. :)


Yes, but he then went on to recommend (2), which I showed to be just as
"silly" (his words) on the very next line:

Enabling RRL doesn't fix this because...
>> 2) Amplifying off recursive servers rather than authoritative servers
>> bypasses RRL.
>>
>
> True, but the fewer authorities that don't run RRL, the better. We want to
> plug as many holes as we can.
>

Again, read Vixie's economic argument: don't waste time doing things that
don't help.

Also, RRL has benefits to the server operator as well. In the event someone
> does try to use them, their own bandwidth costs don't shoot through the
> roof. So good net.citizenship + reduced bandwidth costs. That's a win/win.
>
> Also, you can enable RRL for a recursive server. :) (But see below)
>
> This is a trivial change for the attacker.  Shutting down
>> open recursives isn't economically viable because...
>> 3) The Open Resolver Project sees well over 10M open recursives.  An
>> attacker needs ~10k to launch a successful attack.  So we need to shut
>> down 99.9% before they even need to change a line of code.
>>
>
> Yes, you have correctly identified a problem here. So good education for
> those operators will help, but not eliminate it. Also, the same operators
> who want to run open (or are doing so accidentally) are the same who are
> not likely to know how to enable RRL.
>
> But I'm not sure throwing our hands in the air is the right answer here.
> In any case ...
>
> But even
>> then, we've achieved nothing because...
>> 4) DNS amplification is actually old-school --- the new hotness is
>> amplifying off NTP or SSDP.  There are several other protocols as well
>> (and it's likely new ones will continue to be created).
>>
>
> You're wrong on two counts here. First, why did they move off of DNS? It
> wouldn't have anything to do with the fact that we're closing off attack
> vectors, would it?
>

No, I don't think it does.  I think they moved to NTP because the
amplification factor is *significantly* higher than for DNS.

Second, you're wrong that DNS DDOS is not happening. Sure the other vectors
> are becoming more popular, but since DNS still works, it's still used. And
> NTP has reduced quite a bit because fixing the holes there were fairly
> simple to do.
>

I don't think NTP is reduced because the holes were fixed, but rather
because several ISPs started aggressively rate-limiting 123/udp.

The whole thing is an arms race. We can't say, "Well none of the really
> COOL attackers are using this vector, so I won't bother myself with it."


But attacker coolness matters!  I'm not going to waste my time chasing
attackers that get 10x amplification when there are attackers getting 100x
amplification.  Yes, 10x (or even 1x) will succeed against home users and
small businesses, but 100x becomes a threat to infrastructure.

But as you say, attackers will do the simple thing till it stops working.
RRL will, at best, cause them to switch to a different script, costing them
minutes(!) of work.

My proposal passes the math/economics sniff test:
>>
>> There are ~500 ASNs that fail to filter spoofed traffic to the internet
>> (due to lack of BCP38 compliance).  Most spoofed attacks originate from
>> only a dozen of them.  If we get those cleaned, the attackers need to
>> expend effort to find a new network to spoof from.  This is a bit harder
>> than changing a script, and gets increasingly difficult for them as we
>> clean up the abusive networks.  If we got transit providers on board
>> with caring about the health of the internet rather than the number of
>> octets they carried, they could probably end this discussion in a matter
>> of weeks.
>>
>
> Your argument here is 100% accurate, except for the fact that it totally
> doesn't work. How do I know? Because it hasn't worked for the last 20+
> years that it's been tried. There is no way these networks will change
> anything until they have an economic incentive to do so. I have been saying
> for a long time now that two things need to happen:
>
> 1. Victims of DDOS attacks need to sue the networks that the packets came
> from.
> 2. Large content providers (like Google *cough*) need to tell these
> network operators that they will not accept any packets from them until
> they implement BCP 38.
>
> The combination of those two actions really would solve the problem
> practically overnight. But we have to decide that the pain of implementing
> them is more attractive than the pain we're living with now, and humans
> hardly ever do that.


I'm working to change that (starting by identifying the problematic ASNs
and educating them).  But feel free to advocate for piecemeal solutions
(everyone needs a hobby).

Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160905/c3959b22/attachment.html>