Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-09 Thread Kostas Zorbadelos
LuKreme krem...@kreme.com writes: On 08 Mar 2014, at 12:52 , Kostas Zorbadelos kzo...@otenet.gr wrote: One mitigation approach is to blackhole the domains using local zones. That’s not much of a mitigation. Not having open resolvers would be mitigation. It is a quick and dirty approach,

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-09 Thread Doug Barton
On 3/8/2014 1:30 PM, sth...@nethelp.no wrote: One mitigation approach is to blackhole the domains using local zones. That�s not much of a mitigation. Not having open resolvers would be mitigation. Not having open resolvers is good - but unfortunately doesn't help against misbehaving clients

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-08 Thread Kostas Zorbadelos
Hello, an update with the findings so far: - IPv6 config on the servers was an issue so we removed it and will test further later. There is a hint pointed from various people about a Linux kernel issue and setting (net.ipv6.route.max_size), see

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-08 Thread LuKreme
On 08 Mar 2014, at 12:52 , Kostas Zorbadelos kzo...@otenet.gr wrote: One mitigation approach is to blackhole the domains using local zones. That’s not much of a mitigation. Not having open resolvers would be mitigation. -- Eyes the shady night has shut/Cannot see the record cut And silence

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-08 Thread sthaug
One mitigation approach is to blackhole the domains using local zones. That?s not much of a mitigation. Not having open resolvers would be mitigation. Not having open resolvers is good - but unfortunately doesn't help against misbehaving clients (e.g. small home routers with DNS proxies

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-07 Thread Klaus Darilion
Answering myself: This bug is probably not your problem, as Bind has received the DNS query, otherwise it would not answer with SERVFAIL. regards Klaus On 05.03.2014 16:15, Klaus Darilion wrote: Does it only happen for IPv6 DNS requests? Maybe it is related to this:

RE: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-06 Thread Daniel Dawalibi
Hello We are facing a similar problem by getting an intermittent SERVER FAILS on several domains and specifically during the high traffic. Please note that the IPV6 dual stack is not configured in the Operating system and we are not using any IPV6 option in the BIND configuration file. 1- We

Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-05 Thread Kostas Zorbadelos
Greetings to all, we operate an anycast caching resolving farm for our customer base, based on CentOS (6.4 or 6.5), BIND (9.9.2, 9.9.5 or the stock CentOS package BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1) and quagga (the stock CentOS package). The problem is that we have noticed sporadic but

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-05 Thread Klaus Darilion
Does it only happen for IPv6 DNS requests? Maybe it is related to this: https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001783.html klaus On 05.03.2014 14:16, Kostas Zorbadelos wrote: Greetings to all, we operate an anycast caching resolving farm for our customer base, based on

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

2014-03-05 Thread Marco Davids (SIDN)
On 05/03/14 15:15, Klaus Darilion wrote: Does it only happen for IPv6 DNS requests? Maybe it is related to this: https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001783.html Or, less likely, this: http://marc.info/?l=linux-netdevm=139352943109400w=2 -- Marco