miércoles, agosto 30, 2006

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:


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.

domingo, agosto 27, 2006

Carretera y manta

Como el Sábado pasado no se nos ocurría dónde ir a pasar la tarde, dejamos a J al volante y acabamos en el castillo de Münzenberg.




jueves, agosto 24, 2006

viernes, agosto 18, 2006

Inundación en la oficina

Estamos en verano, la época de las lluvias súbitas e intensas. Y también la época de las vacaciones-santillana y de las inundaciones con correos electrónicos del estilo

Subject: out of office

Ich werde bis zum 24. August nicht im Büro sein.
In dringenden Fällen wenden Sie sich bitte an xxx@xxx

I will be out of the office until August 24th.
In urgent cases please contact xxx@xxx

En principio, estas contestaciones automáticas son útiles: sabes que no vas a tener respuesta inmediata de la otra persona (que es la expectativa habitual hoy en día en el mundo del e-mail) y puedes reaccionar en ocasiones urgentes dirigiéndote, en su defecto, a un tercero. El lado oscuro de las respuestas automáticas es, sin embargo, que ahorita mismo estoy recibiendo mensajes de éstos en cantidades ingentes, incluso de personas que no conozco, y ya no sé a qué correo de quién no voy a recibir respuesta hasta cuándo.

¿Por qué ocurre esto? En primer lugar están las personas que son tan guays como para configurar su cliente (o su servidor) de correo para enviar respuestas automáticas, pero que olvidan introducir las excepciones. Por ejemplo: Nunca envíes mensajes de ausencia a una lista de correo a la que estés suscrito, porque a las personas que ahí leen y escriben, poco les importa si te has ido de vacaciones o a criar malvas. En el peor de los casos, la autorespuesta va a la propia lista, lo que puede desencadenar otras autorespuestas e iniciar así un diálogo para besugos, como en un mano a mano de dos bots de charla. En el mejor de los casos la respuesta va a parar al buzón de un extraño sorprendido.

Luego están los agentes de autorespuesta que no memorizan a quién le han enviado ya un correo y a quién no. Combinando con una lista de correo, el resultado es enervante: No sólo no sé quién es el Sr. Fulano Zutano Mengano, sino que además su ordenador me restriega por las narices con saña varias veces al día que él está en las Bahamas, probablemente hartándose a cócteles, mientras yo estoy en Agosto en la pegajosa ciudad currando y discutiendo temas de trabajo por correo.

Y por último tenemos los mensajes de autorespuesta que no dan indicios acerca del correo que los ha originado y ponen constantemente tu propia memoria a prueba ("¿y yo cuándo escribí al tipet este y para qué?"). En concreto, mi querido Lotus Notes no rellena los campos In-Reply-To o References en la cabecera del correo, los cuales generalmente contienen el identificador del mensaje original. Después de comunicar esta semana el bug a IBM e informarles de que están violando el RFC 3834, la reacción del soporte técnico en Irlanda ha sido llamar por teléfono aquí a la oficina para preguntar dónde pueden encontrar el RFC ése en Internet.

Sólo me queda por decir: "O tempora, o mores!"

martes, agosto 15, 2006

Recensión técnica: GlobeSurfer

Te encuentres en la playa o en la montaña, lo más probable es que haya cerca un hotspot de Wi-Fi abierto al que asociarse y poder acceder a Internet con tu PDA o tu portátil. Pero si eres un verdadero adicto y no quieres dejar nada al azar, te agencias un GlobeSurfer ICON. En estos momentos tengo uno de pruebas para la empresa.

Se conecta al portátil por el puerto USB y controla todos los modos de transmisión de datos inalámbricos que le echen, desde 2G (GSM corriente y moliente) hasta 3.5G (HSDPA de UMTS). En HSDPA consigo 1.8 Mbps nominales de bajada en casi todo el trayecto de tren del trabajo a casa, y cuando no, el handover a GPRS es (casi) transparente para las aplicaciones: sólo un pequeño cuelgue instantáneo. Es fácil de instalar (el software necesario para Windows está dentro del aparato) y de configurar (basta con insertar tu SIM en la ranura que se ve en la imagen). La única pega que veo de momento es que la batería del portátil se descarga casi el doble de rápido.

lunes, agosto 07, 2006

Por el juguete tradicional

Otras criaturas ya sólo se contentan con tecnología punta, pero nosotros acostumbramos a J a que juegue con cubo, rastrillo y pala...
...o con su nuevo escondite favorito, el cesto de la colada:
Como si fuera a posar para una foto de Anne Geddes, J se pone tieso para que le metan en el angosto cesto y luego se divierte asomando ligeramente la cabeza y mirando a su alrededor en plan periscopio.

domingo, agosto 06, 2006

Swret Grrl


A lo mejor ésta (tomada en el mercadillo de Massamagrell) me la publican en Engrish.com. No tan buena como la legendaria "All your base are belong to us", pero bastante enigmática.

miércoles, agosto 02, 2006

Buena suerte, JULIFOR

Mi profesora de alemán, activa literata con dos libros ya en su currículum (del último tengo un ejemplar con dedicatoria :-), ha iniciado ahora un blog en el que los asistentes a su taller de literatura juvenil (JU-LI-FOR, otra de sus actividades) colaboran online para confeccionar una novela. La autoría de los capítulos se va turnando entre los participantes. Es una original idea que merece que prospere.

Lo que me recuerda a un correo electrónico de coña que me llegó hace bastante tiempo de alguno de vosotros, sospechosos habituales de reenviar emails-avalancha. En él, para ilustrar las diferencias entre los dos sexos, se contaba una historia ficticia y cómo la continuarían alternativamente un hombre y una mujer. Si la memoria no falla, al final el relato degenera y los dos acaban saboteándose las líneas de argumento y matándose mutuamente los personajes. Me apetecería leer esta tontería de nuevo, ¿le suena a alguien? ¿tenéis un enlace?