<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 1, 2014 at 1:21 PM, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><blockquote style="border:0px none" type="cite">
  <span class="">
</span></blockquote>
 what we've learned from random-subdomain flood attacks is that the 
nxdomain limit (in BIND9 that's nxdomains-per-second) and the slip ratio
 both have to be higher than we thought. at the moment i'm going to say 
nxdomains-per-second of at least 20, and a slip ratio of 5.<span class=""><br>
<blockquote style="border:0px none" type="cite">
  <div style="color:#888888;margin-left:24px;margin-right:24px">
    <pre></pre>
</div></blockquote></span></div></blockquote></div>This sort of control is of course what distinguishes a prototype implementation of a service from deployment grade.</div><div class="gmail_extra"><br></div><div class="gmail_extra">One of the concerns I have about approaches to DPRIVE is that they tend to start from the DNS specification and add security to that model rather than look at real world implementations. </div><div class="gmail_extra"><br></div><div class="gmail_extra">It is really easy to assume away the hard problems. I want to get authentication into the client-resolver loop so that we have a cryptographic enforcement mechanism for abuse control rather than relying on heuristics.</div></div>