Tengo un sitio web que hospedo yo mismo y uso bind9 como mi servidor DNS (alojo mis propios servidores de nombres, etc.).
Tengo un problema con el ancho de banda del tráfico y mi syslog está lleno del siguiente tipo de problema:
error (unexpected RCODE REFUSED) resolving 'target-express.com/AAAA/IN': 193.95.142.60#53
error (unexpected RCODE REFUSED) resolving 'target-express.com/A/IN': 2001:7c8:3:2::5#53
En el syslog de hoy, hay144258casos de esto, todos relacionados con target-express.com.
Mis preguntas son:
- ¿Hay algo que pueda hacer con respecto al firewall o vincular la configuración para detener esto?
- ¿Por qué mi configuración de enlace intentaría resolver target-express.com (no es mi dominio, no tiene nada que ver conmigo)?
Revisé mis reenviadores en name.conf y ninguno de ellos coincide con las IP que se muestran en los registros (todas son IP básicamente diferentes, no solo 193.95.142.60).
Mi iptables dice:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere loopback/8 reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT icmp -- anywhere anywhere icmp echo-request
LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACTUALIZAR:
Intenté lo siguiente ahora en named.conf.options para bloquear la recursividad.
allow-transfer {"none";};
allow-recursion {"none";};
recursion no;
Una vez que hice esto, ahora veo lo siguiente en syslog:
Mar 4 00:02:21 mail named[29037]: client 127.0.0.1#42139: query (cache) '24.124.41.103.in-addr.arpa/PTR/IN' denied
Mar 4 00:02:22 mail named[29037]: client 127.0.0.1#58405: query (cache) '45.124.41.103.in-addr.arpa/PTR/IN' denied
Mar 4 00:02:24 mail named[29037]: client 127.0.0.1#48692: query (cache) '106.49.174.61.in-addr.arpa/PTR/IN' denied
Para deshacerme de lo anterior, agregué:
additional-from-cache no;
Respuesta1
¿Podrían sus reenviadores de DNS estar reenviando solicitudes al servidor original?
Si es así, esto podría ser algo parecido al problema que tuve el año pasado (verLos servidores DNS de Windows solicitan repetidamente registros en la zona cuando reciben una respuesta SERVFAIL). La solución es no tener bucles de reenvío. Esto sólo aparece como un problema importante con las zonas que devuelven SERVFAIL porque esas respuestas no se almacenarán en caché.
En cuanto a qué inició la consulta original (y puede que solo haya sido una), podría ser casi cualquier cosa: búsqueda de DNS para control de acceso web o algo así.
Para evitar la amplificación (quizás una mejor descripción que los bucles), debe asegurarse de que el servidor DNS donde ve estos mensajes no esté reenviando consultas a un servidor que podría reenviar solicitudes. ¿Los servidores que ha configurado en su servidor DNS local están bajo su control o son externos?
Respuesta2
Seguramente su servidor está intentando resolver 'target-express.com' y está fallando. La razón por la que falla es que los servidores NS para 'target-express.com' no están configurados correctamente. (Google 'servidores aburridos'). Al hacer 'excavación + seguimiento' se muestran dos registros NS para el dominio, pero si consulta esos dominios, no hay respuesta.
Ahora la pregunta es quién consulta su servidor.
1.Usuarios/aplicaciones internos legítimos: no me preocuparía por esto.
2. Usuarios externos no autorizados: sus servidores DNS deben permitir la resolución solo de dominios para los que tienen autoridad. Si su intención no es tener un servidor DNS abierto, establezca una restricción en su configuración de DNS para que solo los hosts permitidos puedan usar el servidor para consultas recursivas.
root@svm1010:/var/tmp# dig @8.8.8.8 target-express.com NS +corto root@svm1010:/var/tmp# dig +trace target-express.com NS ; > DiG 9.7.0-P1 > +trace target-express.com NS ;; opciones globales: +cmd . 16978 EN NS d.root-servers.net. . 16978 EN NS i.root-servers.net. . 16978 EN NS f.root-servers.net. . 16978 EN NS b.root-servers.net. . 16978 EN NS a.root-servers.net. . 16978 EN NS k.root-servers.net. . 16978 EN NS l.root-servers.net. . 16978 EN NS h.root-servers.net. . 16978 EN NS e.root-servers.net. . 16978 EN NS j.root-servers.net. . 16978 EN NS m.root-servers.net. . 16978 EN NS g.root-servers.net. . 16978 EN NS c.root-servers.net. ;; Recibí 228 bytes de 8.8.8.8#53(8.8.8.8) en 9 ms com. 172800 EN NS j.gtld-servers.net. com. 172800 EN NS a.gtld-servers.net. com. 172800 EN NS m.gtld-servers.net. com. 172800 EN NS b.gtld-servers.net. com. 172800 EN NS c.gtld-servers.net. com. 172800 EN NS i.gtld-servers.net. com. 172800 EN NS l.gtld-servers.net. com. 172800 EN NS h.gtld-servers.net. com. 172800 EN NS f.gtld-servers.net. com. 172800 EN NS k.gtld-servers.net. com. 172800 EN NS d.gtld-servers.net. com. 172800 EN NS e.gtld-servers.net. com. 172800 EN NS g.gtld-servers.net. ;; Recibí 496 bytes de 199.7.91.13#53(d.root-servers.net) en 15 ms target-express.com. 172800 EN NS sec02.ns.esat.net. target-express.com. 172800 EN NS auth02.ns.esat.net. ;; Recibí 120 bytes de 192.48.79.30#53(j.gtld-servers.net) en 221 ms ;; Se recibieron 36 bytes de 192.111.39.112#53(sec02.ns.esat.net) en 111 ms. root@svm1010:/var/tmp# dig @sec02.ns.esat.net. target-express.com. soa +corto root@svm1010:/var/tmp# dig @auth02.ns.esat.net. target-express.com. soa +corto raíz@svm1010:/var/tmp#