DNS distribuido: implementación de servidor en 7 días

En pocas palabras: Sí: un DNS distribuido se levanta en una semana con BIND respondiendo, FRR (o Quagga) hablando BGP y Nagios sacando el anuncio anycast cuando un nodo falla. Los cero incidentes tras varios rebuilds no vienen del código, sino del rollback: retirar la ruta BGP toma segundos.

Un desarrollador publicó que levantó un servidor DNS distribuido en poco tiempo y lo reconstruyó varias veces sin un solo incidente. La implementación de un servidor DNS distribuido en ese plazo es posible, con anycast, BGP y un plan de rollback probado antes del cutover.

Un servidor DNS distribuido es una infraestructura de resolución de nombres en la que varios nodos, ubicados en distintos puntos de red, anuncian la misma dirección IP mediante anycast y BGP. Cada consulta cae en el nodo más cercano según la topología de ruteo. Si un nodo se cae, el ruteo lleva el tráfico al siguiente sin cambiar nada en el cliente.

En 30 segundos

El plazo corto es real pero engañoso: arma el nodo, no la operación.
El stack clásico sigue siendo el mismo: BIND para responder, Quagga (o FRR) para hablar BGP, Nagios para chequear salud y sacar el anuncio cuando algo falla.
Cero incidentes viene del rollback, no del código: si podés retirar el anuncio BGP de un nodo en segundos, un rebuild deja de ser un evento de riesgo.
El tuning de kernel te muerde antes que el software: nf_conntrack_max con los valores por defecto hace que el recursivo empiece a descartar consultas bajo carga.
El posteo de exe.dev que originó el titular no publica métricas del DNS: su argumento es otro, que un LLM no es un compilador.

¿En qué se diferencia un DNS distribuido de uno centralizado?

La diferencia es dónde vive la IP. En un DNS centralizado, una o dos máquinas tienen direcciones distintas y el cliente elige entre ellas con un timeout de por medio. En un DNS distribuido con anycast, todos los nodos anuncian la misma IP y es el ruteo de Internet el que decide cuál responde, sin que el cliente se entere ni espere.

Eso cambia el modelo de falla por completo. Ponele que tenés dos NS clásicos y se cae el primario: el resolver del usuario intenta, espera el timeout (entre 1 y 5 segundos según implementación) y recién ahí prueba el secundario. Multiplicá eso por cada consulta no cacheada de cada visitante y ya tenés un sitio que “anda lento” sin que ningún gráfico de CPU te muestre nada raro. Para más detalles técnicos, mirá automatizar despliegues sin incidentes.

Con anycast, ese mismo escenario es un cambio de ruta BGP que tarda menos que el timeout.

Aspecto	DNS centralizado	DNS distribuido (anycast)
Direcciones IP	Una por servidor	La misma en todos los nodos
Failover	Timeout del resolver del cliente	Convergencia BGP, sin acción del cliente
Latencia	Fija según ubicación del server	Baja al nodo más cercano por topología
Superficie ante DDoS	Concentrada en un punto	Repartida entre nodos, absorbe por región
Requisitos	Un VPS y un registro NS	ASN propio o de tránsito, sesiones BGP, prefijo anunciable
Complejidad operativa	Baja	Alta: ruteo, health checks, monitoreo por nodo

¿Qué componentes necesitás para implementar un servidor DNS distribuido?

Necesitás tres piezas que casi nunca vienen juntas: un servidor DNS que responda, un daemon de ruteo que anuncie el prefijo por BGP, y un sistema de chequeo que retire ese anuncio cuando el servidor deja de responder bien. El stack clásico para eso es BIND, Quagga y Nagios.

El servidor DNS es la parte fácil. BIND, Knot, PowerDNS o Unbound si es recursivo. Acá casi no hay decisiones difíciles y todos están bien documentados.
El daemon BGP es el que da miedo. Quagga funciona, aunque hoy la mayoría arranca con FRRouting o BIRD. Es el componente que anuncia el prefijo a tu upstream.
El health check es lo que separa un despliegue prolijo de una caída. No alcanza con mirar si el proceso está vivo: hay que consultar de verdad, desde afuera, y verificar la respuesta.
El pegamento es un script. Si el chequeo falla N veces seguidas, se retira el anuncio y el tráfico se va solo a otro nodo. Si vuelve, se anuncia de nuevo. Eso es todo el “alta disponibilidad” que necesitás.

Si estás del lado de infra y no tenés ASN propio, el camino corto es apoyarte en un proveedor que ya tenga el ruteo resuelto y vos poner los nodos encima. Para infraestructura en Argentina, donweb.com tiene servidores donde levantar los nodos secundarios sin pelearte con la latencia transatlántica de una región europea.

