1 |
On 03/28/2013 03:16 PM, Alan McKinnon wrote: |
2 |
> On 28/03/2013 17:38, Michael Mol wrote: |
3 |
>> On 03/28/2013 04:51 AM, Norman Rieß wrote: |
4 |
>>> Hello, |
5 |
>>> |
6 |
>>> i am using pdns recursor to provide a dns server which should be usable |
7 |
>>> for everybody.The problem is, that the server seems to be used in dns |
8 |
>>> amplification attacks. |
9 |
>>> I googled around on how to prevent this but did not really find |
10 |
>>> something usefull. |
11 |
>>> |
12 |
>>> Does anyone got an idea about this? |
13 |
>> |
14 |
>> I'm not sure it can be done. You can't make a resolver available to |
15 |
>> "everybody" without somebody in that "everybody" group abusing it, and |
16 |
>> that's exacly what happens in a DNS amplification attack. |
17 |
>> |
18 |
>> Restrict your resolver to be accessible only to your network or, at |
19 |
>> most, those of the specific group of people you're seeking to help. |
20 |
>> |
21 |
>> You *might* try restricting the resolver to only respond to TCP requests |
22 |
>> rather than UDP requests, |
23 |
> |
24 |
> NO NO NO NO NO |
25 |
> |
26 |
> Under no circumstances ever do this. The service breaks horribly when |
27 |
> you do this and it has to work even remotely hard. Most likely your ISP |
28 |
> will outright ban you for that if you use the ISP's caches. I knwo I do, |
29 |
> and so does every other major ISP in this country. |
30 |
|
31 |
Er, what? When we're talking about a recursive resolver requiring |
32 |
clients connecting to it to use TCP, what does upstream care? He's |
33 |
talking about running his own open DNS server. |
34 |
|
35 |
> |
36 |
> but if the resolver sends response data along |
37 |
>> with that first SYN+ACK, then nothing is solved, and you've opened |
38 |
>> yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver |
39 |
>> went offline as a result of a SYN flood, at least it wouldn't be part of |
40 |
>> an amplification attack any longer...) |
41 |
> |
42 |
> |
43 |
> Or just use the ISP's DNS caches. In the vast majority of cases, the ISP |
44 |
> knows how to do it right and the user does not. |
45 |
|
46 |
Generally true, though I've known people to choose not to use ISP caches |
47 |
owing to the ISP's implementation of things like '*' records, ISPs |
48 |
applying safety filters against some hostnames, and concerns about the |
49 |
persistence of ISP request logs. |