Actualización 20141001: Indiqué del problema a ETECSA y este fue corregido minutos después.

Adelantándome un poquito en el tiempo quiero indicar que este problema está ocurriendo en Setiembre del 2014, no quiere decir que este será un problema a futuro, quizá lo corrijan. Si usted tiene un problema con nauta.cu, mejor contácteles a ellos.

Rebotes de correos dirigidos a nauta.cu

El día de hoy un amigo me comentó que continuamente los correos que enviaba a su familia en Cuba le rebotaban, que a veces no rebotaban, pero otras veces sí. Leí un mensaje rebotado y decía algo relacionado con los DNS: que no podía resolver el dominio en los DNS.

Inicialmente pensé que podría ser una falla en el servicio por inundación de peticiones (DoS) sin embargo ahora en la noche me pongo a analizar los dns definidos por nauta. Son aparentemente 5:

ns1.etecsa.net, ns2.etecsa.net, ns3.etecsa.net, ns4.etecsa.net y ns5.etecsa.net

El sitio http://www.squish.net/dnscheck/ realiza un chequeo transversal de DNS, verificando la misma pregunta (query) que se le indique en todos los DNS definidos para un dominio (en este caso sería de ns1 a ns5.etecsa.net).

Procedí  a usarle para verificar los records MX definidos para el dominio nauta.cu notando que de 2 de estos 5 DNS fallan directamente indicando que no hay records MX. Es decir, 2/5, un 40% de las peticiones que se realizan a los DNS de nauta.cu para averiguar su record MX falla indicándose que tal record no existe.

Por lo tanto cualquier servidor de correos que tenga la mala suerte de preguntarle a estos DNS que fallan (ns2 y ns4 al momento) recibirá mensajes indicando que no hay MX, que no hay servidor de correos, y los correos posiblemente reboten sin llegar a su destinatario.

Por qué ocurre esto?

Los DNS normalmente trabajan en un modelo que se llama de maestro-esclavo (o primario-secundario) mediante el cual uno de los DNS es el maestro, donde se realizan las adiciones/modificaciones/eliminaciones de records de una zona. Los DNS esclavos son el resto y los esclavos simplemente se ocupan de incorporar las modificaciones que existan en el maestro sean incorporadas a ellos. De esta forma se garantiza que un cambio en el maestro se vea reflejado en todos los esclavos.

Si ETECSA tuviera sus 5 DNS en formato 1 maestro->4 esclavos esto no sucedería pues al modificarse el maestro, los esclavos tuvieran la misma información. De esta forma las respuestas de todos los DNS fueran las mismas (bien o mal, pero las mismas).

Por qué entonces en nauta.cu 3 DNS sí entregan el record MX de la zona y en los otros 2 DNS no? Porque no están completamente configurados en modo maestro-esclavo. Entonces el administrador de los DNS debe realizar los cambios no en un sólo DNS (el maestro) sino en varios o todos; y lógicamente puede olvidarse de modificar uno o varios de los DNS como aparenta ser el caso.

Cómo se soluciona? En principio al menos el administrador de los dns debe agregar el record MX a todos los DNS, en la forma que estén utilizando, sea multiples master o maestro-esclavo o lo que sea. Y luego por facilidad debería cambiar los dns a un formato maestro-esclavo para que no vuelva a suceder esto.

Además los 5 dns de nauta.cu (ns1 a ns5.etecsa.net) tienen punto de falla en común. Qué es esto? Significa que los DNS en cuestión están localizados en la misma red. Esto es fácil de ver en la siguiente imagen:

Como podemos observar de ns1 a ns4 están evidentemente en la misma red y en el AS27725. Y ns5 está aparentemente en una red diferente, pero en el mismo AS (AS27725). Una falla en algún ruteador, sobrecarga, inundación de paquetes, pérdida de paquetes, etc, que ocurra en un equipo clave de la etecsa conllevaría a que todos los DNS dejen de responder y los correos reboten. Si al menos tuvieran un DNS fuera de su red, esto evitaría el punto de falla en común por lo que siempre alguien respondería a las peticiones que se hagan a sus dominios.

Hay más temitas, pero que los arregle el responsable de esa zona.