Seba, Aqui te posteo la direccion de un draft que explica sobre el tema (esta en ingles):
http://tools.ietf.org/group/irtf/draft-irtf-asrg-dnsbl-02.txt Espero sea de utilidad 2007/1/17, Sebastián D. Criado <[email protected]>:
En uno de los servidores que administro, me encontré con con múltiples consultas al DNS (BIND) desde 127.0.0.2:53 y las mismas eran rechazadas por el bind dado que está configurado mediante ACL's para aceptar solo peticiones de la red interna y de 127.0.0.1 (localhost). Luego de un análisis exhaustivo, pude determinar el problema y solucionarlo, aunque me quedaron algunas dudas respecto a por que se efectúan las consultas desde esa IP. El problema comenzó a reportarse cuando el BIND infrmaba el rechazo de la consulta a través del syslog, reportando en forma reiterativa el siguiente mensaje: named[17111]: refused query on non-query socket from [127.0.0.2].53 Esto me indicaba, como dice el mensaje, que se estaba haciendo un query al DNS desde la dirección 127.0.0.2:53 Sabiendo que estaba bien que sea rechazado el pedido, me dispuse a ver que era lo que estaba originando el mismo. Lo que me encontré me llevo al problema directamente. La IP 127.0.0.2 es utilizada por los sistemas de RBL para informar que la ip que se le ha consultado (ej: 200.69.206.108) está dentro de su base de datos como una ip bloqueada. La forma de comprobarlo es hacer una consulta por medio de dig sobre una ip en la forma inversa. Para eso tome un servidor de RBL que se que funciona como el empresa Impsat de Chile. http://abuse.impsat.cl/ Al hacerle una consulta a sus DNS sobre la IP 200.69.206.108 obtendremos el siguiente resultado: $ dig a @dns.impsat.cl 108.206.69.200.abuse.impsat.cl ;; ANSWER SECTION: 108.206.69.200.abuse.impsat.cl. 3600 IN A 127.0.0.2 Como se puede ver, nos responde la ip del problema. ¿Pero que tiene que ver esto con el problema de los mensajes del bind? Para poder chequear desde el Sendmail si una ip esta dentro de una RBL lo que se puede utilizar en DNSBL http://en.wikipedia.org/wiki/DNSBL. Este sistema va hacer una serie de pasos para comprobar si el mail que está entrando se encuentra en la RBL que se le ha consultado consultar. En este caso, estaba usando la RBL relay.ordb.org configurada en el Sendmail. Dado que relay.ordb.org cerro a fin de este año, no se podía hacer la consulta, las consultas que DNSBL le enviaba no se podían responder. Una vez removida la linea del sendmail.mc y generado el cf correspondiente, el mensaje dejo de aparecer. Problema resuelto. Pero aun me quedaba una duda, dado que el que efectuaba el pedido a 127.0.0.2 era el mismo bind. Así, sabiendo que relays.ordb.org no funcionaba, me dispuse a hacer la consulta por medio del dig usando ese servidor, y por medio de tcpdump mire que pasada en la interfase "lo". $ dig @relays.ordb.org 108.206.69.200.relays.ordb.org El resultado de tcpdump de los pedidos fue el siguiente: 15:36:34.475690 127.0.0.1.45816 > 127.0.0.1.53: 2733+ A? relays.ordb.org. (33) (DF) En está linea se puede ver la consulta al DNS sobre el dominio consultado para así poder determinar su IP. 15:36:40.003493 127.0.0.2.53 > 127.0.0.2.53: 65036 A? relays.ordb.org. (33) (DF) 15:36:42.003496 127.0.0.2.53 > 127.0.0.2.53: 56582 [1au] A? relays.ordb.org. OPT UDPsize=4096 (44) (DF) Inmediatamente después se ve una consulta desde 127.0.0.2 a si mismo. 15:36:42.003592 127.0.0.1.53 > 127.0.0.1.45812: 32447 ServFail 0/0/0 (33) (DF) La respuesta que le llega es un ServFail al no poder determinar la ip del mismo. 15:36:42.003624 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port 45812 unreachable [tos 0xc0] 15:36:48.503386 127.0.0.1.45816 > 127.0.0.1.53: 2733+ A? relays.ordb.org. (33) (DF) 15:36:56.003425 127.0.0.1.53 > 127.0.0.1.45814: 60805 ServFail 0/0/0 (33) (DF) 15:36:56.003480 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port 45814 unreachable [tos 0xc0] 15:37:02.003500 127.0.0.2.53 > 127.0.0.2.53: 56582 A? relays.ordb.org. (33) (DF) 15:37:02.534023 127.0.0.1.45818 > 127.0.0.1.53: 2734+ A? relays.ordb.org. (33) (DF) 15:37:10.003491 127.0.0.2.53 > 127.0.0.2.53: 56582 A? relays.ordb.org. (33) (DF) 15:37:10.003589 127.0.0.2.53 > 127.0.0.2.53: 34326 [1au] A? relays.ordb.org. OPT UDPsize=4096 (44) (DF) 15:37:16.563394 127.0.0.1.45818 > 127.0.0.1.53: 2734+ A? relays.ordb.org. (33) (DF) 15:37:26.003490 127.0.0.1.53 > 127.0.0.1.45816: 2733 ServFail 0/0/0 (33) (DF) 15:37:26.003537 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port 45816 unreachable [tos 0xc0] 15:37:30.003488 127.0.0.2.53 > 127.0.0.2.53: 34326 A? relays.ordb.org. (33) (DF) 15:37:38.003423 127.0.0.2.53 > 127.0.0.2.53: 34326 A? relays.ordb.org. (33) (DF) Las demás lineas, muestran idéntico resultado en los reintentos. Intente reproducir el problema con otros dominios los cuales no existen y no pude obtener estos resultados. La hipótesis sobre esto es: Dado que para poder ser un RBL se tendrá que hacer una implementación que antes una consulta de DNS responda con 127.0.0.2 para informar que la ip figura en la base de datos, pero dado que el servicio de rbl de relays.ordb.org no está funcionando, el DNS de este servidor está respondiendo a todas las consultas con un 127.0.0.2 y el dns de mi servidor trata de atenderlo como un pedido de loopback. Esta hipótesis tiene el problema que no puedo comprobarlo ya que no tengo acceso a la configuración actual de relays.ordb.org, pero si enteiendo que usan un sistema tipo rbldn http://www.ladro.com/docs/dns/rblsmtpd.htmlpara brindar el servicio. ¿Alguna idea sobre esto? ¿A alguno le a pasado? ¿Por que hace mi DNS consultas desde 127.0.0.2 cuando no tendría que hacerlas? -- Sebastián D. Criado - scriado{en}ciudad.com.ar L.U.G.R.o - http://www.lugro.org.ar GNU/Linux Registered User # 146768 ------------------------------------------------------------------- "Si el Universo fuera un programa estaría hecho en C, y correría sobre un sistema UNIX" Anónimo.
