<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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
cite="mid:CAJga8ZtXRuYr+8DtGwNNNSYMrSktFsGnqjquqLzyWUZ-ZWt7Rg@mail.gmail.com"
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
moz-do-not-send="true" 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>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 moz-do-not-send="true"
href="http://niqcs.www.84822258.com" target="_blank">niqcs.www.84822258.com</a>
<br>
<a moz-do-not-send="true"
href="http://vbhea.www.84822258.com" target="_blank">vbhea.www.84822258.com</a>
<br>
<a moz-do-not-send="true"
href="http://abpqeftuijklm.www.84822258.com"
target="_blank">abpqeftuijklm.www.84822258.com</a> <br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>
<br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a moz-do-not-send="true"
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>
</body>
</html>