<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">...<br>
<br>
Jared Mauch wrote:
<blockquote 
cite="mid:DD007CB4-1357-4618-9360-9FA928F74538@puck.nether.net" 
type="cite">
  <pre wrap="">On Feb 19, 2013, at 8:48 AM, Edward Lewis wrote:

</pre>
  <blockquote type="cite"><pre wrap="">...
</pre></blockquote>
  <pre wrap=""><!---->
Sending back TC to "authenticate" clients would likely help reduce the abuse of 'udp any'</pre>
</blockquote>
<br>
no. really. not. the subsequent udp queries you would prospectively 
receive following a successful tcp session in the above scenario need 
not be truly sourced. using a successful tcp session as a gate to a 
lightweight udp session is entirely wrong in terms of protecting 
spoofed-source victims from your orbiting death ray projector. (i'm 
touchy about this since i had the same idea and vernon had to straighten
 me out on the subject.)<br>
<br>
<blockquote 
cite="mid:DD007CB4-1357-4618-9360-9FA928F74538@puck.nether.net" 
type="cite">
  <pre wrap="">I was "forced" to rebuild my dns server in the past week or so.. I have not built-in the rrl patch yet as part of the running server and have noticed that the CPU usage is significantly lower.  (Instead of "150%" it's about 50% of a core).

Right now I'm debating if it makes sense to continue to patch w/ rrl due to the much higher "cost" (2-3x)</pre>
</blockquote>
<pre wrap="">
</pre>
as warren said, this sounds like pilot error or measurement failure. 
your cpu costs under RRL should be far lower during an attack since 
you're avoiding the response marshalling cost, and should be about the 
same during non-attack since the hash table is preallocated and the 
hashing is pretty quick. please investigate your claim above, and report
 back?<br>
<br>
paul<br>
</body></html>