¿Cuánto tarda de verdad desplegar un DNS distribuido?

Una semana es un plazo razonable para tener el primer nodo funcionando y validado en laboratorio, no para tener la operación completa. El armado técnico (instalar, configurar zonas, levantar la sesión BGP, escribir los chequeos) entra cómodo en cinco días. Lo que no entra es la validación con tráfico real, que se mide en semanas.

Un desglose honesto de esos siete días:

Días 1 y 2, diseño. Qué prefijo anunciás, con qué upstreams, qué zonas servís, si es autoritativo o recursivo (no mezcles los dos roles en la misma IP).
Días 2 y 3, laboratorio. Todo el stack en máquinas virtuales, con sesiones BGP contra un route reflector de prueba. Acá es donde descubrís que el filtro de prefijos del upstream no te deja anunciar lo que creías.
Días 3 a 5, testing de falla. Matás BIND y mirás cuánto tarda en irse el anuncio. Matás la placa de red. Dejás el proceso vivo pero devolviendo SERVFAIL, que es el caso que más gente no prueba.
Días 5 a 7, rollout parcial. Un nodo en producción, con los NS viejos todavía arriba, midiendo desde afuera.

¿Y el resto? Los treinta días siguientes son de observación, y ahí es donde aparecen los problemas que ningún test de laboratorio te muestra. Te puede servir nuestra cobertura de herramientas de integración continua modernas.

¿Cómo se logra cero incidentes durante los rebuilds?

Se logra desacoplando el rebuild del tráfico. Antes de tocar un nodo, retirás su anuncio BGP y esperás la convergencia (segundos). El nodo queda fuera del anycast, lo reconstruís entero, lo validás con consultas directas a su IP de gestión, y recién después volvés a anunciarlo. Reconstruir sin sacar el anuncio es lo que genera el incidente.

Acá viene lo bueno: ese patrón convierte el rebuild en algo aburrido. Podés destruir y rearmar el nodo cuantas veces quieras, porque durante todo ese rato no está recibiendo una sola consulta de usuario. La “gracia” de reconstruir un servidor DNS varias veces sin incidentes no está en la calidad del código que lo genera, está en que el ruteo ya sacó al paciente de la mesa antes de la cirugía.

Ojo con un detalle: el chequeo de salud tiene que consultar un nombre que exista y comparar la respuesta. Un nodo que responde REFUSED a todo sigue respondiendo, y un monitor mal escrito lo va a dar por sano mientras el 30% de tus usuarios no resuelve nada.

¿Qué problemas técnicos aparecen en producción?

El primero suele ser el kernel, no el software DNS. El recursivo empieza a descartar consultas por saturación de la tabla de conexiones y hay que subir nf_conntrack_max. Con volúmenes altos de consultas por segundo, los defaults de cualquier distribución se quedan cortos en minutos. Complementá con infraestructura distribuida en múltiples regiones.

Los otros tres que se repiten:

Hardware viejo en nodos secundarios. Es tentador reciclar máquinas para los nodos “de respaldo”, hasta que el ruteo decide que ese nodo es el más cercano para media región y no da abasto.
Rutas BGP que no hacen lo que esperabas. Anycast te lleva al nodo más cercano en saltos de AS, que no siempre es el más cercano en kilómetros ni el de menor latencia real. Hay que medir desde varios puntos, no asumir.
DDoS que no tira el servicio pero satura el uplink. El tráfico se reparte entre nodos, que es la ventaja, aunque el nodo que recibe el grueso puede quedarse sin ancho de banda antes de que BIND transpire.

¿Qué métricas hay que monitorear en un DNS distribuido?

La métrica que manda es la tasa de éxito de respuesta medida desde afuera, no el uptime del proceso. Es un número que suele sonar más bajo de lo esperado hasta que entendés que incluye consultas a dominios inexistentes y timeouts de servidores autoritativos ajenos.

QPS por nodo. Si un nodo tiene el 80% del tráfico, tu anycast está desbalanceado y tenés un single point of failure disfrazado.
Latencia P95 y P99, no el promedio. El promedio de un DNS sano y uno con el 5% de consultas en timeout se parecen demasiado.
Tasa de SERVFAIL y REFUSED. Es el indicador temprano de que algo se rompió en la cadena recursiva.
Estado del anuncio BGP por nodo. Un nodo que dejó de anunciar y nadie notó es capacidad que pagás y no usás.

¿Qué tiene que ver Claude con un servidor DNS?

