Tightened DNS security question re: DNS amplification attacks.

Mark Andrews Mark_Andrews at isc.org
Tue Jan 27 17:36:29 CST 2009


In message <200901272116.n0RLGiJA002250 at ns1.konadogs.net>, Nate Itkin writes:
> 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 64.57.246.146#64176: view
> > external-in: query: . IN NS +
> > < ... snip ... >
> > since you can't put a "allow-query { none; };" in a hint zone, what can I d
> o
> > 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 64.57.246.146 neq 53 any eq 53

	Which pre-supposes that 64.57.246.146 os not emitting queries of
	its own.

	BCP 140 looked at this problem and concluded that sending
	REFUSED was the best general guidance that can be given.
	While BCP 140 applies to recursive servers, returning REFUSED
	to queries which are not within the namespace served by
	authoritative servers is entirely consistant with BCP 140.

> Also on this topic:
> Coincident with this DNS DOS, I started seeing inbound PTR queries from 
> various hosts on 10.0.0.0/8 (which are blackholed by my DNS servers). 
> They receive no response, yet they persist.  Anyone have thoughts on their 
> part in the scheme?

	If you don't implement BCP 38 you don't block bogus traffic.

	Unless you are using 10.0.0.0/8 then you aren't implementing
	BCP 38 either.  If you were you wouldn't be seeing queries from
	10.0.0.0/8.

	Mark
 
> Best wishes,
> Nate Itkin
> 
-- 
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