Guía de despliegue seguro de DNS: 15 buenas prácticas para servicios autoritativos

A principios de este año, en marzo de 2026, el NIST publicó SP 800-81r3, su guía para el despliegue seguro de DNS. Se trata de la segunda revisión de este documento (publicado por primera vez 13 años antes), que abarca aproximadamente tres bloques:

1. el uso del DNS como parte de la arquitectura de red
2. el consumo seguro de DNS
3. La seguridad de los servidores DNS autoritativos.

Si aún no lo has hecho, te recomendamos encarecidamente leer nuestro resumen para ponerte al día. Dicho esto, esta guía se centra en el último bloque: la seguridad de los servidores DNS autoritativos. En cierto modo, retoma el tema donde lo dejó el NIST y, tras más de una década desarrollando productos centrados en la seguridad del DNS, queríamos aportar más detalle en forma de buenas prácticas fáciles de seguir para proteger los servidores DNS autoritativos.

Esta es la guía que todo el mundo debería leer para informarse sobre las principales amenazas, determinar cuáles le afectan y decidir qué estrategias de mitigación le convienen más. No te preocupes, ¡es breve!

Si tu audiencia es el público general, es mejor no alojar tus propios servidores DNS autoritativos, por un par de razones. En primer lugar, no es una tarea menor. Para empezar, necesitas dar servicio a una base de usuarios muy distribuida, lo que exige desplegar varios servidores en todo el mundo mediante Anycast para que todos aparezcan como una misma dirección IP. A partir de ahí, debes tener en cuenta la resiliencia: lo ideal es contar con al menos dos niveles de servidores en dos redes independientes. Después, tendrás que preocuparte de mantenerlos operativos y sincronizados. Y, por si fuera poco, de los ataques de denegación de servicio. La lista sigue, pero ya te haces una idea. Realmente no es una tarea menor.

En segundo lugar, existen numerosos proveedores de DNS gestionado de alta calidad a un coste muy razonable. Alojar tu propio DNS no te aporta ninguna ventaja particular, te cuesta más y no lo harás tan bien como los grandes proveedores. Te conviene mucho más dedicar tu tiempo y tus recursos a otras tareas. De hecho, si quieres una presencia DNS muy robusta, probablemente te interese utilizar dos proveedores gestionados para seguir en línea si uno de ellos cae.

Este consejo no se aplica necesariamente si despliegas un servidor DNS autoritativo para una audiencia privada. En ese caso el trabajo es mucho menor; de todos modos querrás mantener tus datos en privado y puedes desplegarlo muy cerca de tus usuarios.

Cuando externalizas tus necesidades de DNS a un tercero, lo habitual es que este mantenga tus datos autoritativos, que tú actualizas mediante una API propietaria. Esto no suele ser un problema si partes de cero, pero es posible que ya dispongas de un servidor DNS que actúa como fuente de verdad. O quizá ya esté integrado en tu organización con flujos de trabajo que no quieres cambiar.

Mantener el control de tu primario es perfectamente válido, pero, por lo general, no conviene exponerlo en la internet pública. Los ataques de denegación de servicio son frecuentes y los atacantes suelen apuntar al punto más débil. Si descubren dónde se encuentra tu primario, es probable que sea el primero en ser atacado.

Tienes varias opciones. En primer lugar, puedes mantenerlo en línea, pero sin anunciar su nombre ni su dirección IP. O bien, puedes desplegarlo con un cortafuegos que permita el acceso desde las redes de tu proveedor de DNS, pero no desde la internet pública.

En esta configuración, tu primario es el plano de control, mientras que tus proveedores de DNS gestionado operan el plano de consultas (datos).

Puede parecer obvio, pero vale la pena comentarlo: combinar funciones autoritativas y recursivas nunca es buena idea. Aunque de lejos ambos parecen servidores DNS, sus funciones son muy distintas. Salvo en situaciones triviales, la función recursiva es más exigente y puede afectar negativamente al componente autoritativo.

