El viernes pasado vivimos un pequeño momento de pánico en Fintual cuando llegó este mensaje a un canal que tenemos para reportar problemas que necesitan de atención inmediata:

fnt.al es un dominio que usamos internamente para acortar links. Por ejemplo, en este caso, matias quería entrar a rellenar un formulario de feedback que el equipo de personas dejó amablemente en fnt.al/formulario. Pero no pudo completarlo por ese críptico mensaje y la bien conocida pestaña triste que muestra Chrome cuando tiene un error y nos quiere distraer.

El problema es que nadie había cambiado ninguna configuración, el dominio seguía vigente y el servicio para acortar urls parecía bien configurado, pero el navegador se negaba a resolver el dominio.
En la desesperación, y buscando no ser los únicos con el problema (y por lo tanto no ser los culpables), descubrimos que tampoco funcionaba entrar a nic.al, que es la institución encargada de administrar los dominios que terminan en .al (que son de Albania). Pasó por nuestras cabezas que podría estar relacionado con la Revolución de los Flamencos (protestas en Albania fines de mayo), pero no. El problema era mucho más simple, y mucho más fome: el DNS.

¿Y qué son los DNS? Para eso tenemos que adentrarnos en las cloacas de la infraestructura del internet. En particular, en la forma que nuestros computadores saben a quién ir a preguntarle cuando escribimos fintual.cl en la barra de direcciones.
Como sabrán algunos, cuando un computador está conectado a alguna red, se le asigna una dirección única dentro de esa red. Esta dirección se llama dirección IP (por Internet Protocol). Por ejemplo, si estás en tu casa conectado a tu red wifi, probablemente tengas una dirección que se vea como 192.168.x.x. Entonces puede ser que tu teléfono use 192.168.1.25 y tu computador 192.168.1.26 y tu tostadora 192.168.1.29. Si desde tu teléfono tratas de entrar a http://192.168.1.25, le va a preguntar a tu computador si es que tiene algo para responder, y si no tienes algún servidor andando, lo más probable es que veas un error como el que vió matias al intentar darle feedback a sus compañeros. En el caso de Fintual, una de las IPs públicas que tiene asignada es la 10.10.05.12 (en verdad no, pero sirve para el ejemplo), entonces si nuestro computador le manda un paquete a esa dirección, ese mensaje va a llegar a los servidores de Fintual.

En teoría podríamos entrar siempre a los sistemas que ocupamos usando su IP pública, pero se podrán imaginar que no es lo más práctico y puede llegar a ser bastante inseguro (la gente identifica más rápido un texto mal escrito que un número mal escrito). Antes nos teníamos que acordar de los teléfonos de amigos y familiares, pero ahora que tenemos smartphones nadie tiene tiempo para estar aprendiéndose números de memoria.
Para solucionar este problema a los diseñadores del internet se les ocurrió agregar un nuevo componente: DNS (Domain Name System). Básicamente funciona como la guía de teléfono, pero para el internet. Una lista gigante que traduce nombres a direcciones IP. Se podrán imaginar que estos nombres son las direcciones a las que estamos acostumbrados, como fintual.cl o google.com.
Cuando entran en un navegador a fintual.cl, lo primero que hace el navegador es tratar de encontrar la IP a quien consultar, que es la única dirección válida para encontrar el servidor en internet. Para eso tiene que ir a preguntarle a un servidor de DNS cuál es la IP de fintual.cl. Este servidor puede ser el de tu proveedor de internet o uno público como el 8.8.8.8 de Google o 1.1.1.1 de Cloudflare, que muchas veces funcionan mejor (por qué estas compañías ofrecerían gratis este servicio queda como ejercicio para el lector). Con eso, la tarjeta de red puede mandar paquetes de mensajes dirigido a esa IP, y los routers del mundo se encargan de rutear estos mensajes para que lleguen al servidor correcto.

¿Y qué tiene que ver todo esto con matias que solo quiere dar feedback?
El error que le salió significa que el navegador, cuando le preguntó al servidor DNS por fnt.al le contestó básicamente “no tengo idea quién es ese tal fnt.al”. Desastre.

Después de investigar un rato descubrimos que si hacíamos la consulta agregando un parámetro para ignorar las verificaciones de seguridad (DNSSEC), funcionaba bien.

DNSSEC es una extensión del protocolo original de consultas DNS. Se parece a TLS que es el protocolo para cifrar y firmar los mensajes que se transmiten por HTTP (también conocido como el candado que aparece al entrar a páginas con https en vez de http).
Un elemento importante de estos protocolos es que los mensajes van firmados por una cadena de llaves que certifican que el la final es legítima. En este caso una de estas firmas estaba vencida (o mal generada) y el protocolo dice que ante cualquier falla de validación, el proceso termina en error, que se terminó propagando hasta el computador de matias.
Los responsables de estas firmas y llaves son los operadores de la infraestructura de DNS, en este caso es una organización estatal en Albania que administra los servidores autoritativos para la zona .al. Parecido a NIC Chile, que administra los dominios chilenos .cl.

El problema no era de nosotros y, aún peor, probablemente estaba afectando a todos los dominios .al. Unos minutos después encontramos que Cloudflare había reportado la incidencia y estaba buscando cómo solucionarla, y al rato avisaron que habían mitigado el error desde su lado desactivando las validaciones de DNSSEC para los dominios de la zona .al. La solución parche que aplicaron es muy similar a la que ya habían usado cuando la zona .de (de Alemania) tuvo un problema parecido (acá un artículo muy bueno con la descripción). Con eso arreglaron el problema para sus usuarios mientras los albaneses corregían el problema de raíz. A las horas se deshabilitó DNSSEC para toda la zona y las consultas volvieron a funcionar correctamente.
Lo más probable es que la AKEP estaba probando una próxima implementación de DNSSEC para su zona y se les pasó alguna llave firmada por ellos mismos en vez de por una llave raíz.


Respuestas de consultas DNS a fnt.al antes y después de que se corrigió el problema generadas con DNSViz. En la de la izquierda la zona raíz tiene exige que la zona .al tenga una llave que la consulta no encuentra. En la de la derecha ya no existe el registro DS y la zona completa (al/SOA) aparece en gris, es decir, insegura.
El DNS es uno de estos componentes con los que interactuamos todos los días y todo el día sin darnos cuenta. Constantemente nuestros equipos hacen consultas a servidores que se identifican por un nombre y tienen que transformarse a una IP antes de empezar cualquier comunicación. DNS nació en un internet muy distinto al de ahora, cuando era más una curiosidad de pocos que una infraestructura crítica para el funcionamiento del mundo. Con el tiempo ha ido cambiando y evolucionando, pero ha mantenido su carácter distribuido. Esto significa que no hay un solo punto central dueño de la verdad, sino que múltiples actores que se tienen que poner de acuerdo.
Y como todos los acuerdos en la vida, no siempre es fácil mantenerlos.
Y una vez que nos descoordinamos, no siempre es fácil o rápido volver a la normalidad. Lo mismo pasa con los errores de DNS. Cuando ocurren, no es fácil encontrar al culpable, y aunque lo encontremos, no es rápido propagar el nuevo acuerdo. Cada cambio tiene que comunicarse a miles de servidores en todo el mundo, que a veces puede tomar varias horas. Por eso es que los errores de DNS son probablemente de los más típicos que ocurren en la administración de sistemas conectados a internet. Al final nuestro problema fue menor porque no tenemos nada crítico en esos dominios, pero probablemente el pánico duró más de unos minutos para más de alguna empresa albanesa.