Message from discussion about DNS RRL
Received: by 10.66.83.35 with SMTP id n3mr4653119pay.23.1350462878496;
Wed, 17 Oct 2012 01:34:38 -0700 (PDT)
From: Phil Mayers <p.may...@imperial.ac.uk>
Subject: Re: about DNS RRL
Date: Wed, 17 Oct 2012 09:34:26 +0100
X-Trace: usenet.stanford.edu 1350462878 28262 188.8.131.52 (17 Oct 2012 08:34:38 GMT)
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:16.0) Gecko/20121010 Thunderbird/16.0.1
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org
List-Id: BIND Users Mailing List <bind-users.lists.isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/17/2012 09:17 AM, pangj wrote:
> I have read the document of redbarn RRL for BIND and this NSD RRL:
> I have a question that, since the DDoS to DNS are coming from spoofed
> IPs. But RRL is working based on source IP. So how can it stop the real
> life attack?
It doesn't stop it (indeed, can't). It mitigates the impact.
The DDoS tend to come from a fixed set of spoofed source at any one
time. RRL helps, in that it:
1. punts early in the path, lowering resolver CPU use, and
2. returns a minimal response, which prevents amplification.
Remember the DDoS is actually directed at the spoofed source, not the
DNS server. The DNS server is merely an unwilling participant. RRL helps
prevent that participation.
There is, as I understand it, some spotty evidence that the attackers
will move to a different server if RRL seems to be in use. How this
happens I don't know - maybe they probe with real IPs? - but I've heard
others emphatically claim this is not the case, and attackers will
continue to blindly flail at you until the attacking node goes down.
The only solution to these kinds of attacks is for providers to
implement BCP 38, and for upstream providers to start de-peering
providers who don't. I rate this about as likely as... a very unlikely
S/RTBH can help the DNS provider, if they're being overwhelmed and their
upstream supports it.