Tightened DNS security question re: DNS amplification attacks.

Wed Jan 28 03:46:35 UTC 2009

On Jan 27, 2009, at 10:21 PM, Paul Vixie wrote:

>>
> (looking for ". IN NS" as the q-tuple pattern is not a solution,  
> since the
> bad guys can pretty trivially change the question they ask into one  
> you're
> willing to answer.)

Actually, ". IN NS" is a particularly useful thing for them to do,  
because it's an almost globally guaranteed response that will get a  
large response and be in cache.  One can get similar effects with  
"<tld>. IN NS", of course, but the set of things that work well for  
such an attack are relatively limited.

One thing that's fairly straightforward with the current attack is to  
block

00600 deny udp from 66.230.160.1 to me 53 iplen 45
(foreach victim host)

(If you tcpdump the traffic, because of the . IN NS, the packets are  
all the same length - 45 IP bytes.)  Very easy to filter at the  
current time with almost no collateral damage.

I realize this is just a cat-and-mouse game, but forcing the attacker  
to use larger query packets that have smaller cached replies isn't a  
bad thing.

". NS" -> 45 byte query, 245 byte response
"COM. NS" -> 48 byte query, 245 byte response
"NET. NS" -> 242 byte response,
"ORG. NS" -> 159 byte response,

This masking is mostly effective for people whose nameservers are set  
to deny recursive but are still serving from cache.  YMMV.

   -Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090127/632a06dd/attachment.sig>