Un servidor de nombres primario normalmente solo se comunica con sus secundarios. Su tarea es sencilla: conservar la información maestra del dominio y distribuirla a los servidores encargados de comunicarse con el público. En cambio, los servidores recursivos deben atender a una audiencia amplia (a menudo el público general, justo lo contrario de lo que quieres para un servidor DNS autoritativo), consultar cualquier otro servidor DNS de internet, gestionar una caché, etc.

Por definición, los servidores autoritativos contienen información pública, pero eso no significa que deba entregarse de forma masiva a cualquiera que la solicite. La ocultación sigue teniendo su utilidad. Las transferencias de zona son un mecanismo pensado para propagar actualizaciones de los primarios a los secundarios, pero es habitual encontrar que están disponibles para cualquiera. En la práctica, lo mejor es limitar esta información a quien realmente la necesite.

Si es posible, utiliza controles de acceso a la red y autenticación para evitar que la información de zona caiga en malas manos. Lo habitual es usar la autenticación TSIG, que emplea algoritmos simétricos rápidos. Si necesitas autenticar a un gran número de partes, también existe SIG(0), que utiliza criptografía de clave pública, aunque requiere más esfuerzo de despliegue y mantenimiento.

Algunos servidores DNS anuncian su número de versión. Esto es otro aspecto que conviene comprobar y desactivar.

Una táctica habitual de los atacantes es apuntar a tus interfaces de administración. Si ocultas tu primario, mantenerlo alejado de la internet pública eliminará un vector de ataque importante.

Si tus datos autoritativos están en un proveedor de DNS gestionado, utiliza todos los medios disponibles para proteger las interfaces de administración y los endpoints de la API. Como mínimo, usa la autenticación de dos factores y plantéate también restringir las direcciones IP desde las que se permite el acceso.

En muchas empresas pequeñas, la configuración de las zonas DNS no cambia con frecuencia y puede mantenerse como configuración estática. Tradicionalmente, las actualizaciones dinámicas de DNS (p. ej., RFC 2136) se han reservado a grandes empresas con entornos complejos. Sin embargo, la validación automatizada de dominios para la emisión de certificados X.509 mediante el protocolo ACME se ha popularizado mucho, y uno de sus métodos consiste en un cambio en el DNS.

Permitir actualizaciones dinámicas de DNS entra en conflicto con la posibilidad de blindar tu servidor de nombres primario y mantenerlo seguro. Hay dos aspectos que considerar:

• Los endpoints remotos tienen que conectarse al lugar donde residen tus datos
• Debes garantizar que cada entidad solo pueda modificar un conjunto reducido de datos, no todo

Es posible que tu proveedor de DNS gestionado ofrezca una buena solución para ello en sus API, pero aun así requerirá recursos para diseñarla y gestionarla. Si alojas tu propio servidor de nombres, plantéate usar un proxy reforzado en lugar de exponer tu primario en internet.

Como alternativa, algunos proveedores ofrecen servicios de validación ACME basados en una configuración única de un registro CNAME desde tu dominio hacia un endpoint de terceros. A partir de ese momento, pueden gestionar la validación ACME por ti. Esto ayuda a evitar las actualizaciones dinámicas de DNS, pero, por otro lado, la validación de tus certificados pasa a depender de un tercero.

El control de versiones es tu aliado. Aunque lo más importante es que tus zonas contengan y distribuyan información precisa, saber cuándo y por qué se produjeron los cambios te ayuda a determinar si esa información es realmente correcta. De hecho, hoy en día distribuir tu configuración DNS al mundo no es un gran reto, pero garantizar que tu información siga siendo correcta sí lo es.

Si tu configuración DNS está en forma de archivos de zona, ponlos bajo control de versiones, por ejemplo con Git. Protege la rama principal y utiliza flujos de trabajo basados en pull requests para documentar y validar los cambios a medida que se producen. DNSControl y octoDNS son dos herramientas de código abierto populares que admiten este tipo de flujo de trabajo.

