[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mitigating DNS amplification attacks
- Subject: Mitigating DNS amplification attacks
- From: tstpierre at iweb.com (Thomas St-Pierre)
- Date: Wed, 1 May 2013 00:42:06 +0000
- In-reply-to: <[email protected]om>
We offer a DNS hosted solution, most people still use their own servers though. (especially those with control panels such as cPanel or plesk, where it's built-in).
As for BCP38, I would love to stop the spoofed packets, however with them coming from our upstreams, (Level3, Cogent, Tata, etc) I don't see how we can.
From: Damian Menscher <damian at google.com<mailto:damian at google.com>>
Date: Tuesday, 30 April, 2013 8:32 PM
To: "Thomas St.Pierre" <tstpierre at iweb.com<mailto:tstpierre at iweb.com>>
Cc: "Dobbins, Roland" <rdobbins at arbor.net<mailto:rdobbins at arbor.net>>, NANOG list <nanog at nanog.org<mailto:nanog at nanog.org>>
Subject: Re: Mitigating DNS amplification attacks
On Tue, Apr 30, 2013 at 5:28 PM, Thomas St-Pierre <tstpierre at iweb.com<mailto:tstpierre at iweb.com>> wrote:
On 13-04-30 7:57 PM, "Dobbins, Roland" <rdobbins at arbor.net<mailto:rdobbins at arbor.net>> wrote:
>On May 1, 2013, at 6:43 AM, Thomas St-Pierre wrote:
>> We've been sending emails to our clients but as the servers are not
>>managed by us, there's not much we can do at that level.
>Sure, there is - shut them down if they don't comply. Most ISPs have AUP
>verbiage which would apply to a situation of this type.
Unfortunately I somehow doubt management is going to look favourably on a
request to shut down so many clients. :( The large majority of the servers
being used in the attacks are not open resolvers. Just DNS servers that
are authoritative for a few domains, and the default config of the dns
application does referrals to root for anything else.
Offering a DNS service to your customers may allow you to provide a good alternative to push those customers onto. You can then manage it properly.
But I think DNS isn't the real issue here, it's the fact you're receiving spoofed traffic. I'd start by tracking the attacks backwards through your upstreams, as obviously someone in the path isn't enforcing BCP 38. Stop the spoof capability and the attacks will stop. It requires less effort overall (vs your counterparts at every hosting provider needing to solve the problem for their networks) and provides the best benefit to the victims.