Entre flores, fandanguillos y alegría, desapareció la España de mi amor

Lo habréis leído ya seguro en el periódico y yo ya he tenido que aguantar bastante pitorreo en la oficina:

El nombre de dominio .ES desaparece ayer de Internet durante dos horas

Aunque conozco un par de personas en el ESNIC, no he hablado todavía con ninguno de ellos. A través de lo que pone en su página web

Entre las 15.15 y las 17.12 horas de ayer martes, el archivo de las direcciones IP del ESNIC se vio afectado por un error en el proceso de actualización del software con el que se gestiona.

interpreto que pasó lo siguiente:

ES tiene 8 servidores de nombres de dominio

;; AUTHORITY SECTION:
ES. 1H IN NS ns1.cesca.ES.
ES. 1H IN NS ns2.nic.ES.
ES. 1H IN NS ns3.nic.fr.
ES. 1H IN NS sun.rediris.ES.
ES. 1H IN NS aunic.aunic.net.
ES. 1H IN NS sunic.sunet.se.
ES. 1H IN NS ns.uu.net.
ES. 1H IN NS ns1.nic.ES.

ns1.nic.ES. es el servidor primario y el resto son los secundarios, a juzgar por la información del SOA, y todos corren con el mismo software BIND con versiones que varían entre la 8.3 y la 9.4 (información obtenida a través de fpdns*).

La zona (por así decirlo, el fichero que contiene la traducción de todos los nombres de dominio ES a sus direcciones IP) se actualiza cada ocho horas (a juzgar por el número de serie del SOA y por las declaraciones que leo en El País). Esto hay que hacerlo para añadir nuevos dominios, borrar los viejos y cambiar direcciones. Para ello se suele generar una nueva zona, que se carga en el servidor primario y que todos los servidores secundarios automáticamente descargarán de él.

Supongo que la nueva zona que se generó a las 15:15 estaba corrupta o incompleta (a lo mejor porque el proceso de generación de zona abortó de manera espontánea o porque se llenó el disco duro o vete tú a saber). Si el servidor primario tratara de recargar en funcionamiento la zona nueva, abortaría el proceso con un error pero seguiría funcionando con la zona vieja, lo cual parece ser que no ocurrió. Así que seguramente paran automáticamente el servidor y lo reinician para que cargue la zona nueva (esto consume menos recursos de memoria que una recarga en funcionamiento).

Desgraciadamente la zona no pudo ser cargada y probablemente este proceso esté automatizado, así que nadie se dio cuenta de que el primario ya no funcionaba. Seguro que se generaron mensajes de error, pero o bien no se enviaron a los responsables del mantenimiento o no se leyeron inmediatamente.

Esto explica la caída del primario, ¿pero y los secundarios? Si el primario no funciona, los secundarios no se pueden descargar la zona de él y teóricamente siguen en marcha, pero éste no fue el caso. Eso significa que algún mecanismo externo (es decir, ni AXFR ni IXFR, sino algún script que hace copias periódicas a través de internet), empujó la zona corrupta a todos los secundarios, que seguro que de manera automática se reiniciaron para intentar cargar la zona y también fallaron.

En estos momentos no había ningún servidor autoritativo de ES funcionando, excepto cachés distribuidas por la red que mantienen durante algún tiempo (TTL) las direcciones más utilizadas. ¿Por qué se tardó dos horas en restaurar el servicio? Si se reacciona a tiempo, se puede volver a usar la zona antigua, cargarla en el primario y redistribuirla a los secundarios, lo que como máximo puede llevar 5 ó 10 minutos a mano. Quizá no había ninguna copia de la zona vieja, o se borró cuando la copia nueva la sobreescribió, lo que significa que hay que subsanar el problema original y después generar una zona nueva desde cero. Probablemente esto es lo que les mantuvo ocupados durante las dos horas.

* Por cierto que con fpdns me he dado cuenta de que el servidor NS1.CESCA.ES. está funcionando en modo recursivo, lo cual es peligroso. Ya escribiré sobre ello en otro momento.

[ACTUALIZACIÓN] Después de ver este log, parece que los servidores sí que funcionaban, pero la zona que se generó estaba parcial o totalmente vacía (en contra de lo que se lee en las declaraciones de El País). Así que la hipótesis más probable es entonces la siguiente: Por un error de tu propio software (no de BIND) se genera una zona vacía, se carga en el primario y todos los secundarios se la descargan automáticamente. No hay mensaje de error, nada. Al principio nadie se da cuenta y poco a poco se van acumulando las llamadas que te avisan que tu servidor está dando respuestas falsas ("el dominio XYZ no existe"). Incluso aun después de generar una zona nueva correcta y redistribuirla, las respuestas falsas están cacheadas en Internet y perduran durante un cierto tiempo. Una pesadilla para ESNIC. Y una prueba rotunda de algo que siempre se dice en el mundillo: es preferible un servidor que no funciona a un servidor que funciona pero que escupe datos falsos.

¿Cómo se puede evitar este tipo de fallos, si no hay mensajes de error? Introduciendo pruebas automáticas e independientes de plausibilidad a las zonas nuevas que generas, por ejemplo: ¿Cuántas líneas tiene? ¿Cuántos dominios contiene? ¿Son sospechosamente muchos? ¿Son sospechosamente pocos? Idealmente repites las pruebas en todos los secundarios, porque puede ser que al transmitir la zona se produzca algún error de red y se trunque. Para asegurarte de que la zona que tienes en el primario es igual a la del secundario calcula un hash o un CRC, transmítelo en paralelo y recalcúlalo en todas las máquinas para asegurarte de que coincide.