<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">...<br>
<br>
Roland Dobbins wrote:
<blockquote 
cite="mid:cbb9e574-1cba-4460-bae8-7e17ddc88e0f@email.android.com" 
type="cite">
  <pre wrap="">
Paul Vixie <a class="moz-txt-link-rfc2396E" href="mailto:paul@redbarn.org"><paul@redbarn.org></a> wrote:

</pre>
  <blockquote type="cite"><pre wrap="">good enough to be generally deployable by end system operators: no.

we're talking about different things.
</pre></blockquote>
  <pre wrap=""><!---->
Possibly. One point I forgot to mention is that I've yet to run into the fairly unlikely circumstance of having a legitimate resolver actually issuing legitimate queries and being's 'authenticated' against a given [recursive or] authoritative server, and then being promptly pummeled by a reflection/amplification attack leveraging that very same authoritative server to attack that very same resolver.  </pre>
</blockquote>
<br>
your experiences as a remediator are not predictive of what a global 
system that behaved this way would experience.<br>
<br>
<blockquote 
cite="mid:cbb9e574-1cba-4460-bae8-7e17ddc88e0f@email.android.com" 
type="cite">
  <pre wrap="">And although I don't have stats on this, my subjective experience seems to  indicate that DNS resolvers are not generally the ultimate intended targets of DNS reflection / amplification attacks, anyways.  AFAICT, it's mainly Web servers</pre>
</blockquote>
<br>
we must not attempt reason from the specific to the general in the way 
you're implying here, if the details aren't endemic. that is, since the 
bad guys can easily change from ANY to some other qtype, we won't widely
 deploy a defense against ANY; similarly, since the bad guys can easily 
choose a recursive dns server which shares upstream capacity with their 
real target, we won't widely deploy a solution that only works if their 
proximate and direct target is not a recursive dns server.<br>
<br>
i'm not saying your experiences didn't happen or that your product 
doesn't work. i'm saying that your experiences are not indicative of how
 a global system that behaved this way would behave. the topic under 
discussion is not what will work on a case by case basis, but rather 
what can we globally deploy that will make the whole system harder to 
successfully attack. thus RRL deals differently with attack flows than 
opendns or googledns does -- those are already hard targets but like the
 arbor service you've been describing the hardness of those targets 
relies on methods that would not scale to large numbers of 
less-well-funded name service plants, and which would not work if the 
bad guys had no lower-hanging fruit and instead had to focus their 
bypass efforts on your specific methods.<br>
<br>
paul<br>

</body></html>