La información que incluyes en tu configuración DNS tiene un propósito y debe distribuirse a quienes la necesitan. Asume que todo lo que incluyas en tus zonas es información pública. No incluyas nada que no quieras que se descubra, porque inevitablemente saldrá a la luz. Revisa periódicamente lo que se anuncia en tus archivos de zona y comprueba si alguna parte puede eliminarse.

A continuación, te ofrecemos un breve resumen de las técnicas de reconocimiento más comunes:

• Transferencias de zona. Si las transferencias de zona están habilitadas, son la forma más eficiente de obtener el archivo de zona completo. No obstante, como ya hemos comentado, deberían estar deshabilitadas por defecto y habilitarse solo donde realmente se necesiten.
• Servicios de DNS pasivo. Históricamente, el DNS nunca protegió el tráfico en tránsito. Como los datos de esos paquetes UDP contienen mucha información útil (p. ej., para elaborar perfiles), surgió toda una industria de monitorización pasiva de DNS. Estas empresas despliegan sondas por todo el mundo, en los puntos de intercambio más concurridos, y registran todo lo que pueden. Después, los datos se ponen a disposición de cualquiera que esté dispuesto a pagar. Estadísticamente, es posible que algunos de tus subdominios menos conocidos no se detecten, pero los más populares sin duda lo serán.
• Certificate Transparency. Certificate Transparency (CT) es un sistema que supervisa la emisión de todos los certificados públicos. Como los certificados incluyen dominios y subdominios, filtran información que antes solía ser privada. Ahora, la información incluso sobre subdominios poco conocidos pasa a ser de dominio público en cuanto se emite un solo certificado. Los comodines, si se usan de forma segura, pueden ayudar en cierta medida, pero, por desgracia, compartir certificados entre servicios no relacionados amplía el "radio de impacto" de un compromiso o de una caducidad.
• Fuerza bruta sobre registros de recursos. Al haber solo un pequeño número de registros de recursos principales, aplicarles fuerza bruta es muy sencillo y genera poco ruido una vez descubierto un subdominio.
• Filtración de información a través de DNSSEC. Cuando se diseñó DNSSEC, su enfoque principal consistía en firmar previamente todos los datos para evitar operaciones criptográficas en tiempo de ejecución. Esto planteaba un problema al responder a dominios arbitrarios inexistentes, ya que la firma dinámica se consideraba demasiado costosa. Dos soluciones fueron los registros NSEC y NSEC3, que evitaban la firma dinámica. Sin embargo, su diseño permitía recorrer ("tree-walk", es decir, descubrir por completo) cualquier zona con DNSSEC habilitado. Las soluciones modernas a este problema se conocen como "White Lies" (RFC 4470) y, más recientemente, "Black Lies" (RFC 9824).
• Enumeración de dominios DNS. Si todo lo demás falla, los atacantes siempre pueden recurrir a la "clásica" enumeración por fuerza bruta. Armados con diccionarios que contienen las etiquetas DNS más comunes (a menudo adaptados a lo que ya se sabe de tu patrimonio de DNS), simplemente lo prueban todo, a menudo a gran velocidad. Estos ataques suelen ser muy ruidosos y poco sofisticados; una buena monitorización debería detectarlos, ya que generan un gran número de respuestas NXDOMAIN.

Como ya hemos comentado, todo lo que incluyas en tus zonas DNS autoritativas acabará siendo público, de una forma u otra. No puedes eliminar lo que realmente necesitas, pero evita compartir de más. Las empresas suelen utilizar un mismo nombre de dominio para necesidades públicas y privadas; en este último caso, su DNS autoritativo contendrá información interna.

Si partes de cero, plantéate utilizar nombres de dominio distintos para las actividades públicas y privadas. Si ya compartes un nombre de dominio, plantéate un despliegue de DNS de zona dividida (split-zone), en el que la parte pública contenga únicamente lo que es verdaderamente público y la información privada se distribuya mediante una infraestructura independiente a la que solo puedan acceder tus usuarios internos.

Para ocultar información, lo mejor es utilizar una PKI privada para tus certificados internos. Esto conlleva un coste nada despreciable, que incluye el esfuerzo y el gasto de mantener una CA privada y la necesidad de instalar sus certificados raíz en todos los dispositivos cliente.

