I agree with Roland on the firewall placement. I add that the attack would have likely succeeded to exhaust the servers. There is alot of recent ddos activity on DNS with what looks like legitimate queries. You should also look at some DOS/ application level protections; Radware and Arbor top the list.
Yeah like I say, it wasn't my idea to put DNS behind firewalls. As long as it is not *my* firewalls I really don't care what they do 
As you're posting here, it looks like it's become your problem. 
Seriously, though, there is no value to maintaining state for DNS queries.
You would be much better off to put your firewall production interfaces on
a routed port on a hardware router so that you can implement ASIC packet
filtering. This will operate at wire speed without dumping you into the
colloquial poo every time someone decides to take out your critical
infrastructure.
Nick
I get the feeling that leigh had implemented this against his own
advice for a client... that he's onboard with 'putting a firewall in
front of a dns server is dumb' meme...
In principle, this is certainly correct (and I've often said the same thing
about web servers); in practice, though, a lot depends on the specs. For
example: can the firewall discard useless requests more quickly? Does it do
a better job of discarding malformed packets? Is the vendor better about
supplying patches to new vulnerabilities? Can it do a better job filtering
on source IP address? Does it do load-balancing? Are there other services
on the same server IP address that do require stateful filtering?
As I said, most of the time a dedicated DNS appliance doesn't benefit from
firewall protection. Occasionally, though, it might.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Yeah like I say, it wasn't my idea to put DNS behind firewalls. As long
as it is not *my* firewalls I really don't care what they doAs you're posting here, it looks like it's become your problem.
Seriously, though, there is no value to maintaining state for DNS queries.
You would be much better off to put your firewall production interfaces on
a routed port on a hardware router so that you can implement ASIC packet
filtering. This will operate at wire speed without dumping you into the
colloquial poo every time someone decides to take out your critical
infrastructure.I get the feeling that leigh had implemented this against his own
advice for a client... that he's onboard with 'putting a firewall in
front of a dns server is dumb' meme...In principle, this is certainly correct (and I've often said the same thing
about web servers); in practice, though, a lot depends on the specs. For
example: can the firewall discard useless requests more quickly? Does it do
a better job of discarding malformed packets? Is the vendor better about
supplying patches to new vulnerabilities? Can it do a better job filtering
on source IP address? Does it do load-balancing? Are there other services
on the same server IP address that do require stateful filtering?
yup... I think roland and nick (he can correct me, roland I KNOW is
saying this) are basically saying:
permit tcp any any eq 80
permit tcp any any eq 443
deny ip any any
is far, far better than state management in a firewall. Anything more
complex and your firewall fails long before the 7206's
interface/filter will 
Some folks would say you'd be better off
doing some LB/filtering-in-software behind said router interface
filter, I can't argue with that.
As I said, most of the time a dedicated DNS appliance doesn't benefit from
firewall protection. Occasionally, though, it might.
I suspect the cases where it MAY benefit are the 'lower packet rate,
ping-o-death-type' attacks only though. Essentially 'use a proxy to
remove unknown cruft' as a frontend to your more complex dns/web
answering system, eh?
under load though, high pps rate attacks/instances (victoria secret
fashion-show sorts of things) your firewall/proxy is likely to die
before the backend does ;(
-chris
>
>
>>>> Yeah like I say, it wasn't my idea to put DNS behind firewalls. As
long
>>>> as it is not *my* firewalls I really don't care what they do
>>>
>>> As you're posting here, it looks like it's become your problem.
>>>
>>> Seriously, though, there is no value to maintaining state for DNS
queries.
>>> You would be much better off to put your firewall production
interfaces on
>>> a routed port on a hardware router so that you can implement ASIC
packet
>>> filtering. This will operate at wire speed without dumping you into
the
>>> colloquial poo every time someone decides to take out your critical
>>> infrastructure.
>>
>> I get the feeling that leigh had implemented this against his own
>> advice for a client... that he's onboard with 'putting a firewall in
>> front of a dns server is dumb' meme...
>
> In principle, this is certainly correct (and I've often said the same
thing
> about web servers); in practice, though, a lot depends on the specs.
For
> example: can the firewall discard useless requests more quickly? Does
it do
> a better job of discarding malformed packets? Is the vendor better
about
> supplying patches to new vulnerabilities? Can it do a better job
filtering
> on source IP address? Does it do load-balancing? Are there other
services
> on the same server IP address that do require stateful filtering?
yup... I think roland and nick (he can correct me, roland I KNOW is
saying this) are basically saying:permit tcp any any eq 80
permit tcp any any eq 443
deny ip any anyis far, far better than state management in a firewall. Anything more
complex and your firewall fails long before the 7206's
interface/filter will
doing some LB/filtering-in-software behind said router interface
filter, I can't argue with that.> As I said, most of the time a dedicated DNS appliance doesn't benefit
from
> firewall protection. Occasionally, though, it might.
I suspect the cases where it MAY benefit are the 'lower packet rate,
ping-o-death-type' attacks only though. Essentially 'use a proxy to
remove unknown cruft' as a frontend to your more complex dns/web
answering system, eh?under load though, high pps rate attacks/instances (victoria secret
fashion-show sorts of things) your firewall/proxy is likely to die
before the backend does ;(
Very refreshing tone of conversation. Normally I hear a chorus of "defense
in depth" blah when we should be talking about fundamental host / protocol
based robustness.... and matching risks with controls ...not boxes with
places on a network map.
It leads to: security is like an onion, it makes you cry
The ng stateful firewall is no firewall (tm)
I like https://www.opengroup.org/jericho/index.htm
Cb
yup... I think roland and nick (he can correct me, roland I KNOW is saying this) are basically saying:
permit tcp any any eq 80
permit tcp any any eq 443
deny ip any any
is far, far better than state management in a firewall. Anything more complex and your firewall fails long before the 7206's interface/filter will 
Some folks would say you'd be better off doing some LB/filtering-in-software behind said router interface filter, I can't argue with that.
But you don't get the benefit of UNIFIED THREAT MANAGEMENT or syn-authentication with an access-list or what happens if someone sends your wordpress blog a malformed GET request which causes it to give the attacker root? Or Slowloris, or one of any thousand other HTTP protocol based attacks?
(I'm being sarcastic but that is the argument you will hear).
Seriously though if there is one thing I wish people would stop doing it is releasing web vulnerability scanners for free (like acunetix), they're easy enough to catch because they use sitemaps but they can be a bit annoying and generate a lot of load =)
-Drew