Un servidor web devuelve 500, las conexiones a la base de datos fallan intermitentemente, y el equipo de desarrollo jura que no han tocado nada. Alguien sugiere revisar los logs, otro insiste en que es un problema de red, y mientras tanto el sistema de monitorización muestra que todo está verde. Dos horas después, alguien se da cuenta: el servidor DNS secundario lleva caído desde ayer y nadie lo había notado hasta que el primario se saturó. El problema no era el código, ni la red, ni la base de datos. Era DNS. Siempre es DNS.
Existe una broma recurrente en el sector: cuando algo falla y no sabes por qué, probablemente sea DNS. Y si no es DNS, es un problema de permisos. Y si no son permisos, vuelve a revisar DNS. La gracia funciona porque tiene un fondo de verdad incómodo: DNS es uno de esos sistemas que todo el mundo usa, pocos entienden bien, y casi nadie monitoriza correctamente hasta que algo se rompe de forma espectacular.
Este artículo no es un repaso de cómo funciona la resolución de nombres. Es un recorrido por los errores que rompen sistemas en producción, esos que aparecen en retrospectivas de incidentes y que, con perspectiva, parecen obvios. Pero en el momento, con la presión de un servicio caído, no lo son tanto.
El TTL que nadie respeta hasta que importa
El Time To Live de un registro DNS indica cuánto tiempo pueden los resolvers intermedios mantener esa respuesta en caché sin volver a consultar al servidor autoritativo. Es un concepto sencillo que genera problemas complejos cuando se ignora. Configurar un TTL alto, de varias horas o incluso días, parece razonable: reduce la carga en los servidores autoritativos y mejora el rendimiento. Hasta que hay que hacer un cambio urgente y descubres que parte de tu infraestructura seguirá apuntando a la IP antigua durante las próximas doce horas.
El error habitual no es usar TTLs altos en sí, sino no planificar los cambios con antelación. Cuando se sabe que va a haber una migración, una actualización de IPs o un cambio de proveedor, lo sensato es reducir el TTL días antes. Bajarlo de 86400 segundos a 300 segundos con suficiente margen permite que, cuando llegue el momento del cambio, la propagación sea rápida. Pero esto requiere coordinación, documentación y que alguien se acuerde de hacerlo.
Otro escenario típico: un registro con TTL bajo que genera miles de consultas innecesarias porque alguien lo configuró así durante una prueba y nunca lo volvió a ajustar. El equilibrio está en entender qué registros cambian con frecuencia y cuáles son estables. Los registros de servicios críticos que rara vez cambian pueden permitirse TTLs de varias horas. Los que forman parte de infraestructuras dinámicas o balanceadores necesitan valores más conservadores.
Resolvers internos que se convierten en puntos únicos de fallo
Muchas organizaciones montan sus propios servidores DNS internos para resolver nombres de servicios privados, integrar con directorios corporativos o simplemente tener control sobre las consultas. La configuración típica incluye un par de servidores, quizá tres si alguien fue previsor, y todo funciona bien. Hasta que uno falla y nadie se entera porque el otro sigue respondiendo. Cuando el segundo también cae, o se satura porque ahora maneja todo el tráfico, el sistema completo deja de funcionar.
El problema no es técnico, es organizativo. Los servidores DNS internos suelen caer en una zona gris de responsabilidades: no son lo suficientemente críticos como para recibir atención constante, pero cuando fallan, todo se para. Es común encontrar entornos donde los DNS internos no tienen monitorización específica, no están incluidos en los runbooks de incidentes, y nadie sabe exactamente quién los mantiene.
La solución pasa por tratarlos como lo que son: infraestructura crítica. Eso significa monitorización activa de las consultas, alertas cuando los tiempos de respuesta suben, y pruebas periódicas de failover. También implica documentar qué servicios dependen de ellos y tener un plan B si todo falla. Algunos equipos optan por configurar resolvers públicos como respaldo en caso de emergencia, aunque esto tiene sus propias implicaciones de seguridad y privacidad.
Cachés que mienten y resolvers que no olvidan
Los sistemas operativos, las aplicaciones, los navegadores y los propios servidores DNS mantienen cachés en múltiples niveles. Esto es eficiente, pero genera situaciones donde un cambio en los registros DNS no se refleja inmediatamente en todos los puntos de la infraestructura. El registro se actualiza, el servidor autoritativo responde correctamente, pero algún resolver intermedio sigue devolviendo la respuesta antigua porque su caché aún no ha expirado.
Este comportamiento es especialmente frustrante durante incidentes. Se hace un cambio para redirigir el tráfico a un servidor de respaldo, se comprueba que el registro DNS está actualizado, pero parte de los usuarios siguen llegando al servidor problemático. La tentación es pensar que algo está mal configurado, cuando en realidad el sistema está funcionando exactamente como debe: respetando los TTLs y las políticas de caché.
Aquí entra en juego el concepto de caché negativa, definido formalmente en la RFC 2308, que es aún más traicionero. Cuando un cliente pregunta por un registro que no existe, el resolver puede cachear esa respuesta negativa. Si después se crea ese registro, el resolver seguirá respondiendo que no existe hasta que expire esa caché. Esto rompe despliegues automatizados que asumen que un registro recién creado estará disponible inmediatamente.
No hay forma de eliminar cachés remotas de forma centralizada. La única defensa es planificación: crear los registros DNS con antelación, verificar que se resuelven correctamente antes de usarlos, y asumir que cualquier cambio tardará al menos el tiempo del TTL en propagarse completamente. En entornos donde esto no es aceptable, la alternativa es usar TTLs muy bajos de forma permanente, pero eso tiene su propio coste en carga y latencia.
Dependencias circulares y el huevo y la gallina
Un escenario clásico: el servidor DNS primario está configurado para sincronizar su configuración desde un repositorio Git. El repositorio está alojado en un servidor interno cuyo nombre se resuelve mediante DNS. Si el servidor DNS se reinicia y no puede resolver el nombre del repositorio, no puede cargar su configuración. Si no puede cargar su configuración, no puede resolver nombres. El sistema entra en un bucle del que no puede salir sin intervención manual.
Este tipo de dependencias circulares aparecen en sistemas complejos donde todo está automatizado y orquestado. Otro ejemplo típico: un sistema de monitorización que envía alertas cuando el DNS falla, pero las alertas se envían a un webhook cuyo nombre necesita ser resuelto por DNS. O un balanceador que consulta el estado de los backends usando nombres DNS, pero los propios servidores DNS están detrás de ese balanceador.
La prevención requiere mapear las dependencias críticas y asegurarse de que los sistemas fundamentales pueden arrancar de forma autónoma. Los servidores DNS deberían poder iniciar con una configuración mínima que no dependa de servicios externos. Las IPs de servicios críticos deberían estar también disponibles como respaldo directo, sin pasar por resolución de nombres. Y los sistemas de monitorización de DNS deberían usar IPs directas para sus comprobaciones, no nombres que a su vez requieran DNS.
Registros huérfanos y zonas fantasma
Con el tiempo, las zonas DNS acumulan registros que ya no apuntan a nada útil. Servidores que se dieron de baja hace meses pero cuyos registros siguen ahí. Subdominios de proyectos cancelados. Alias que apuntaban a servicios que ya no existen. Estos registros huérfanos no suelen causar problemas directos, pero complican el mantenimiento y pueden generar confusión durante incidentes.
Peor aún son las zonas fantasma: configuraciones DNS para dominios o subdominios que ya no se usan pero que siguen configurados en los servidores autoritativos. Estas zonas consumen recursos, pueden generar consultas inesperadas, y en algunos casos crean agujeros de seguridad. Un caso especialmente peligroso es el de los registros CNAME que apuntan a recursos en la nube ya dados de baja: un atacante puede registrar ese recurso externo y empezar a recibir tráfico que debería ser interno o que los usuarios confían como legítimo. Este tipo de secuestro de subdominios es más frecuente de lo que parece en organizaciones que usan servicios cloud de forma intensiva.
La limpieza periódica de registros DNS debería ser parte del mantenimiento habitual, pero rara vez lo es. Requiere coordinación entre equipos, conocimiento de qué servicios siguen activos, y cierto valor para borrar cosas que llevan años ahí sin que nadie sepa exactamente para qué sirven. Una estrategia intermedia es marcar registros como obsoletos, monitorizarlos durante un tiempo para ver si alguien los usa, y solo entonces eliminarlos definitivamente.
Monitorización que llega tarde
La mayoría de sistemas de monitorización comprueban que los servidores DNS responden, pero no verifican que las respuestas sean correctas. Un servidor puede estar devolviendo IPs equivocadas, registros obsoletos o respuestas inconsistentes entre réplicas, y seguir pasando las comprobaciones básicas de disponibilidad. Cuando alguien se da cuenta del problema, el sistema lleva horas o días funcionando mal de forma silenciosa.
La monitorización efectiva de DNS va más allá del simple ping o de comprobar que el puerto 53 está abierto. Implica hacer consultas reales de registros críticos y verificar que las respuestas coinciden con lo esperado. Implica medir los tiempos de respuesta y alertar cuando suben por encima de umbrales razonables. Implica comprobar que los servidores secundarios están sincronizados con el primario y que las transferencias de zona funcionan correctamente.
También implica monitorizar desde múltiples puntos. Un servidor DNS puede estar funcionando perfectamente desde la perspectiva de la red interna pero ser inaccesible desde ciertas ubicaciones externas. O puede estar respondiendo correctamente a consultas simples pero fallando en consultas más complejas o con respuestas grandes que requieren TCP. En entornos que han implementado DNSSEC, la monitorización debe incluir la validación de firmas y la renovación de claves: una firma expirada o una cadena de confianza rota puede provocar que resolvers validadores rechacen respuestas perfectamente legítimas, con el agravante de que el problema solo afecta a los clientes que validan, haciendo el diagnóstico aún más confuso.
Cuando el problema es de diseño, no de ejecución
Algunos problemas de DNS no se resuelven ajustando configuraciones o corrigiendo errores puntuales. Son problemas de arquitectura: diseños que funcionan en entornos pequeños pero que no escalan, o que asumen condiciones de red que no se cumplen en la realidad. Un ejemplo típico es usar un único dominio para todos los servicios, lo que dificulta delegar responsabilidades, aplicar políticas diferentes o migrar servicios entre proveedores.
Otro error de diseño común, y probablemente el más extendido, es no separar DNS público de DNS interno. Usar los mismos servidores para resolver nombres externos e internos puede parecer eficiente, pero genera problemas de seguridad, complica el diagnóstico de fallos y hace que un fallo afecte a todo simultáneamente. La separación permite aplicar políticas diferentes, optimizar cada sistema para su caso de uso, y aislar fallos. Esta separación se ha vuelto aún más relevante con la adopción de DNS sobre HTTPS y DNS sobre TLS por parte de los navegadores y sistemas operativos modernos: cuando los clientes cifran sus consultas y las envían directamente a resolvers externos, las consultas escapan al control del resolver corporativo sin que nadie lo detecte. Los equipos que no han planificado este escenario descubren que sus políticas internas de resolución simplemente no se aplican a una parte creciente del tráfico.
El diseño también importa en cómo se estructuran las zonas y subdominios. Una jerarquía plana con cientos de registros en una sola zona es difícil de mantener y propensa a errores. Delegar subdominios a equipos específicos, usar zonas separadas para entornos diferentes, y mantener una estructura lógica facilita el mantenimiento y reduce la probabilidad de cambios accidentales que rompan cosas.
Lo que queda después del incidente
DNS es uno de esos sistemas que funcionan tan bien la mayor parte del tiempo que es fácil olvidarse de ellos. Hasta que algo falla. Y cuando falla, lo hace de formas que no siempre son obvias: timeouts intermitentes, comportamientos inconsistentes entre clientes, problemas que aparecen y desaparecen sin razón aparente. La complejidad no está en el protocolo en sí, que es relativamente simple, sino en todas las capas de caché, forwarding, políticas y dependencias que se acumulan en sistemas reales.
Los errores que rompen todo no suelen ser fallos técnicos puros. Son decisiones de diseño que parecían razonables en su momento, configuraciones que nadie revisó después del despliegue inicial, o simplemente falta de atención a un sistema que se daba por sentado. La diferencia entre un entorno donde DNS es un problema recurrente y uno donde funciona de forma fiable está en tratarlo como infraestructura crítica desde el principio: con monitorización específica, documentación actualizada, y alguien que sepa exactamente qué hacer cuando las cosas se tuercen.
Porque al final, cuando un servicio cae y nadie sabe por qué, alguien va a sugerir revisar DNS. Y esa persona probablemente tenga razón.
Para seguir aprendiendo
Profundizar en DNS más allá de los conceptos básicos ayuda a entender por qué fallan las cosas y cómo prevenirlo. Estas referencias ofrecen perspectivas técnicas sólidas desde diferentes ángulos:
«DNS and BIND» de Cricket Liu y Paul Albitz (O’Reilly). Referencia clásica que cubre desde fundamentos hasta configuraciones avanzadas y resolución de problemas en entornos reales. La quinta edición, aunque publicada en 2006, sigue siendo el tratamiento más completo del tema en un solo volumen. Enlace: https://www.oreilly.com/library/view/dns-and-bind/0596100574/
Documentación oficial de BIND, mantenida por Internet Systems Consortium. Fuente autoritativa sobre uno de los servidores DNS más desplegados, con explicaciones detalladas de comportamientos y opciones de configuración. Enlace: https://bind9.readthedocs.io/en/latest/
«TCP/IP Illustrated, Volume 1» de W. Richard Stevens y Kevin R. Fall (Addison-Wesley, segunda edición, 2011). El capítulo sobre DNS contextualiza el protocolo dentro del stack completo y explica interacciones con otros componentes de red. La segunda edición actualiza el contenido original de Stevens con cobertura de IPv6 y DNSSEC. Enlace: https://www.amazon.com/TCP-Illustrated-Protocols-Addison-Wesley-Professional/dp/0321336313
RFC 1034 y RFC 1035, disponibles a través de IETF. Los documentos fundacionales del sistema DNS, escritos por Paul Mockapetris en 1987. Útiles para entender decisiones de diseño y comportamientos que a veces parecen contraintuitivos. La RFC 2308, del mismo ámbito, detalla el funcionamiento de la caché negativa. Enlaces: RFC 1034 · RFC 1035 · RFC 2308
Documentación de PowerDNS Authoritative Server, mantenida por el proyecto PowerDNS. Alternativa moderna a BIND con enfoque en backends flexibles y APIs, útil para entornos automatizados. La versión actual es la 5.0. Enlace: https://doc.powerdns.com/authoritative/
Documentación de Unbound, mantenida por NLnet Labs. Resolver recursivo ligero y orientado a seguridad, ampliamente desplegado como alternativa a BIND en su función de resolver. Especialmente relevante en entornos donde se quiere separar la función autoritativa de la recursiva. Enlace: https://unbound.docs.nlnetlabs.nl/