Inicialmente un servicio sencillo que se limitaba principalmente a proporcionar información sobre direcciones IP (registros A), el DNS se ha vuelto cada vez más complejo con el tiempo. Hoy cuenta con bastantes piezas móviles y modos de fallo. No solo habrá varios servidores (primario y secundarios), sino que además estarán distribuidos por todo el mundo. Deben funcionar sobre IPv4 e IPv6, y sobre UDP y TCP. A gran escala, los problemas surgen constantemente, y la mejor forma de detectarlos es mediante una monitorización activa.

Los registros de consultas de los servidores DNS a menudo se olvidan, pero si alojas tus propios servidores, sin duda deben supervisarse y almacenarse junto con el resto de registros. Si sigues estas buenas prácticas, los registros de tu servidor de nombres primario serán bastante escasos. Cualquier cosa que aparezca en ellos indicará que algún control ha fallado.

Por defecto, todo el espacio de dominios de tus zonas autoritativas está bajo tu control directo. El DNS es distribuido por naturaleza, con punteros no solo hacia otros lugares que controlas, sino también hacia terceros. Esto se hace con mayor frecuencia mediante registros CNAME, delegación de subzonas y, en raras ocasiones, incluso mediante registros DNAME.

Estas delegaciones suelen añadirse para que el tercero pueda prestar algún tipo de servicio, pero hay que tener presente que cada delegación introduce un elemento de riesgo. Por ello, deben registrarse y supervisarse como parte de tu gestión de riesgos. Implica a tu equipo de seguridad de aplicaciones, ya que puede evaluar si los dominios delegados pueden afectar a la seguridad de los dominios padre o hermanos. Informa también a quienes supervisan tu PKI, porque los terceros pueden estar emitiendo certificados en tu nombre a través de CA distintas de las tuyas.

Lo ideal es que tu plataforma de monitorización ofrezca un inventario completo de las delegaciones a terceros. Anótalas con su finalidad y su responsable y, si es posible, establece una fecha de caducidad. Incluye también en esta lista las delegaciones de servicio a dominios que no te pertenecen.

Las delegaciones a terceros que comentamos en la buena práctica anterior conllevan riesgos mientras están activas, pero a veces suponen un riesgo aún mayor cuando dejan de funcionar. Cuando eso ocurre, un tercero malicioso puede tomar el control de ellas.

Los motivos más habituales por los que esto ocurre:

• Se contrata una suscripción a un servicio de terceros y se añade un CNAME que apunta a la infraestructura del proveedor. Tiempo después, se cancela la suscripción, pero el CNAME permanece. Si el destino del CNAME también se elimina, el caso es sencillo, porque el registro de recursos DNS queda roto. Sin embargo, con mayor frecuencia, estos CNAME apuntan a un destino genérico (es decir, un único destino para todos los clientes), lo que da lugar a un servicio colgante mucho más difícil de detectar.
• Se configura un nuevo servicio en la nube, identificado por una o varias direcciones IP. Se añaden registros DNS de tipo A y AAAA. Tiempo después, el servicio se da de baja, pero los registros DNS permanecen. El proveedor de nube asigna entonces esas direcciones IP, ya sin uso, a otros de sus clientes.

Estos son dos de los problemas más comunes, pero el DNS está intrínsecamente lleno de formas de apuntar de un lugar a otro. Prácticamente cualquier registro de recursos (RR) DNS puede causar un problema de este tipo: A, AAAA, CNAME, NS, SOA, MX, CAA, SRV, TXT, HTTPS… y así sucesivamente.

El problema de fondo es que, una vez configurado un puntero, no hay forma de mantenerlo sincronizado con su destino. Una monitorización exhaustiva y continua de toda la superficie DNS es la única forma de detectar estos problemas a tiempo, antes de que actores maliciosos puedan explotarlos.

Tus adversarios te atacarán de cualquier forma posible. A veces, si no pueden abusar directamente de tus nombres de dominio (p. ej., explotando un registro DNS colgante), registrarán nombres de dominio que, a ojos tanto de tus empleados como de tus clientes, podrían pasar por tuyos.

