Estoy con un gran dilema y es que desde hace mas de una semana comenzó un ataque hacia mi plataforma anycast de resolvedores de nombres. Estoy en un ISP así que esto es grande.
El ataque es mas o menos así (extracto de named-queries.log



Como pueden preciar hay un sin fin de consultas hacia diversos subdominios del dominio gegequ.com, Así pueden hacerse consultas hacia muchos distintos dominios con el mismo síntoma. Esto me ha llevado a problemas de Denegación de Servicios. De momento he instalado dnstop que me ayuda a identificar el o los dominios usados para atacar. Dentro de named.conf tengo una lista de dominios bloqueados y lo que hago es hacer que responda localmente a estos bloqueos con IP e loopback, esto configurado en un archivo de zona predeterminado.
Si bien esto evitar caer en DOS, es solo una solución parche, estoy en busca de una solución definitiva donde pensar en evitar la recursividad no es una opción dado que como ISP tenemos millones de clientes que atender y así no funciona esto. La recursividad esta acotada a los rangos de IP confiables que entregan nuestros servidores dhcp o los rangos de IP estáticas que se venden.
Cuando detectamos alguna IP estática atacando también la bloqueamos excepto en el caso de las adsl, pues son dinámicas y no tiene ningún sentido.
Algún sabio binario que me oriente o me entregue un pase de sabiduría para acabar con esta pesadilla que de momento me tiene durmiendo en tramos no superiores a 1 hora.

Como ven estoy bailando con la fea y casi sin dormir.
He pensado en alguna herramienta del tipo despoof, pero la verdad es que siento que esa decisión es un simple palo de ciego.

Un abrazo y si alguien puede ayudarme con esto, se ganara gobernar la matrix por la eternidad.

Un abrazo desde Chile y me alegra que este sitio le sea de tanta utilidad a muchos.

Éxitos Joel y equipo AL.

Buenas Tardes.... te recomiendo usar fail2Ban


https://www.debian-administration.org/article/Blocking_a_DNS_DDOS_using_the_fail2ban_package

Hola compatriota!!!. Eso tiene mucha cara de ser un zoombie ejecutando algo para sobre-saturar(si existe esa palabra) tu server. Creo que Fail2ban no es una mala alternativa pero el dilema será cuantas consultas vas a permitir a cada cliente, si los logs son extensos la carga sobre fail2ban se volverá eterna. Quizás sería prudente ocupar el archivo /etc/hosts.deny pero tendrías que estar revisando cada ciertos minutos los logs y agregando las ips. Aun que también podrías crear algún script en bash o python que lea y obtenga una cantidad de "x" coincidencias de ips y consultas y escribirlas en ese archivo (/etc/hosts.deny), aun que sigo creyendo que sería muy complejo pero efectivo.

Por otra parte, no sé como este conformada tu red, pero si yo fuera tu no dejaría mi servidor DNS directamente conectado a internet y menos y lo usas como cache de ISP. Deberías pensar en la posibilidad de instalar algún firewall con monitoreo de red y hasta un balanceo de carga para dividir las consultas DNS entre 1 o mas servers. Si usas una distro como centos para firewall instala SNOR para revisar y monitorear que diablos pasa realmente realizar bloqueos necesarios dentro del firewall y no de la maquina DNS.

Lamentablemente als alternativas aportadas no son utiles para mi caso, pero se agradecen sus respuestas. en un ISP no podemos manejar canones como lo podemos hacer desde una segmento publico asignado a una empresa. Mis resolvedorrs necesitan recursividad y no hay otra via.
Les cuento que hemos decantando el asunto por el lado de los lospuertos abiertos a nuestros clientes dhcp y ftth. Por ahi hemos encontrado unas vulnerabilidades. En cuanto saquemos este tema al aire les comentare la solucion porque parace que el problema lo esta generando la generosidad de apertura de puerto de los router que se dejan en las casas, los que escuchan por el `puerto 53 y por ende donde cualquier botnet puede hacer uso de el instalandose y haciendo las consultas hechas a ellos recursivas a nuestra plataforma. Empiricamente probado, pero vamos a probar si la inyeccion creada es la solucion

Aqui les dejo un link donde se explia muy bien lo que nos afecta:

http://dnsamplificationattacks.blogspot.com/2014/02/authoritative-name-server-attack.html