Re: Monitoring Zonefiletransfer
Hi Markus, Markus Weber bumpemacve...@googlemail.com writes: Choose sane SOA values. refresh and retry expire I will check these values, i thought they were kind of standard values the default SOA values on a MS DNS Server are well and good for dynamic, internal, AD integrated DNS zones. For use in the Internet, you might want to adjust the values, esp. the expire value should be not too low. This document gives some guidance on SOA values for DNS zones that are used in the Internet http://meetings.ripe.net/ripe-55/presentations/koch-ripe203bis.pdf -- Carsten ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind vs flood
Hi Dmitry,
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.
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.
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.
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
#define MAX_SINGLE_QUERY_TIMEOUT 9U
#define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U)
snip
void
dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int seconds) {
REQUIRE(VALID_RESOLVER(resolver));
if (seconds == 0)
seconds = DEFAULT_QUERY_TIMEOUT;
if (seconds MAXIMUM_QUERY_TIMEOUT)
seconds = MAXIMUM_QUERY_TIMEOUT;
if (seconds MINIMUM_QUERY_TIMEOUT)
seconds = MINIMUM_QUERY_TIMEOUT;
resolver-query_timeout = seconds;
}
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.
It would be nice to have some kind of rate limits for query volume of
different hosts inside a single zone.
Best regards,
Ivo
On 2/27/14 7:59 AM, Dmitry Rybin wrote:
Over 2 weeks ago begins flood. A lot of queries:
niqcs.www.84822258.com
vbhea.www.84822258.com
abpqeftuijklm.www.84822258.com
adcbefmzidmx.www.84822258.com
and many others.
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.
Recursion clients via rnds status 300-500.
I can try to use rate limit:
rate-limit {
nxdomains-per-second 10;
errors-per-second 10;
nodata-per-second 10;
};
I do not see an any improvement.
Found one exit in this situation, add flood zones local.
What can we do in this situation?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind vs flood
I guess I am missing why anyone on the internet should be able to open
queries against your caching resolver.
Why would in bound queries be allowed to servers that are for your people
to get out?
On Feb 27, 2014 10:13 AM, Ivo i...@nic.lv wrote:
Hi Dmitry,
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.
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.
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.
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
#define MAX_SINGLE_QUERY_TIMEOUT 9U
#define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U)
snip
void
dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int seconds) {
REQUIRE(VALID_RESOLVER(resolver));
if (seconds == 0)
seconds = DEFAULT_QUERY_TIMEOUT;
if (seconds MAXIMUM_QUERY_TIMEOUT)
seconds = MAXIMUM_QUERY_TIMEOUT;
if (seconds MINIMUM_QUERY_TIMEOUT)
seconds = MINIMUM_QUERY_TIMEOUT;
resolver-query_timeout = seconds;
}
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.
It would be nice to have some kind of rate limits for query volume of
different hosts inside a single zone.
Best regards,
Ivo
On 2/27/14 7:59 AM, Dmitry Rybin wrote:
Over 2 weeks ago begins flood. A lot of queries:
niqcs.www.84822258.com
vbhea.www.84822258.com
abpqeftuijklm.www.84822258.com
adcbefmzidmx.www.84822258.com
and many others.
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.
Recursion clients via rnds status 300-500.
I can try to use rate limit:
rate-limit {
nxdomains-per-second 10;
errors-per-second 10;
nodata-per-second 10;
};
I do not see an any improvement.
Found one exit in this situation, add flood zones local.
What can we do in this situation?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind vs flood
Doesn't this look like a DDOS attack on the spoofed origin of the queries?
On 27/02/14 16:18, Ben Croswell wrote:
I guess I am missing why anyone on the internet should be able to open
queries against your caching resolver.
Why would in bound queries be allowed to servers that are for your
people to get out?
On Feb 27, 2014 10:13 AM, Ivo i...@nic.lv mailto:i...@nic.lv wrote:
Hi Dmitry,
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.
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.
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.
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
#define MAX_SINGLE_QUERY_TIMEOUT 9U
#define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U)
snip
void
dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int
seconds) {
REQUIRE(VALID_RESOLVER(resolver));
if (seconds == 0)
seconds = DEFAULT_QUERY_TIMEOUT;
if (seconds MAXIMUM_QUERY_TIMEOUT)
seconds = MAXIMUM_QUERY_TIMEOUT;
if (seconds MINIMUM_QUERY_TIMEOUT)
seconds = MINIMUM_QUERY_TIMEOUT;
resolver-query_timeout = seconds;
}
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.
It would be nice to have some kind of rate limits for query volume
of different hosts inside a single zone.
Best regards,
Ivo
On 2/27/14 7:59 AM, Dmitry Rybin wrote:
Over 2 weeks ago begins flood. A lot of queries:
niqcs.www.84822258.com http://niqcs.www.84822258.com
vbhea.www.84822258.com http://vbhea.www.84822258.com
abpqeftuijklm.www.84822258.com
http://abpqeftuijklm.www.84822258.com
adcbefmzidmx.www.84822258.com http://adcbefmzidmx.www.84822258.com
and many others.
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.
Recursion clients via rnds status 300-500.
I can try to use rate limit:
rate-limit {
nxdomains-per-second 10;
errors-per-second 10;
nodata-per-second 10;
};
I do not see an any improvement.
Found one exit in this situation, add flood zones local.
What can we do in this situation?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org mailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org mailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Best regards
Sten Carlsen
No improvements come from shouting:
MALE BOVINE MANURE!!!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind vs flood
Ben,
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.
Ivo
On 2/27/14 5:18 PM, Ben Croswell wrote:
I guess I am missing why anyone on the internet should be able to open
queries against your caching resolver.
Why would in bound queries be allowed to servers that are for your
people to get out?
On Feb 27, 2014 10:13 AM, Ivo i...@nic.lv mailto:i...@nic.lv wrote:
Hi Dmitry,
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.
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.
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.
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
#define MAX_SINGLE_QUERY_TIMEOUT 9U
#define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U)
snip
void
dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int
seconds) {
REQUIRE(VALID_RESOLVER(resolver));
if (seconds == 0)
seconds = DEFAULT_QUERY_TIMEOUT;
if (seconds MAXIMUM_QUERY_TIMEOUT)
seconds = MAXIMUM_QUERY_TIMEOUT;
if (seconds MINIMUM_QUERY_TIMEOUT)
seconds = MINIMUM_QUERY_TIMEOUT;
resolver-query_timeout = seconds;
}
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.
It would be nice to have some kind of rate limits for query volume
of different hosts inside a single zone.
Best regards,
Ivo
On 2/27/14 7:59 AM, Dmitry Rybin wrote:
Over 2 weeks ago begins flood. A lot of queries:
niqcs.www.84822258.com http://niqcs.www.84822258.com
vbhea.www.84822258.com http://vbhea.www.84822258.com
abpqeftuijklm.www.84822258.com
http://abpqeftuijklm.www.84822258.com
adcbefmzidmx.www.84822258.com http://adcbefmzidmx.www.84822258.com
and many others.
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.
Recursion clients via rnds status 300-500.
I can try to use rate limit:
rate-limit {
nxdomains-per-second 10;
errors-per-second 10;
nodata-per-second 10;
};
I do not see an any improvement.
Found one exit in this situation, add flood zones local.
What can we do in this situation?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org mailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org mailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind vs flood
Ah I see you are in provider situation. Shows my assumption you were in an
enclosed enterprise environment.
On Feb 27, 2014 10:57 AM, Ivo i...@nic.lv wrote:
Ben,
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.
Ivo
On 2/27/14 5:18 PM, Ben Croswell wrote:
I guess I am missing why anyone on the internet should be able to open
queries against your caching resolver.
Why would in bound queries be allowed to servers that are for your people
to get out?
On Feb 27, 2014 10:13 AM, Ivo i...@nic.lv wrote:
Hi Dmitry,
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.
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.
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.
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
#define MAX_SINGLE_QUERY_TIMEOUT 9U
#define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U)
snip
void
dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int seconds) {
REQUIRE(VALID_RESOLVER(resolver));
if (seconds == 0)
seconds = DEFAULT_QUERY_TIMEOUT;
if (seconds MAXIMUM_QUERY_TIMEOUT)
seconds = MAXIMUM_QUERY_TIMEOUT;
if (seconds MINIMUM_QUERY_TIMEOUT)
seconds = MINIMUM_QUERY_TIMEOUT;
resolver-query_timeout = seconds;
}
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.
It would be nice to have some kind of rate limits for query volume of
different hosts inside a single zone.
Best regards,
Ivo
On 2/27/14 7:59 AM, Dmitry Rybin wrote:
Over 2 weeks ago begins flood. A lot of queries:
niqcs.www.84822258.com
vbhea.www.84822258.com
abpqeftuijklm.www.84822258.com
adcbefmzidmx.www.84822258.com
and many others.
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.
Recursion clients via rnds status 300-500.
I can try to use rate limit:
rate-limit {
nxdomains-per-second 10;
errors-per-second 10;
nodata-per-second 10;
};
I do not see an any improvement.
Found one exit in this situation, add flood zones local.
What can we do in this situation?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