El titular sale de un posteo del blog de exe.dev, “Claude Is Not a Compiler”. Su tesis no es sobre DNS: el autor sostiene que comparar un LLM con un compilador es un error de categoría, porque el software se construye en capas donde cada paso agrega especificación y cada paso implica decisiones.

La cita que importa: “Un compilador bueno y confiable libera al ingeniero de software de tener que tomar esas decisiones. La mayoría de los ingenieros tiene poca idea de cómo funcionan los compiladores; no necesitan saberlo para ser efectivos.” El punto es que un LLM todavía no tiene esa propiedad, porque las decisiones que toma no son consistentes ni auditables del mismo modo.

¿Hay métricas del DNS en ese posteo? En el texto publicado, no. No hay QPS, ni latencias, ni detalle del stack, ni una definición de qué se entendió por “cero incidentes”. Tomalo con pinzas: es la anécdota de una persona sobre su propio proyecto, no un caso de estudio con datos verificables. La parte reproducible del asunto está en los casos documentados de anycast, y ahí sí hay números que alguien más midió.

Errores comunes al implementar DNS distribuido

Anunciar el prefijo antes de que el servicio esté respondiendo. Ese nodo se transforma en un agujero negro para toda la región que rutea hacia él. Corrección: el anuncio se hace desde el script de health check, nunca a mano en el arranque.
Monitorear el proceso en vez de la respuesta. Un BIND vivo que devuelve SERVFAIL pasa cualquier chequeo de systemctl status. Corrección: el chequeo consulta un registro conocido y compara el valor devuelto.
Mezclar autoritativo y recursivo en la misma IP anycast. Son cargas distintas, patrones de falla distintos y superficies de ataque distintas. Corrección: prefijos separados, siempre.
Dejar los defaults del kernel. nf_conntrack_max, buffers de socket UDP y límites de descriptores son los tres que revientan primero bajo carga real. Corrección: tunealos antes del rollout, no durante el incidente.
Bajar el TTL “por las dudas” antes del cutover y olvidarse de subirlo. Multiplicás tu tráfico de consultas por diez de forma permanente.

Preguntas Frecuentes

¿Qué es DNS anycast?

DNS anycast es una técnica en la que varios servidores DNS en ubicaciones distintas anuncian la misma dirección IP a Internet mediante BGP. El ruteo entrega cada consulta al nodo más cercano en términos de topología de red. Es la base de las implementaciones de DNS distribuido de alta disponibilidad. Lo explicamos a fondo en servicios descentralizados sin dependencias externas.

¿Cuánto tarda implementar un DNS distribuido desde cero?

Entre cinco y siete días de trabajo técnico para el primer nodo validado en laboratorio y un rollout parcial. La validación con tráfico real y el ajuste de kernel bajo carga suman varias semanas más. El plazo de “una semana” describe el armado, no la operación estabilizada.

¿Qué necesito para anunciar por BGP?

Un prefijo IP propio o delegado por tu proveedor, un ASN (propio o el del upstream si acepta anuncios de clientes) y una sesión BGP configurada con un daemon como FRRouting, BIRD o Quagga. Sin acuerdo con el upstream para aceptar tu prefijo, el anuncio no sale de tu router.

¿El DNS distribuido protege contra DDoS?

Reparte el ataque entre nodos según el origen geográfico del tráfico, lo que evita que un solo servidor absorba todo. No es mitigación: si el volumen satura el uplink del nodo más golpeado, ese nodo cae igual. Sirve como capa de resiliencia, combinada con filtrado y rate limiting.

¿Cuál es la diferencia entre anycast y GeoDNS?

Anycast trabaja en la capa de ruteo: una sola IP, y la red decide qué nodo responde. GeoDNS trabaja en la capa de aplicación: el servidor DNS mira la IP de origen de la consulta y devuelve una respuesta distinta según la región. Se pueden combinar, y de hecho la mayoría de los CDN los usan juntos.

Conclusión

Lo interesante del caso no es que alguien haya armado un DNS distribuido rápido. Es que el “cero incidentes” no vino de escribir mejor código, vino de una propiedad de la arquitectura: si podés retirar un nodo del anycast en segundos, reconstruirlo deja de ser un evento riesgoso y pasa a ser mantenimiento de rutina.

Si vas a encarar esto, el orden importa. Primero el health check que retira el anuncio, después el nodo. Al revés, tarde o temprano tenés un agujero negro anunciando tu IP. Y antes de festejar el uptime, medí la tasa de respuesta desde afuera de tu red: es un número mucho más honesto que cualquier “99,99% de uptime” sacado del monitor de procesos.

DNS distribuido en una semana: qué hace falta de verdad