1 |
On 28/03/2013 21:38, Michael Mol wrote: |
2 |
> On 03/28/2013 03:16 PM, Alan McKinnon wrote: |
3 |
>> On 28/03/2013 17:38, Michael Mol wrote: |
4 |
>>> On 03/28/2013 04:51 AM, Norman Rieß wrote: |
5 |
>>>> Hello, |
6 |
>>>> |
7 |
>>>> i am using pdns recursor to provide a dns server which should be usable |
8 |
>>>> for everybody.The problem is, that the server seems to be used in dns |
9 |
>>>> amplification attacks. |
10 |
>>>> I googled around on how to prevent this but did not really find |
11 |
>>>> something usefull. |
12 |
>>>> |
13 |
>>>> Does anyone got an idea about this? |
14 |
>>> |
15 |
>>> I'm not sure it can be done. You can't make a resolver available to |
16 |
>>> "everybody" without somebody in that "everybody" group abusing it, and |
17 |
>>> that's exacly what happens in a DNS amplification attack. |
18 |
>>> |
19 |
>>> Restrict your resolver to be accessible only to your network or, at |
20 |
>>> most, those of the specific group of people you're seeking to help. |
21 |
>>> |
22 |
>>> You *might* try restricting the resolver to only respond to TCP requests |
23 |
>>> rather than UDP requests, |
24 |
>> |
25 |
>> NO NO NO NO NO |
26 |
>> |
27 |
>> Under no circumstances ever do this. The service breaks horribly when |
28 |
>> you do this and it has to work even remotely hard. Most likely your ISP |
29 |
>> will outright ban you for that if you use the ISP's caches. I knwo I do, |
30 |
>> and so does every other major ISP in this country. |
31 |
> |
32 |
> Er, what? When we're talking about a recursive resolver requiring |
33 |
> clients connecting to it to use TCP, what does upstream care? He's |
34 |
> talking about running his own open DNS server. |
35 |
|
36 |
Because the list is indexed and archived and Googled forever. Others may |
37 |
get the idea that TCP-only DNS caches are a good idea in general. Have |
38 |
you ever had to deal with the insanity caused when Windows Servers |
39 |
insist on using TCP only, and YOU are the upstream? |
40 |
|
41 |
I understand what the OP was suggesting, but he did not limit the |
42 |
usefulness and scope of the suggestion, so I did. |
43 |
|
44 |
> |
45 |
>> |
46 |
>> but if the resolver sends response data along |
47 |
>>> with that first SYN+ACK, then nothing is solved, and you've opened |
48 |
>>> yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver |
49 |
>>> went offline as a result of a SYN flood, at least it wouldn't be part of |
50 |
>>> an amplification attack any longer...) |
51 |
>> |
52 |
>> |
53 |
>> Or just use the ISP's DNS caches. In the vast majority of cases, the ISP |
54 |
>> knows how to do it right and the user does not. |
55 |
> |
56 |
> Generally true, though I've known people to choose not to use ISP caches |
57 |
> owing to the ISP's implementation of things like '*' records, ISPs |
58 |
> applying safety filters against some hostnames, and concerns about the |
59 |
> persistence of ISP request logs. |
60 |
|
61 |
I get a few of those too every now and again. I know for sure in my case |
62 |
their fears are unfounded, but can't prove it. Those few (and they are |
63 |
few) can go ahead and deploy their own cache. I can't stop them, they |
64 |
are free to do it, they are also free to ignore my advice of they choose. |
65 |
|
66 |
|
67 |
|
68 |
|
69 |
|
70 |
-- |
71 |
Alan McKinnon |
72 |
alan.mckinnon@×××××.com |