La seguridad del DNS es el conjunto de medidas de control que garantizan que el DNS de tu dominio sea preciso, esté disponible y permanezca bajo tu control, de modo que los atacantes no puedan redirigir tu tráfico, suplantar tu dominio ni dejarlo fuera de servicio.
A continuación, explicamos por qué la seguridad del DNS es fundamental para la infraestructura moderna, aclaramos la confusión que existe entre la seguridad general del DNS y el DNSSEC, ofrecemos una lista de comprobación práctica de 12 pasos para reforzar la seguridad y presentamos un plan priorizado que indica qué aspectos deben solucionarse en primer lugar.
¿Qué es la seguridad del DNS?
El DNS funciona detrás de cada solicitud web, llamada a la API y envío de correo electrónico, pero se creó sin autenticación integrada ni verificación criptográfica. La seguridad del DNS abarca las políticas, configuraciones, protocolos y prácticas de supervisión necesarias para proteger los nombres de dominio y la infraestructura de servidores de nombres frente a la manipulación no autorizada, el espionaje y las interrupciones operativas.
En lugar de basarse en una única herramienta, una seguridad DNS eficaz requiere una defensa que abarque cuatro capas operativas distintas:
- Nivel de registrador: Controles que protegen el registro de tu dominio, los registros de titularidad del dominio y las credenciales de acceso administrativo para evitar la apropiación no autorizada de cuentas.
- Capa de servidores de nombres autoritativos: Medidas de seguridad aplicadas a los servidores autoritativos que alojan sus archivos de zona públicos, lo que garantiza un tiempo de actividad resistente, redundancia y transferencias de zona controladas.
- Resolución y capa de transporte: Medidas aplicadas a los resolutores recursivos y al tráfico de consultas, que protegen las solicitudes de búsqueda contra el espionaje en la ruta, la alteración y la manipulación de la caché local.
- Capa de registros e identidad: Registros criptográficos y políticas de seguridad publicados dentro de su zona, incluidas las firmas DNSSEC, las políticas de autorización de las CA y las normas de autenticación del correo electrónico.
La mayoría de las brechas de seguridad se originan en una vulnerabilidad evitable en una de estas capas. Comprender cómo interactúan estas capas ayuda a los equipos de seguridad a eliminar las vulnerabilidades latentes vulnerabilidades del DNS antes de que los atacantes las detecten y las aprovechen. Las organizaciones que siguen programas de cumplimiento normativos formales también pueden consultar las directrices de seguridad del DNS del NIST para conocer los requisitos básicos federales.
¿Por qué es importante la seguridad del DNS?
Dado que el protocolo básico del Sistema de Nombres de Dominio (DNS) transmite las consultas en texto sin cifrar y sin validación criptográfica del origen, el tráfico DNS sin procesar confía de forma inherente en las respuestas recibidas. Las organizaciones suelen realizar importantes inversiones en cortafuegos, cortafuegos de aplicaciones web (WAF) y agentes de detección en los terminales, mientras que dejan sus zonas DNS prácticamente sin supervisar.
Cuando los atacantes manipulan el DNS, eluden por completo las defensas perimetrales. El compromiso de una zona DNS permite a un adversario redirigir el tráfico web corporativo hacia réplicas maliciosas, emitir certificados TLS válidos a nombre de tu marca o interceptar comunicaciones confidenciales por correo electrónico sin necesidad de acceder a los servidores físicos de tu red.
Sin una seguridad integral del DNS, las organizaciones se enfrentan a graves vectores de amenaza:
- Secuestro de DNS y compromiso del registrador: Los atacantes se hacen con las credenciales del registrador o recurren a la ingeniería social para redirigir los servidores de nombres autoritativos hacia hosts maliciosos.
- Suplantación de DNS y envenenamiento de caché: Los atacantes introducen registros de recursos fraudulentos en resolutores recursivos vulnerables, redirigiendo a los usuarios a destinos destinados a la recopilación de credenciales.
- Amplificación de DNS y DDoS: Se hace un uso indebido de los resolutores recursivos abiertos para dirigir respuestas de gran volumen contra una víctima, saturando el ancho de banda y dejando fuera de servicio servicios enteros.
- Registros pendientes y apropiación de subdominios: Los registros DNS huérfanos que apuntan a recursos en la nube desactivados o a buckets de alojamiento son apropiados por agentes externos para alojar contenido malicioso bajo tu marca.
- Suplantación de identidad en el correo electrónico a través de registros DNS deficientes: La ausencia o una configuración incorrecta de las políticas SPF, DKIM y DMARC permite a los estafadores enviar correos electrónicos de spear phishing que aparentan proceder de tu dominio corporativo.
Para obtener un desglose completo de las metodologías de ataque, consulta nuestra guía sobre los 10 tipos de ataques al DNSy comprueba tu dominio con nuestro comprobador de DNSSEC.
Seguridad DNS frente a DNSSEC
Un error muy común entre los equipos de TI es considerar que «seguridad DNS» y «DNSSEC» son términos intercambiables. No lo son.
DNSSEC (Extensiones de seguridad del Sistema de Nombres de Dominio) es un control técnico específico dentro de un marco de seguridad más amplio. DNSSEC utiliza criptografía de clave pública para firmar digitalmente los registros DNS dentro de un archivo de zona. Cuando un resolutor de validación comprueba un dominio firmado, verifica la firma comparándola con una cadena de confianza que llega hasta la zona raíz, lo que garantiza que la respuesta recibida no haya sido alterada durante la transmisión.
La seguridad global del DNS abarca todo el ciclo de vida de la gestión y la arquitectura de defensa. Aunque el DNSSEC garantiza la autenticidad y la integridad de los registros, no resuelve todas las amenazas:
- DNSSEC no cifra el tráfico de consultas ni garantiza la confidencialidad frente a posibles intrusos.
- DNSSEC no impide que los atacantes se hagan con el control de tu cuenta de registrador y modifiquen tus registros de delegación públicos.
- El protocolo DNSSEC no mitiga los ataques DDoS volumétricos ni impide que los resolutores abiertos participen en tormentas de amplificación.
- DNSSEC no detecta registros CNAME «suspensos» que apunten a recursos en la nube de terceros que ya no están en servicio.
DNSSEC es un componente obligatorio de una infraestructura reforzada, pero debe funcionar junto con los bloqueos de los registradores, el cifrado del transporte, los controles estrictos del correo electrónico y la supervisión continua de las zonas. Obtén más información sobre cómo funciona la validación criptográfica en nuestra guía sobre DNSSEC.
Prácticas recomendadas de seguridad del DNS: la lista de comprobación para el refuerzo de la seguridad
Para garantizar la seguridad de tu dominio es necesario adoptar hábitos operativos estructurados y reproducibles. La siguiente lista de comprobación recoge 12 controles esenciales, organizados por capa de infraestructura y complejidad de implementación.
| Buenas prácticas | Capa | Nivel de esfuerzo |
|---|---|---|
| Bloquea tu dominio a nivel del registrador | Secretario | Bajo |
| Aplica la autenticación de dos factores (MFA) y el acceso basado en roles en tu registrador | Secretario | Bajo |
| Restringir las transferencias de zona (AXFR) | Servidor de nombres | Bajo |
| Implementar servidores de nombres autoritativos redundantes | Servidor de nombres | Medio |
| Implementar DNSSEC con criptografía moderna | Expediente e identidad | Medio |
| Publicar un registro de autorización de autoridad de certificación (CAA) | Expediente e identidad | Bajo |
| Auditoría de registros sin asignar y huérfanos | Expediente e identidad | Medio |
| Establece valores TTL razonables y realiza un seguimiento de las ventanas de propagación | Servidor de nombres | Bajo |
| Cifrar el transporte entre el cliente y el resolutor (DoH / DoT / DoQ) | Resolución y transporte | Medio |
| Fortalecer el software de resolución local y de servidores de nombres | Resolución y transporte | Alta |
| Implementar las zonas de política de respuesta (RPZ) | Resolución y transporte | Medio |
| Aplicar los protocolos de autenticación de correo electrónico: SPF, DKIM y DMARC | Expediente e identidad | Medio |
1. Bloquea tu dominio a través del registrador
Las solicitudes de transferencia no autenticadas constituyen una de las principales vulnerabilidades para los activos críticos del dominio. Aplica clientTransferProhibited y clientUpdateProhibited a sus dominios.
En el caso de los dominios corporativos de gran valor, solicita un «Registry Lock» a tu registrador. El «Registry Lock» requiere una verificación fuera de línea, como una confirmación telefónica con el personal designado, antes de que se pueda realizar cualquier cambio en las delegaciones de los servidores de nombres o en los contactos administrativos del WHOIS.
2. Implemente la autenticación multifactorial (MFA) y el acceso basado en roles en su registrador
Asegúrate de que las cuentas administrativas de tu registrador de dominios y de tu proveedor de alojamiento DNS no dependan únicamente de contraseñas. Implemente la autenticación multifactorial (MFA) basada en hardware mediante llaves de seguridad FIDO2 / WebAuthn.
No guardes las credenciales de inicio de sesión del registrador en los buzones compartidos del equipo. Implementa un control de acceso basado en roles (RBAC) estricto, de modo que el personal de TI general tenga acceso de solo lectura, reservando los permisos de gestión del dominio para los administradores de dominio designados.
3. Restricción de transferencias de zona (AXFR)
Los servidores DNS de referencia utilizan transferencias de zona completas (AXFR) para replicar los datos del DNS entre los servidores primarios y secundarios. Si tu servidor de nombres permite solicitudes AXFR sin restricciones desde cualquier dirección IP, los atacantes pueden descargar todo tu archivo de zona. Esto deja al descubierto las estructuras internas de nombres de host, los servidores de prueba y la infraestructura de red oculta.
Configura tus servidores de nombres principales para que solo permitan transferencias AXFR a las direcciones IP específicas de tus servidores de nombres secundarios autorizados. Puedes comprobar tu configuración desde la línea de comandos de un terminal:
dig AXFR tudominio.com @ns1.tudominio.com
Si el servidor devuelve la lista completa de registros DNS en lugar de un error de «Transferencia fallida» o «RECHAZADA», la configuración de transferencia de tu zona está abierta y es necesario restringirla de inmediato.
4. Implementar servidores de nombres autoritativos redundantes en redes diferentes
Depender de un único proveedor de DNS o de un único centro de datos físico supone un punto único de fallo. Si tu proveedor sufre un ataque DDoS o una interrupción de la red, toda tu presencia en línea queda inactiva.
Implementa al menos dos servidores de nombres autoritativos alojados en números de sistema autónomo (ASN) distintos y en redes geográficamente dispersas. El uso de un modelo de DNS autoritativo con dos proveedores garantiza que, si uno de ellos sufre un fallo en su infraestructura, el proveedor secundario seguirá resolviendo las consultas sin interrupciones.
5. Implementar DNSSEC con criptografía moderna
DNSSEC añade firmas digitales a tus registros DNS. Cuando un resolutor recursivo consulta una zona habilitada para DNSSEC, valida las firmas criptográficas (registros RRSIG) comparándolas con una cadena de confianza que se remonta hasta la zona raíz. Esto ayuda a garantizar que la respuesta no se haya modificado durante la transmisión.
A la hora de implementar DNSSEC, sigue las directrices actualizadas de la norma NIST SP 800-81r3:
- Utiliza criptografía moderna basada en curvas elípticas, como la curva ECDSA P-256 o Ed25519, en lugar de claves RSA obsoletas. Las claves de menor tamaño reducen el riesgo de fragmentación de paquetes a través de UDP.
- Mantenga los plazos de validez de las firmas entre 5 y 7 días para limitar el periodo de exposición de una clave comprometida.
- Programa las renovaciones de las claves de firma de zona (ZSK) cada 1 a 3 años y almacena las claves de firma de claves (KSK) en configuraciones de hardware seguras siempre que sea posible.
Puedes comprobar si la cadena criptográfica de tu dominio está intacta sometiendo tu dominio a una verificador de DNSSEC.
6. Publicar un registro de autorización de autoridad de certificación (CAA)
A registro CAA permite a los propietarios de dominios especificar qué autoridades de certificación (CA) están autorizadas a emitir certificados digitales TLS para su dominio y sus subdominios.
Antes de emitir un certificado, las autoridades de certificación públicas deben consultar el DNS del dominio en busca de registros CAA. Si existe un registro CAA, solo las autoridades designadas (por ejemplo, Let’s Encrypt o DigiCert) están autorizadas a tramitar las solicitudes de emisión. Esto impide que empleados malintencionados o sistemas de terceros comprometidos soliciten certificados no autorizados a través de proveedores no autorizados.
Incluye una etiqueta «iodef» en tu registro CAA que apunte a un buzón de correo de contacto de seguridad activo para recibir alertas inmediatas en caso de que una CA no autorizada reciba una solicitud de certificado para tu dominio. Valida la sintaxis de tu registro con nuestro comprobador de CAA.
7. Auditoría de registros sueltos y huérfanos
Revisa periódicamente tu inventario de registros publicados para localizar nombres de host obsoletos. Presta especial atención a los registros CNAME que apuntan a servidores en la nube de terceros, a los subdominios asociados a proveedores de correo electrónico fuera de servicio y a los registros A caducados que apuntan a direcciones IP retiradas.
Antes de realizar cambios estructurales, comprueba tus registros publicados utilizando un herramienta de búsqueda de registros . Revisa los distintos tipos de registros DNS en todos los subdominios activos ayuda a evitar la exposición accidental a ataques de apropiación de subdominios.
8. Establecer valores de TTL razonables y realizar un seguimiento de los plazos de propagación
Los parámetros de «Time-To-Live» (TTL) determinan durante cuánto tiempo los resolutores recursivos almacenan en caché un registro DNS antes de solicitar una copia actualizada a tu servidor de nombres autoritativo.
- Operaciones estándar: Establece los TTL predeterminados entre 3.600 segundos (1 hora) y 86.400 segundos (24 horas). Esto equilibra la carga del servidor y la latencia de las consultas.
- Antes de la migración o en caso de respuesta a incidentes: Reduzca los valores de TTL a 300 segundos (5 minutos) al menos entre 24 y 48 horas antes de los cambios previstos en la infraestructura.
Reducir los TTL con antelación garantiza una rápida caducidad de la caché en los resolutores globales si necesitas desviar el tráfico de un servidor afectado. Puedes supervisar cómo se propagan los cambios por los resolutores globales utilizando una herramienta de herramienta de comprobación de la propagación del DNS.
9. Cifrado del transporte entre el cliente y el resolutor (DoH / DoT / DoQ)
Las consultas DNS estándar se transmiten a través del puerto 53 de UDP y TCP en texto sin cifrar, lo que expone a los usuarios a la vigilancia local, al seguimiento por parte de los proveedores de servicios de Internet, a las escuchas y a la manipulación a lo largo de la ruta en los distintos saltos de la red local.
Los protocolos modernos protegen el tramo de transporte entre el cliente y el resolutor mediante marcos criptográficos de probada eficacia:
- DNS sobre HTTPS (DoH): Envuelve las solicitudes de DNS dentro de sesiones HTTPS estándar a través del puerto 443, ocultando el tráfico de consultas entre las solicitudes web habituales.
- DNS sobre TLS (DoT): Dirige las consultas DNS a través de un túnel TLS cifrado específico por el puerto 853, lo que aísla las transacciones DNS al tiempo que proporciona una autenticación sólida de los puntos finales. Para comprender cómo los protocolos de cifrado subyacentes protegen los flujos de transporte, lee nuestra guía básica sobre la diferencia entre SSL y TLS.
- DNS sobre QUIC (DoQ): Transmite las consultas a través de QUIC (puerto UDP 853), lo que minimiza la sobrecarga que supone el establecimiento de la conexión y elimina el bloqueo de cabeza de cola.
Configura los terminales internos de la empresa, los sistemas operativos y los reenviadores de la red local para que el enrutamiento de la resolución ascendente se realice exclusivamente a través de resolutores seguros que apliquen los protocolos DoH o DoT.
10. Reforzar la seguridad del software de resolución local y de los servidores de nombres
Si su organización mantiene resolutores recursivos internos o gestiona instancias de servidores de nombres autoritativos dedicados mediante BIND, Unbound, PowerDNS o el DNS de Windows Server, siga unas prácticas rigurosas de refuerzo de la seguridad del sistema:
- Desactivar la recursividad abierta: Asegúrese de que los resolutores recursivos solo procesen consultas procedentes de rangos de red internos de confianza. Dejar los resolutores abiertos a consultas arbitrarias de Internet expone su infraestructura a ataques de amplificación a través de resolutores abiertos.
- Funciones separadas: Nunca ejecute el alojamiento autoritativo y la resolución recursiva en la misma instancia de software del servidor.
- Aplica las actualizaciones de seguridad tan pronto como estén disponibles: Suscríbete a las listas de avisos de seguridad de tus proveedores de software. En los paquetes DNS heredados se detectan con frecuencia vulnerabilidades como errores de caché, fallos de búfer y fugas de memoria. Realiza un seguimiento continuo del software DNS que no esté actualizado y aplica los parches correspondientes.
- Ocultar las versiones del software: Desactiva las consultas públicas de versión (como la consulta TXT «version.bind» de BIND) para impedir que los escáneres de reconocimiento obtengan información sobre tu versión específica del software.
- Habilitar la limitación de la tasa de respuesta (RRL): Implementar el RRL en los servidores de referencia para limitar las avalanchas de consultas rápidas y repetidas dirigidas a dominios idénticos, frenando así la participación en ataques de reflexión.
11. Implementar las zonas de política de respuesta (RPZ)
Las zonas de políticas de respuesta, a menudo denominadas «cortafuegos DNS», permiten a los administradores de resolutores recursivos superponer fuentes de información sobre amenazas personalizadas a la resolución de nombres estándar.
Cuando un dispositivo cliente intenta resolver un dominio que se sabe que aloja malware, servidores de comando y control (C2) o páginas de phishing, las reglas RPZ interrumpen la consulta. El resolutor devuelve un respuesta NXDOMAIN o redirige al usuario a una página de bloqueo interna.
12. Aplicar los protocolos de autenticación de correo electrónico: SPF, DKIM y DMARC
La autenticación del correo electrónico funciona directamente a través de registros TXT específicos publicados en tu zona DNS. Sin unos registros de correo electrónico bien gestionados, cualquier remitente externo puede enviar correos electrónicos fraudulentos que parezcan proceder de tu nombre de dominio.
Una estrategia completa de protección del correo electrónico requiere tres estándares interrelacionados:
- SPF (Sender Policy Framework): Publica una lista autorizada de direcciones IP de servidores y proveedores de retransmisión externos a los que se les permite enviar correo en nombre de tu dominio. Repasa los conceptos básicos en nuestra guía sobre SPF, DKIM y DMARC.
- DKIM (DomainKeys Identified Mail): Utiliza criptografía de clave pública para añadir una firma digital a los encabezados de los correos electrónicos salientes. La clave pública se publica en la zona DNS, lo que permite a los destinatarios verificar que el contenido del mensaje no ha sido alterado durante la transmisión.
- DMARC (Autenticación, notificación y conformidad de mensajes basados en el dominio): Unifica SPF y DKIM bajo una política centralizada publicada en _dmarc. DMARC ofrece visibilidad sobre la actividad de envío e indica a los servidores de correo de los destinatarios cómo deben tratar los correos electrónicos que no cumplen con los requisitos.
Pasar a una política DMARC (p=cuarentena o p=rechazo) garantiza que los servidores de correo de los destinatarios rechacen o aíslen los mensajes no autorizados que utilicen tu identidad. Comprueba tu configuración actual con nuestro comprobador de registros DMARCy sigue nuestra guía técnica para publicar un registro DMARC.
Supervisión del DNS: la práctica que la mayoría de los equipos pasan por alto
La implementación de controles de seguridad no es una tarea que se realice una sola vez. Los registros DNS se van desviando con el tiempo a medida que los equipos lanzan campañas de marketing temporales, cambian de proveedor de correo electrónico, rotan los servidores de nombres delegados y retiran la infraestructura obsoleta. Sin una visibilidad automatizada, los cambios no autorizados o las configuraciones erróneas involuntarias pueden pasar desapercibidos durante meses.
Una rutina rigurosa de supervisión del DNS debe realizar un seguimiento continuo de:
- Cambios en los servidores de nombres y en las delegaciones: Detección inmediata de modificaciones en los registros NS o en los registros «glue» de la zona principal que puedan indicar un compromiso de la cuenta.
- Desviación de MX y SPF: Visibilidad sobre los intercambios de correo recién publicados o las modificaciones en los mecanismos de remitentes SPF.
- Estado de validación de DNSSEC: Comprobaciones automáticas que confirman que las firmas de clave, los registros RRSIG y las cadenas DS permanecen activos y no han caducado.
- Aprovechamiento de la transferencia de zona: Registro de solicitudes repetidas de transferencia AXFR realizadas desde redes externas no autorizadas.
- Registro y caducidad de certificados: Seguimiento proactivo de las fechas de renovación de los dominios y de la vigencia de los certificados SSL/TLS públicos para evitar caducidades accidentales.
- Activaciones de dominios similares: Supervisión de dominios recién registrados que contienen homógrafos o errores tipográficos y que activan registros MX para suplantar a tu marca.
DNS gestionado y filtrado en la capa DNS: dónde encajan
Las empresas modernas suelen implementar plataformas de DNS gestionadas y filtros de seguridad en la capa de DNS para simplificar las operaciones y mejorar la visibilidad de las amenazas.
Proveedores de DNS gestionado de confianza
Los proveedores de DNS gestionado para empresas operan redes Anycast globales que distribuyen su archivo de zona autoritativo por cientos de ubicaciones periféricas. La infraestructura Anycast ofrece mitigación de DDoS integrada, lo que permite absorber ataques volumétricos masivos antes de que lleguen a su red central. Las plataformas gestionadas también automatizan la gestión de claves DNSSEC y el mantenimiento de los registros DNS.
Filtrado recursivo en la capa DNS (DNS protector)
Las soluciones de DNS protector (PDNS) funcionan en la capa del resolutor recursivo. En lugar de limitarse a responder a las consultas, las soluciones PDNS comparan cada solicitud con bases de datos dinámicas de inteligencia sobre amenazas.
Si un empleado hace clic en un enlace que conduce a un dominio de phishing recién registrado o si una carga útil infectada intenta conectarse a un servidor C2, el resolutor de protección bloquea la resolución en la capa de red.
Ni el DNS gestionado ni el filtrado de DNS sustituyen a las buenas prácticas de los registradores de dominios ni a una configuración adecuada de los registros. Ambos constituyen capas complementarias dentro de una arquitectura de seguridad «Zero Trust» más amplia.
Qué auditar primero: plan de acción prioritario
Corregir una cartera de dominios en los 12 controles de la lista de verificación puede resultar abrumador. Sigue este calendario priorizado para abordar primero las vulnerabilidades críticas:
- Día 1: Garantizar la titularidad de la cuenta
- Activa la autenticación multifactorial (MFA) mediante dispositivo físico en el portal de tu registrador de dominios.
- Activa el bloqueo de registro en todos los dominios registrados.
- Elimina las cuentas de administrador inactivas y sin asignar.
- Día 2: Proteger el enrutamiento del tráfico principal
- Restringir las transferencias de zona (AXFR) a servidores de nombres secundarios verificados.
- Analiza tus archivos de zona públicos en busca de registros CNAME, A o NS «soltos» que apunten a servicios en la nube no reclamados.
- Desactiva la recursión abierta en cualquier servidor de resolución corporativo conectado a Internet.
- Semana 1: Implementación de la identidad criptográfica
- Publica un registro CAA en el que se indiquen las autoridades de certificación que hayas elegido.
- Configura y firma tus zonas de producción utilizando algoritmos DNSSEC modernos, asegurándote de que los registros DS se validen en el registro principal.
- Semana 2: Aplicar la autenticación del correo electrónico
- Revisa tus mecanismos SPF activos y elimina los proveedores que no utilices.
- Implementa las claves DKIM en todas las pasarelas de correo saliente.
- Publica un registro DMARC y configura la generación de informes para supervisar la conformidad de la autenticación.
- En curso: Establecer un seguimiento continuo
- Realiza un seguimiento automático de los cambios en el historial, las fechas de caducidad de los certificados y el estado de las firmas DNSSEC.
¿No sabes cuál es tu situación? Prueba nuestro analizador de dominios para evaluar el estado de tu dominio.
Preguntas frecuentes
¿Cuál es la medida de seguridad más importante en materia de DNS?
La medida más importante es aplicar controles de acceso estrictos al registrador, incluyendo la autenticación multifactorial respaldada por hardware y los bloqueos del registrador o del registro. Si un atacante compromete tu cuenta de registrador, puede sustituir por completo tus servidores de nombres autoritativos, lo que dejaría inservibles todas las configuraciones de zona posteriores y las claves DNSSEC.
¿Cómo puedo saber si mi DNS ha sido secuestrado?
Entre los indicios de secuestro de DNS se incluyen caídas repentinas del tráfico de sitios web legítimos, errores inesperados relacionados con certificados SSL/TLS que se muestran a los usuarios, modificaciones no autorizadas en los registros de auditoría de tu registrador, devoluciones inexplicables de correos electrónicos o resolutores externos que devuelven direcciones IP desconocidas para tu dominio.
¿La seguridad del DNS solo es necesaria para las grandes empresas?
No. Los autores de amenazas suelen atacar a las pequeñas y medianas empresas porque, a menudo, los portales de sus registradores y sus zonas DNS no están supervisados. Los atacantes secuestran habitualmente los dominios de las pequeñas empresas para llevar a cabo campañas de phishing, alojar cadenas de redireccionamientos maliciosos y suplantar la identidad de directivos de las empresas.
¿DNSSEC cifra las consultas DNS?
No. El protocolo DNSSEC garantiza la integridad de los datos y la autenticación criptográfica del origen, lo que demuestra que un registro DNS recibido procede del propietario legítimo y no ha sido alterado durante el trayecto. No cifra las consultas DNS ni garantiza la confidencialidad. Para cifrar el tráfico de consultas se requieren protocolos de transporte como DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT).
¿Cuál es la diferencia entre la seguridad DNS autoritativa y la recursiva?
La seguridad del DNS autoritativo se centra en proteger los registros publicados de tu dominio, el tiempo de actividad de los servidores de nombres y los archivos de zona, para que los usuarios de todo el mundo reciban respuestas precisas sobre tus servicios. La seguridad del DNS recursivo se centra en proteger los dispositivos de los clientes de tu red para que no reciban respuestas manipuladas, en bloquear dominios maliciosos y en cifrar el tráfico hacia los resolutores externos.
¿Con qué frecuencia debería una organización auditar sus registros DNS?
Las organizaciones deben auditar los archivos de la zona pública al menos una vez al trimestre para eliminar los nombres de host retirados y los punteros sueltos. No obstante, la supervisión automatizada debe realizarse a diario para detectar en tiempo real modificaciones no autorizadas de los registros, cambios en los servidores de nombres o claves DNSSEC a punto de caducar.
¿Es seguro el servidor DNS 1.1.1.1?
Sí. El resolutor DNS público 1.1.1.1 de Cloudflare es seguro y es compatible con los protocolos de transporte cifrados más modernos, como DNS sobre HTTPS (DoH), DNS sobre TLS (DoT) y la validación DNSSEC. Además, aplica estrictas medidas de protección de la privacidad y se compromete a borrar los registros de consultas de los usuarios en un plazo de 24 horas.
¿La seguridad del DNS es lo mismo que una VPN?
No. Una VPN (red privada virtual) crea un túnel cifrado para todo el tráfico de red entre tu dispositivo y una red privada remota, ocultando tu dirección IP a los servidores de destino. La seguridad DNS protege específicamente la conversión de nombres de dominio en direcciones IP, garantizando que tus consultas sean auténticas, a prueba de manipulaciones y resistentes a la suplantación de identidad.
Palabras finales
La protección del Sistema de Nombres de Dominio (DNS) es un componente indispensable de las prácticas modernas de ciberseguridad. Si no se gestiona adecuadamente, el DNS crea una amplia superficie de ataque que permite a los atacantes eludir las defensas tradicionales de los terminales, los cortafuegos y las aplicaciones web.
Al aplicar de forma sistemática esta lista de comprobación de seguridad de 12 pasos, proteger tu cuenta de registrador, implementar DNSSEC y aplicar una autenticación estricta del correo electrónico, tu organización establece una defensa sólida contra el secuestro de tráfico, la suplantación de marca y las costosas interrupciones del servicio.