DNS anycast de Netnod: 20 años de 100% de disponibilidad

14/03/2024

Por Lars-Johan Liman, Especialista senior en sistemas y cofundador de Netnod

Publicado originalmente en Netnod blog

Lars-Johan Liman, DNS Nestor de Netnod, comparte algunas reflexiones sobre el vigésimo aniversario del despliegue de anycast por parte de Netnod, una tecnología que es una parte esencial de la infraestructura de los modernos servicios de DNS de Netnod.

Como administradores de uno de los 13 grupos de servidores raíz del DNS de Internet, Netnod emplea una tecnología llamada anycast para que nuestro servicio esté disponible desde una gran cantidad de ubicaciones en todo el mundo. Netnod (para ser más precisos, Autonomica, entonces su empresa filial) fue pionera en la tecnología anycast y este año se cumple el vigésimo aniversario de la primera implementación anycast de Netnod.

El 22 de agosto de 2003 a las 17:01, envié el histórico mensaje que aparece en la figura anterior a mis colegas, los administradores de sistemas de los doce operadores de servidores raíz, después de haber activado la instancia número dos del servidor I-Root. El “número uno” llevaba ya doce años en funcionamiento, pero pasar de una a dos instancias fue el paso más importante, ya que de repente los enrutadores de Internet tenían más de un camino hacia el objetivo. Esto fue generando ondas en toda la estructura del enrutamiento de Internet a medida que la nueva instancia del servidor I-Root se incorporó a las tablas de enrutamiento, que el algoritmo de selección de rutas BGP entró en juego, y que los enrutadores empezaron a determinar la mejor ruta a usar y reenviar a sus pares.

Decidimos instalar el segundo servidor en las instalaciones de nuestros amigos del punto de intercambio de tráfico finlandés FICIX en la ciudad “cercana” Helsinki, Finlandia. Helsinki y Estocolmo están a tan solo 400 kilómetros de distancia, pero entre ellas se encuentra el Mar Báltico.

En ese momento, las máquinas virtuales no eran un concepto demasiado conocido y confiable, por lo que tuvimos que instalar una pila completa de servidores físicos que realizaran las diferentes tareas necesarias.

Los sistemas se instalaron en un rack en el punto de intercambio y se los equipó con conexiones de red y energía para manejar el tráfico DNS esperado y recibir instrucciones de administración desde Estocolmo.

Dedicamos mucho tiempo a planificar la configuración y a preparar la instalación de la red en la instancia existente en Estocolmo para operar con dos instancias. También preparamos una nueva infraestructura de servidores en Estocolmo para manejar la distribución de datos de la zona raíz del DNS. La zona raíz es la base de datos desde donde los servidores raíz sirven los datos. Se actualiza dos veces al día y ahora necesitábamos nuestras propias instalaciones de distribución para proporcionar dos instancias en vez de una. Nuestros planes consistían en aumentar esa cantidad de dos a veinte en el transcurso de dos o tres años.

Al principio, el servidor de Helsinki no tenía acceso al punto de intercambio. Solo podía hablar con la “nave nodriza” en Estocolmo. Usando ese canal, el servidor se cargó con datos correctos. Se colocaron y verificaron las últimas piezas necesarias para armar la red (excepto la última pieza del rompecabezas).

Una vez que nos sentimos cómodos de que todo estaba en su lugar, habilitamos la conexión hacia el punto de intercambio, todavía sin “anunciar” a la red que había algo que se podía alcanzar detrás de nuestro enrutador. Establecimos relaciones de enrutamiento con algunos de los principales proveedores de servicios en el punto de intercambio, todavía sin anunciar nada que fuera de interés.

Después, inicié un pequeño programa paralelo (tcpdump) para observar el tráfico de DNS entrante proveniente del punto de intercambio. Como debía ser, este tráfico era nulo. Con cierta emoción, procedí a ingresar el comando en el enrutador de Helsinki para anunciar la existencia y la accesibilidad de la instancia I-Root local a todos los proveedores de servicios, e informarles que podían enviar tráfico “aquí” en vez de enviarlo a Estocolmo.

Apena levanté mi dedo de la tecla ENTER, el tcpdump cobró vida y comenzaron a llover paquetes de DNS de los proveedores de servicios finlandeses. Un vistazo a la antigua instancia en Estocolmo mostró que todo se veía bien. Hubo una pequeña caída en el volumen de tráfico entrante, que ahora se dirigía a Helsinki. ¡Un éxito!

Todavía esperábamos que se presentaran algunas cosas raras en los flujos de tráfico y el enrutamiento, pero en realidad fueron muy pocas. Sentimos que este iba a ser nuestro futuro.

Durante los últimos 20 años, Netnod ha implementado instancias de servidores raíz del DNS en más de 80 ubicaciones alrededor del mundo: desde Helsinki en Finlandia hasta Port Vila en Vanuatu, desde Timbú en Bután hasta Santiago de Chile, desde Kigali en Ruanda hasta Ulán Bator en Mongolia. En Luleå, Suecia, operamos el servidor raíz más septentrional del mundo. Nuestra instancia principal sigue estando en Estocolmo, Suecia, en un búnker de comunicaciones a prueba de bombas. Hace poco lo actualizamos —¡otra vez! — instalando CPU más potentes y “conexiones más gruesas” a Internet de manera que esta instancia siga siendo nuestro buque insignia.

Contar la cantidad de consultas de DNS a las que hemos respondido a lo largo de los años sería tan imposible como inútil, pero podemos dar una idea de estos números: el ejército actual de servidores de nombres raíz de Netnod responde a aproximadamente 3.700.000.000 de consultas… ¡por día! Y eso casi sin despeinarnos.

El despliegue de anycast reforzó la redundancia de nuestro sistema. Desde ese día de agosto de 2003, el servicio raíz de Netnod no se ha caído ni una sola vez. Sí, se ha degradado ligeramente en ciertos momentos, pero nunca se ha caído. Llevamos 20 años de 100,0000% de disponibilidad. (Sí, tus ojos no te engañan: ¡no hay ningún 9 en ese porcentaje!)

Estamos orgullosos de ofrecer este servicio de forma gratuita como parte de la misión de Netnod de trabajar por el bien de Internet.

Las opiniones expresadas por el autor de este artículo son propias y no necesariamente reflejan las opiniones de LACNIC.