<p dir="ltr">Ah I see you are in provider situation.  Shows my assumption you were in an enclosed enterprise environment. </p>
<div class="gmail_quote">On Feb 27, 2014 10:57 AM, "Ivo" <<a href="mailto:ivo@nic.lv">ivo@nic.lv</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Ben,<br>
      <br>
      No, our server is not an open resolver,  we have a large user
      community and the problem is that users install their own wifi box
      like Zyxel or similar which may have open resolver by default.<br>
      <br>
      Ivo<br>
      <br>
      On 2/27/14 5:18 PM, Ben Croswell wrote:<br>
    </div>
    <blockquote type="cite">
      <p dir="ltr">I guess I am missing why anyone on the internet
        should be able to open queries against your caching resolver.  </p>
      <p dir="ltr">Why would in bound queries be allowed to servers that
        are for your people to get out? </p>
      <div class="gmail_quote">On Feb 27, 2014 10:13 AM, "Ivo" <<a href="mailto:ivo@nic.lv" target="_blank">ivo@nic.lv</a>>

        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000">
            <div>Hi Dmitry,<br>
              <br>
              We observed that similar requests are landing on our cache
              resolver mostly from various home routers running dns
              server as open resolver and that also masquerades the
              original request source. <br>
              We have a collection of ~60 domains involved and most of
              them are related to China. The problem is that attacker
              selects few domains and generates queries with random
              hostnames which therefore are not in the cache and server
              has to perform recursion for each query. So each query
              will consume one udp or tcp socket for at least 10 seconds
              because remote DNS server is responding slowly or is down
              and based on a query volume it can effectively overload
              the cache server. <br>
              <br>
              Initially we thought we could fix it with "
              resolver-query-timeout", but after bind code analysis it
              seems that everything less that 10 seconds would be
              ignored, it would be great to mention this in the
              documentation. <br>
              So one solution is to change MINIMUM_QUERY_TIMEOUT in
              resolver.c and recompile named, but  it would be nice to
              understand why 10 seconds as minimum value were selected
              in the first place, see /lib/dns/resolver.c<br>
              <br>
              #define MAX_SINGLE_QUERY_TIMEOUT 9U<br>
              #define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT +
              1U)  <br>
              <br>
              ....snip....<br>
              <br>
              void<br>
              dns_resolver_settimeout(dns_resolver_t *resolver, unsigned
              int seconds) {<br>
                      REQUIRE(VALID_RESOLVER(resolver));<br>
                      if (seconds == 0)<br>
                              seconds = DEFAULT_QUERY_TIMEOUT;<br>
                      if (seconds > MAXIMUM_QUERY_TIMEOUT)<br>
                              seconds = MAXIMUM_QUERY_TIMEOUT;<br>
                      if (seconds < MINIMUM_QUERY_TIMEOUT)<br>
                              seconds =  MINIMUM_QUERY_TIMEOUT;<br>
                      resolver->query_timeout = seconds;<br>
              }<br>
              <br>
              We also tried to create local dummy zones for all these
              domains but since domains change frequently we started to
              block most active open resolvers and coordinate with local
              CERT.<br>
              <br>
              It would be nice to have some kind of rate limits for
              query volume of different hosts inside a single zone.<br>
              <br>
              Best regards,<br>
              <br>
              Ivo<br>
              <br>
              <br>
              On 2/27/14 7:59 AM, Dmitry Rybin wrote:<br>
            </div>
            <blockquote type="cite">Over 2 weeks ago begins flood. A lot
              of queries: <br>
              <br>
              <a href="http://niqcs.www.84822258.com" target="_blank">niqcs.www.84822258.com</a>
              <br>
              <a href="http://vbhea.www.84822258.com" target="_blank">vbhea.www.84822258.com</a>
              <br>
              <a href="http://abpqeftuijklm.www.84822258.com" target="_blank">abpqeftuijklm.www.84822258.com</a> <br>
              <a href="http://adcbefmzidmx.www.84822258.com" target="_blank">adcbefmzidmx.www.84822258.com</a> <br>
              and many others. <br>
              <br>
              Bind answers with "Server failure". On high load (4 qps)
              all normal client can get Servfail on good query. Or query
              can execute more 2-3 second. <br>
              <br>
              Recursion clients via "rnds status" 300-500. <br>
              <br>
              I can try to use rate limit: <br>
                      rate-limit { <br>
                              nxdomains-per-second 10; <br>
                              errors-per-second 10; <br>
                              nodata-per-second 10; <br>
                      }; <br>
              I do not see an any improvement. <br>
              <br>
              Found one exit in this situation, add flood zones local. <br>
              <br>
              What can we do in this situation? <br>
              _______________________________________________ <br>
              Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>
              to unsubscribe from this list <br>
              <br>
              bind-users mailing list <br>
              <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>
              <br>
              <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>
              <br>
            </blockquote>
            <br>
            <br>
          </div>
          <br>
          _______________________________________________<br>
          Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>
          to unsubscribe from this list<br>
          <br>
          bind-users mailing list<br>
          <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
          <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br></blockquote></div>