Puedes recibir alertas sobre estos dominios similares mediante un servicio de terceros, como Red Sift Brand Trust. La detección se consigue supervisando el inventario completo de nombres de dominio del mundo, junto con otras técnicas diversas.

No liberes ni olvides renovar nombres de dominio que estuvieron en uso. Si lo haces, es probable que alguien vuelva a registrarlos y que incluso se utilicen en tu contra. Al fin y al cabo, te pertenecieron y es probable que aún conserven parte de tu reputación implícita.

Además, la titularidad de un dominio se utiliza a veces para establecer relaciones de confianza con terceros. Si se abandona un nombre de dominio, quien lo obtenga heredará las relaciones de confianza existentes.

DNSSEC sigue siendo un tema controvertido, y quizá hayas notado que no lo hemos incluido entre nuestras buenas prácticas. Lo cierto es que tenemos sentimientos encontrados. Por un lado, DNSSEC ofrece una funcionalidad que no existe en ningún otro lugar: la integridad criptográfica de la resolución DNS autoritativa. (Para ver un ejemplo de por qué esto es importante, consulta esta entrada del blog, que explica cómo mejora la seguridad de la PKI web).

Por otro lado, su adopción sigue siendo muy baja. DNSSEC es difícil de operar y las herramientas todavía son poco maduras. La mayoría de las empresas evitan DNSSEC a menos que su plataforma de alojamiento lo automatice, aunque la seguridad se resienta.

Para empeorar las cosas, la amenaza inminente de los ordenadores cuánticos con relevancia criptográfica obligará a DNSSEC a cambiar sus algoritmos criptográficos subyacentes, pero aún no está claro cómo serán esos cambios, ni siquiera si UDP seguirá siendo el principal mecanismo de transporte, dado el tamaño mucho mayor de las firmas poscuánticas.

En resumen, creemos que DNSSEC cumple una función muy importante, pero no hemos podido clasificarlo como buena práctica porque no se ha aceptado universalmente como tal.

Si se explota un registro DNS colgante o un servicio colgante, las consecuencias pueden ser muy incómodas. Sin embargo, existe una posible mitigación que se basa en que los navegadores modernos exigen certificados X.509 válidos. Si pudiéramos impedir que los atacantes obtengan un certificado válido, sus intentos de explotación podrían fracasar.

Por defecto, si controlas una dirección IP a la que apunta un dominio DNS, puedes obtener un certificado para ella. Pero no tiene por qué ser así, ya que los titulares de dominios pueden publicar políticas que orienten la validación de dominios. La tecnología para ello se denomina Certification Authority Authorization (CAA) y todas las CA públicas están obligadas a respetarla.

En el contexto de los DNS colgantes, CAA te ofrece un par de opciones: 1) centralizar la emisión de certificados para todo el nombre de dominio, impidiendo por completo que los servidores individuales obtengan certificados directamente; o 2) exigir que, para cada dominio, se utilice una cuenta ACME específica.

Red Sift Attack Surface Monitoring (ASM), anteriormente Hardenize, fue la primera plataforma del mundo de descubrimiento y monitorización continua en profundidad, diseñada para empresas que quieren supervisar su propia presencia en internet. Dentro de ASM, el componente DNS de este producto implementa por completo los aspectos de monitorización descritos en este documento, incluida la supervisión del estado de los servicios autoritativos y de las conexiones con terceros, así como la detección de registros y servicios DNS colgantes.

La solución Red Sift Brand Trust detiene los ataques con dominios similares antes de que dañen tu marca. Detecta, supervisa y retira los dominios similares maliciosos gracias a la protección de dominios y marcas impulsada por IA.

• RFC 9499: Terminología del DNS
• NIST SP 800-81 Rev. 3: Guía de despliegue seguro de DNS
• Red Sift: Guía de despliegue seguro de DNS del NIST: buenas prácticas
• IANA: Requisitos técnicos para servidores de nombres autoritativos