Tightened DNS security question re: DNS amplification attacks.

Mark Andrews Mark_Andrews at isc.org
Wed Jan 28 00:50:55 UTC 2009

In message < at imap.ameslab.gov>, "Douglas C. St
ephens" writes:
> At 03:16 PM 1/27/2009, Nate Itkin wrote:
> >On Tue, Jan 27, 2009 at 03:04:19PM -0500, Matthew Huff wrote:
> > > < ... snip ... >
> > > dns queries to the . hint file
> > > are still occuring and are not being denied by our servers. For example:
> > > 27-Jan-2009 15:00:22.963 queries: client view
> > > external-in: query: . IN NS +
> > > < ... snip ... >
> > > since you can't put a "allow-query { none; };" in a hint zone, 
> > what can I do
> > > to deny the query to the . zone file?
> >
> >
> >AFAIK, that's about the best you can do with the DNS configuration. You've
> >mitigated the amplification value, so hopefully the perpetrator(s) will drop
> >you. If you're willing to keep up with the moving targets, the next level
> >is an inbound packet filter. Add to your inbound ACL:
> >
> >deny udp host neq 53 any eq 53
> >
> >Also on this topic:
> >Coincident with this DNS DOS, I started seeing inbound PTR queries from
> >various hosts on (which are blackholed by my DNS servers).
> >They receive no response, yet they persist.  Anyone have thoughts on their
> >part in the scheme?
> >
> >Best wishes,
> >Nate Itkin
> I'm not seeing those PTR queries for, but then my perimeter
> ingress/egress filters (BCP 38) toss most of that kind of junk before my
> DNS servers ever see it.
> I agree that is as far as one can go with BIND, right now.  However, that
> isn't making the perpetrators cease and desist.  I am seeing ongoing query
> attempts coming in and refusal packets going back out, and the targets
> don't seem to change until I do something to block them.  So mitigating
> the amplification factor does not seem of interest to these perpetrators.
> On the contrary, even REFUSED responses can aggregate with some amplified
> responses to enhance the apparent DoS goal.  Thus BCP 140 seems to be
> less than completely effective because it is less than universally applied
> (i.e., older versions of BIND or misconfigured BIND.)  I think the same
> situation is true with BCP 38: less than universally applied.  So do I wait
> for universal application of these BCPs, or do I take responsibility for
> doing what I can to make my network resources less appealing for abuse?
> I choose the latter, and that is why went to the effort of blocking this
> abusive traffic before it reaches my authoritative-only DNS servers.
> Nevertheless, I also agree with a point made last week that trying to keep up
> with the changing targets is a game of whack-a-mole that is and will continue
> to be a drain on network management resources -- if the detection and respons
> e
> continues to be deployed manually.  This is why I wrote some Perl for my
> authoritative-only servers to automate detection and response at the server
> level.  Granted it isn't a permanent solution, but at least it is a place
> to start.  I appended that code below for those who are interested in it.

	Which will just make the attacks evolve.  It's pretty easy
	to design a amplifing DNS attack which is almost indetectable
	unless you know which addresses are being targeted.  This
	one is highly visible in the logs.

	A much more productive task would be to trace back the
	offending traffic and to put into place policies which
	require BCP 38 deployment by those you connect to.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org

More information about the NANOG mailing list