¿Está su organización protegida contra los ciberataques basados ​​en DNS?

Publicado: septiembre de 2021. Actualizado: agosto de 2026. Revisado por el equipo de asesoría de PKI de Encryption Consulting.

¿Qué son los ciberataques basados ​​en DNS y por qué son importantes?

Un ciberataque basado en DNS se dirige al Sistema de Nombres de Dominio (DNS), el protocolo que traduce un nombre de dominio legible para humanos, como www.example.com, a la dirección IP numérica a la que se conecta un navegador o una aplicación. La resolución DNS se realiza a través de una cadena de servidores: un resolvedor auxiliar en el dispositivo del usuario consulta a un resolvedor recursivo, que a su vez consulta a los servidores raíz, luego al servidor del dominio de nivel superior (TLD) correspondiente (.com, .org, etc.) y, finalmente, al servidor de nombres autoritativo del dominio, que almacena los registros reales. Cada salto en esa cadena se diseñó en la década de 1980 para la disponibilidad y la velocidad, no para la autenticación, por lo que nada en el protocolo original impide que una respuesta falsificada se acepte como auténtica.

Esa brecha es crucial porque la resolución DNS se produce antes que casi cualquier otra cosa en la red, antes del protocolo de enlace TLS, antes del inicio de sesión de una aplicación, antes de que se transmita un solo byte del tráfico previsto. Un atacante que controle o corrompa esa primera consulta puede redirigir silenciosamente a la víctima a una página de phishing, interceptar credenciales en tránsito, extraer datos eludiendo las reglas de salida del firewall disfrazados de consultas ordinarias, o dejar un servicio completamente fuera de servicio saturando los servidores DNS que se encuentran delante de él. Dado que el DNS se sitúa por debajo de casi todos los demás controles que implementa una organización, una capa DNS comprometida puede debilitar silenciosamente defensas que, en teoría, parecen sólidas.

¿Cuáles son los principales tipos de ataques basados ​​en DNS?

Los ataques basados ​​en DNS se dividen en cuatro familias operativamente distintas, cada una de las cuales explota un punto débil diferente en la cadena de resolución.

• Suplantación de DNS y envenenamiento de caché: Un atacante inyecta una respuesta DNS falsificada en la caché de un resolvedor para que las futuras consultas de un dominio devuelvan una dirección IP controlada por el atacante en lugar de la real. La técnica clásica, demostrada por primera vez a gran escala por el investigador de seguridad Dan Kaminsky en 2008, consiste en que un atacante externo se adelanta a las respuestas legítimas adivinando el ID de transacción de 16 bits y el puerto de origen de la consulta antes de que el servidor autoritativo real responda. Una vez infectado, cada cliente que utiliza ese resolvedor es redirigido silenciosamente hasta que la entrada de la caché caduca o se vacía. Para obtener una explicación más detallada de la mecánica de adivinación externa y las defensas de puerto de origen y codificación 0x20 que siguieron, consulte la guía dedicada de Encryption Consulting. Envenenamiento de caché DNS y ataques de jerarquía.
• Secuestro de DNS: En lugar de envenenar una caché, el atacante toma el control del lado autoritativo de la resolución, comprometiendo una cuenta de registrador, alterando los registros del servidor de nombres (NS) o explotando la configuración DNS de un enrutador vulnerable, de modo que el verdadero propietario del dominio ya no controla dónde se resuelve su propio nombre.
• Túnel DNS para exfiltración y comando y control (C2): Debido a que las consultas DNS atraviesan habitualmente los perímetros de red que bloquean casi todo lo demás, los atacantes codifican datos robados o instrucciones de comando y control (C2) dentro de los nombres de las consultas DNS y las respuestas de los registros TXT, utilizando el propio DNS como un canal de comunicación encubierto, lento y discreto que las reglas de salida de los cortafuegos tradicionales no inspeccionan.
• Amplificación de ataques DDoS e inundaciones NXDOMAIN: Un atacante envía una consulta DNS pequeña y falsificada que desencadena una respuesta mucho mayor, la cual se refleja en la dirección IP de la víctima, multiplicando así el ancho de banda del atacante. Una variante relacionada, el ataque NXDOMAIN o "inundación de DNS", bombardea un resolvedor autoritativo con consultas de subdominios aleatorios e inexistentes, agotando la capacidad del resolvedor en lugar del ancho de banda del origen, ya que cada consulta requiere una búsqueda aunque la respuesta sea "dominio no encontrado" (NXDOMAIN).

¿Qué protocolo de seguridad DNS debería implementar?

Ningún protocolo de seguridad DNS cubre todos los ataques mencionados anteriormente, ya que cada uno resuelve un problema diferente: integridad de la respuesta, privacidad de la consulta o vinculación del certificado. Tres estándares, combinados, cubren la mayor parte de la brecha: DNSSEC (Domain Name System Security Extensions), que firma criptográficamente los registros DNS para que un resolvedor pueda verificar que una respuesta no ha sido alterada (definido en RFC 4033 , RFC 4034 y RFC 4035 ); DoT (DNS over TLS), que cifra la consulta en sí dentro de una sesión TLS a través de un puerto dedicado ( RFC 7858 ); DoH (DNS over HTTPS), que transporta consultas cifradas dentro del tráfico HTTPS ordinario en el puerto 443 ( RFC 8484 ); y DANE (DNS-Based Authentication of Named Entities), que utiliza registros TLSA firmados por DNSSEC para fijar el certificado que un servicio debe presentar, como una verificación independiente junto con el modelo de confianza PKI web/CA pública ( RFC 6698 ).

Protocolo	Lo que protege	Lo que no protege	Mejor implementado cuando
DNSSEC	Integridad y autenticidad de las respuestas DNS; detecta suplantación de identidad y envenenamiento de caché.	Privacidad de la consulta; la consulta y la respuesta se siguen enviando sin cifrar.	Necesitas resolvedores para rechazar registros falsificados para cualquier dominio del que seas autoridad o que resuelvas en nombre de los usuarios.
DoT (DNS sobre TLS)	Confidencialidad de la consulta en tránsito, en un puerto dedicado y fácilmente identificable (853).	Autenticidad de la respuesta; un resolvedor DoT aún puede devolver un registro envenenado o manipulado si no está validando también DNSSEC.	Usted controla los puntos finales administrados o la salida de la red y desea que el tráfico DNS sea claramente separable para la monitorización empresarial.
DoH (DNS sobre HTTPS)	Confidencialidad de la consulta, integrada en el tráfico HTTPS habitual para una amplia compatibilidad con clientes y navegadores.	Autenticidad y visibilidad de la respuesta: DoH es intencionalmente difícil de distinguir de otro tráfico HTTPS.	Necesitas una amplia compatibilidad con clientes (navegadores, sistemas operativos móviles) y puedes dirigir a los clientes a un resolvedor DoH confiable y administrado por la empresa.
DANE (TLSA sobre DNSSEC)	¿Qué certificado TLS debe presentar un dominio, independientemente del modelo de confianza de la CA pública?	Nada por sí solo; DANE sin una zona firmada con DNSSEC puede ser suplantado.	Usted ejecuta servicios (especialmente entrega de correo SMTP, por RFC 7672) donde la sustitución de certificados es un riesgo real y DNSSEC ya está implementado.

¿Cuál es el modelo de amenaza que subyace a los ataques basados ​​en DNS?

Modelar el riesgo de DNS comienza con una distinción fundamental: ¿el atacante opera dentro o fuera de la ruta? Un atacante dentro de la ruta, que controla un punto de acceso Wi-Fi malicioso, un enrutador comprometido o un segmento de red por el que transita el tráfico de la víctima, puede ver y modificar directamente cada consulta y respuesta, lo que simplifica enormemente la suplantación de DNS sin necesidad de adivinar. Un atacante fuera de la ruta no tiene visibilidad del tráfico real y debe competir con la respuesta autorizada genuina, adivinando la combinación de ID de transacción y puerto de origen antes de que llegue la respuesta legítima, que es precisamente la técnica en la que se basa el envenenamiento de caché clásico.

Por encima de esa distinción se encuentra la propia cadena de resolución: el resolvedor stub, el resolvedor recursivo, el servidor TLD y el servidor de nombres autoritativo representan cada uno un límite de confianza independiente, y una vulneración en cualquier salto, una cuenta de registrador secuestrada, una caché recursiva envenenada, un registro autoritativo malicioso, se propaga a todos los clientes que dependen de ella. La implicación práctica es que el DNS debe tratarse como un transporte no confiable por defecto. Una respuesta es tan confiable como la cadena criptográfica (la cadena de confianza de DNSSEC desde la raíz hasta la zona firmada) que la respalda, no el hecho de que haya llegado al puerto 53 con un formato correcto. Esto refleja el marco de ataque activo versus pasivo más amplio que se aborda en la guía de Encryption Consulting sobre tipos de ataques de ciberseguridad , ya que un atacante DNS en la ruta está ejecutando, en la práctica, un ataque de intermediario contra la propia cadena de resolución.

¿Cómo se puede reforzar la infraestructura DNS frente a estos ataques?

1. Inventarie y evalúe las amenazas en su infraestructura DNS. Enumere todas las zonas autorizadas, cuentas de registrador y resolvedores de los que depende su organización, y luego determine qué tipo de ataque (suplantación de identidad, secuestro de sesión, tunelización, amplificación) es viable contra cada uno antes de elegir los controles.
2. Firma las zonas con DNSSEC y activa la validación. Habilite la firma DNSSEC en el lado autoritativo para cada zona de su propiedad y confirme que sus resolvedores recursivos validen realmente las firmas (active el bit DNSSEC OK / AD) en lugar de simplemente pasar los registros firmados sin marcar.
3. Trasladar el transporte de consultas al Departamento de Transporte (DoT) o al Departamento de Salud (DoH), donde la privacidad es importante. Para los puntos finales administrados y los resolvedores internos, el puerto dedicado de DoT facilita la identificación y el monitoreo del tráfico DNS cifrado; para los navegadores y los clientes no administrados, DoH ofrece una compatibilidad más amplia, siempre que los clientes estén configurados para usar un resolvedor en el que su organización realmente confíe y que pueda registrar la actividad.
4. Publique los registros DANE TLSA para los servicios que se encuentren fuera de la ruta estándar de la infraestructura de clave pública web (Web PKI). La entrega de correo SMTP, en particular, se beneficia de DANE, ya que rara vez está protegida por la validación de certificados al estilo del navegador.
5. Limitar la velocidad y aumentar la capacidad para protegerse contra la amplificación y las inundaciones de NXDOMAIN. Implemente la limitación de la tasa de respuesta, la capacidad del resolvedor anycast y el filtrado de direcciones de origen al estilo BCP 38, de modo que las consultas pequeñas falsificadas no puedan convertirse en grandes inundaciones contra un tercero o sus propios resolvedores.
6. Vigile los indicadores de túneles. Esté atento a un volumen de consultas anormal, subdominios inusualmente largos o de alta entropía, y picos en las consultas de registros TXT, todas ellas señales comunes de que se está utilizando la tunelización DNS para la exfiltración o el comando y control (C2).
7. Controla las claves que subyacen a todo esto. Todos los controles anteriores dependen de que las claves de firma DNSSEC se generen, roten y almacenen correctamente; trate la gestión de la clave de firma de zona (ZSK) y la clave de firma de clave (KSK) como una parte fundamental del programa, no como algo secundario.

¿Cuáles son las ventajas y desventajas en cuanto a rendimiento e interoperabilidad de DNSSEC, DoH y DoT?

DNSSEC añade firmas criptográficas a las respuestas DNS, lo que suele hacer que estas superen el límite original de 512 bytes de UDP, requiriendo compatibilidad con EDNS0 o un recurso alternativo TCP, e incrementa el trabajo de la CPU para la validación de firmas en el servidor DNS. El mayor riesgo operativo no reside en la velocidad, sino en la disponibilidad: una firma mal configurada o caducada provoca que una zona firmada falle y se cierre , dejando el dominio completamente irresoluble para los servidores DNS que intentan validarlo, en lugar de simplemente inseguro. Este modo de fallo es más seguro frente a los atacantes, pero mucho menos tolerante para los equipos de operaciones que el DNS simple sin firmar.

DoT requiere una conexión TLS dedicada en el puerto 853, lo que significa un intercambio de claves adicional a menos que se haya implementado la reanudación de sesión, y ese mismo puerto dedicado facilita que las redes restrictivas (y las herramientas de seguridad empresarial) lo identifiquen y, si se desea, lo bloqueen. DoH deliberadamente va en la dirección opuesta: al usar el puerto HTTPS estándar 443, se mezcla con el tráfico web ordinario, lo que maximiza la compatibilidad y el alcance del cliente, pero hace que el tráfico DoH sea difícil de distinguir para las herramientas de seguridad perimetral de cualquier otra conexión HTTPS, un costo real de interoperabilidad para las empresas que dependen de la visibilidad de la capa DNS para la monitorización de la seguridad. Ni DoH ni DoT reemplazan a DNSSEC, ya que cifrar la consulta en tránsito no dice nada sobre si la respuesta que contiene fue falsificada; la guía del NIST sobre la implementación segura de DNS ( NIST SP 800-81 Rev. 3 ) y la guía de protección de DNS de CISA tratan el transporte cifrado y la validación DNSSEC como capas complementarias, no sustitutas entre sí.

¿Qué dependencias de gestión de claves introduce DNSSEC?

La seguridad de DNSSEC se basa completamente en dos pares de claves por zona, cada uno con un ritmo de rotación y un alcance diferentes. La clave de firma de zona (ZSK) firma los registros de recursos reales de la zona y está diseñada para rotarse con relativa frecuencia (generalmente cada pocos meses), ya que reemplazarla solo requiere volver a firmar la zona misma. La clave de firma de clave (KSK) firma el conjunto de registros DNSKEY que contiene la ZSK, y su contraparte pública debe publicarse como un registro DS (Delegation Signer) en la zona principal, lo que significa que una renovación de KSK requiere una acción coordinada del operador o registrador de la zona principal, no solo del propietario del dominio. Esta dependencia hace que las renovaciones de KSK sean mucho más riesgosas operativamente: la renovación de KSK de la zona raíz de 2018 fue retrasada por la ICANN específicamente porque la telemetría mostró que una parte significativa de los resolvedores aún no habían adoptado la nueva clave, y renovarla según lo programado corría el riesgo de romper la validación para esos resolvedores.

Dado que una vulnerabilidad en la clave KSK o una gestión incorrecta de la rotación pueden dejar un dominio firmado completo fuera de servicio para todos los resolvedores validadores en Internet, la custodia de las claves DNSSEC merece el mismo rigor que la custodia de la clave raíz de la autoridad de certificación: generación y almacenamiento en un módulo de seguridad de hardware (HSM), procedimientos de rotación documentados y probados antes de que sean necesarios, y una propiedad clara en lugar de la suposición implícita de que la configuración predeterminada de un host DNS es suficiente.

¿Cómo son en la práctica los ejemplos de implementación de DNSSEC y DANE?

• Zona autoritativa firmada con resolutores validadores: Una empresa habilita la firma DNSSEC en sus zonas autoritativas a través de su proveedor de alojamiento DNS, publica el registro DS resultante con su registrador y confirma por separado que los resolvedores recursivos que utilizan sus propios empleados y servicios validan realmente las firmas, ya que firmar una zona protege a los visitantes de la misma, pero la validación protege a los propios usuarios de una organización de respuestas falsificadas en otros lugares de Internet.
• DANE para la entrega de correo SMTP: Según la RFC 7672, un administrador de correo publica registros TLSA para cada nombre de host de intercambio de correo (MX) en una zona firmada con DNSSEC, de modo que los servidores de correo receptores puedan verificar el certificado exacto que debe presentar un servidor remitente, cerrando así una vía de degradación e interceptación que el modelo de CA pública por sí solo deja abierta para la entrega de correo de servidor a servidor.
• Perfil de resolución del Departamento de Salud gestionado por la empresa: En lugar de permitir que cada navegador utilice por defecto su propio resolvedor DoH público (lo que eludiría por completo el filtrado de seguridad DNS corporativo), una organización configura una política de grupo o un perfil MDM que dirige los navegadores administrados a un resolvedor DoH específico y de confianza para la empresa, preservando así la privacidad de las consultas cifradas y la visibilidad centralizada.

¿Qué defensa detiene cada tipo de ataque DNS?

Utilice esta tabla como lista de verificación inicial. En entornos reales, se superponen varias filas a la vez en lugar de seleccionar un control por ataque.

Tipo de ataque	Mecanismo	Defensa primaria
Suplantación de DNS / envenenamiento de caché	Un atacante externo adivina el ID de la transacción y el puerto de origen para inyectar un registro falsificado antes de que llegue la respuesta real.	Validación DNSSEC; aleatorización del puerto de origen y del ID de consulta.
Secuestro de DNS	El atacante compromete una cuenta de registrador o altera los registros NS/autoritativos para redirigir la resolución en el origen.	Autenticación multifactor del registrador y bloqueo del registro; zona firmada con DNSSEC; monitorización de cambios inesperados en NS/registros.
Túnel DNS (exfiltración / C2)	El atacante codifica datos o comandos dentro de los nombres de las consultas DNS y las respuestas TXT para eludir las reglas de salida del firewall.	Monitorización de la longitud de las consultas y la entropía; filtrado de protección DNS/cortafuegos DNS; restricción de tipos de registros poco comunes en la salida.
Amplificación de ataques DDoS / inundación de NXDOMAIN	Una pequeña consulta falsificada desencadena una gran respuesta reflejada, o bien, las inundaciones de subdominios aleatorios agotan la capacidad del resolvedor.	Limitación de la tasa de respuesta; capacidad anycast; filtrado de direcciones de origen BCP 38; almacenamiento en caché del resolvedor y ajuste de capacidad.

Limitaciones

• DNSSEC protege la integridad de la respuesta, no la confidencialidad de la pregunta; un observador pasivo en la red aún puede ver qué dominios se resuelven incluso a través de una consulta totalmente firmada y validada.
• DoH y DoT protegen la consulta en tránsito, pero no hacen nada para evitar que una zona autoritativa sea manipulada, envenenada o secuestrada en la red; esa brecha es responsabilidad de DNSSEC, no de ellos.
• DANE solo funciona si la zona que publica el registro TLSA está firmada con DNSSEC; DANE aplicado a una zona sin firmar puede ser falsificado y no proporciona ninguna protección real.
• El diseño de DNSSEC, que permite el cierre en caso de fallo, es más seguro contra los atacantes, pero menos tolerante a nivel operativo; una firma caducada o una cadena de confianza rota pueden hacer que un dominio sea completamente inaccesible, en lugar de simplemente inseguro.
• El cifrado de DNS a un resolvedor público puede eludir por completo los controles de seguridad DNS empresariales si los puntos finales no están configurados centralmente para usar un resolvedor de confianza, lo que crea un punto ciego de monitorización en lugar de solucionarlo.
• Ninguno de estos protocolos detiene el phishing a nivel de aplicación, que simplemente registra un dominio de apariencia similar en lugar de atacar la resolución DNS en sí; ese riesgo requiere controles separados de monitoreo de dominio y de concientización del usuario.

¿Qué recomendaría Encryption Consulting?

Gestionar las claves DNSSEC con la misma rigurosidad que la custodia de las claves raíz de la autoridad de certificación, ya que desde el punto de vista operativo se trata del mismo problema: un pequeño número de claves criptográficas de larga duración que, si se pierden, se ven comprometidas o se gestionan incorrectamente durante la rotación, pueden comprometer la confianza en todo un dominio, en lugar de solo debilitarla. Normalmente, recomendamos comenzar con una evaluación de la infraestructura de clave pública (PKI) para determinar quién es el responsable de la generación, rotación y transferencia de claves DNSSEC, ya que en la mayoría de las organizaciones la respuesta es «quien configuró los valores predeterminados del servidor DNS», no un proceso controlado. A partir de ahí, las claves privadas ZSK y KSK se benefician de la misma custodia respaldada por HSM que Encryption Consulting recomienda para las claves raíz de la CA, disponible a través de HSM como servicio en lugar del almacenamiento de claves exclusivamente por software en el proveedor de DNS.

Para las organizaciones que ya utilizan la automatización del ciclo de vida de los certificados mediante PKI como servicio , extender esa misma disciplina de gobernanza, con sus calendarios de rotación definidos, el registro de auditoría y la separación de roles, a los registros DNSSEC y DANE TLSA, subsana una deficiencia que la gestión del ciclo de vida de los certificados por sí sola no cubre: un certificado emitido válidamente no protege si un atacante puede secuestrar el registro DNS que apunta a él. Cuando los ataques basados ​​en DNS son un síntoma de una deficiencia más amplia, en lugar de una preocupación aislada, un servicio de asesoramiento sobre cifrado es el punto de partida adecuado para analizar el riesgo de DNS junto con el resto del entorno criptográfico.

Conclusión

Los ciberataques basados ​​en DNS tienen éxito porque el protocolo subyacente a casi todas las conexiones a internet nunca se diseñó para autenticar sus propias respuestas. La suplantación de identidad, el envenenamiento de caché, el secuestro de DNS, la tunelización y las inundaciones de amplificación explotan diferentes puntos de la cadena de resolución, razón por la cual ninguna solución por sí sola resuelve el problema. DNSSEC autentica las respuestas, DoH y DoT protegen la privacidad de la consulta, y DANE fija certificados independientemente del modelo de CA pública, pero cada una de estas protecciones depende de la eficacia con la que se generan, rotan y gestionan las claves subyacentes, sobre todo la Clave de Firma de Zona y la Clave de Firma de Clave de DNSSEC. Las organizaciones que se toman la gestión de claves DNS tan en serio como la custodia de claves de la autoridad de certificación solucionan el mayor problema descrito en este artículo; aquellas que lo dejan a la configuración predeterminada del servidor DNS suelen descubrirlo solo después de que un atacante ya lo haya encontrado.

Preguntas Frecuentes

¿Es suficiente DNSSEC para proteger el DNS de mi organización? No. DNSSEC protege la integridad y autenticidad de las respuestas DNS, evitando la suplantación de identidad y el envenenamiento de caché, pero no cifra la consulta en sí, no impide el túnel DNS ni protege contra ataques DDoS de amplificación. Considérenlo como una capa necesaria entre varias, no como un programa completo de seguridad DNS por sí solo.

¿Cuál es la diferencia real entre DoH y DoT? Ambos cifran las consultas DNS, pero DoT (RFC 7858) utiliza una conexión TLS dedicada en el puerto 853, lo que facilita la identificación y el monitoreo del tráfico DNS cifrado en el borde de la red, mientras que DoH (RFC 8484) canaliza las consultas dentro del protocolo HTTPS estándar en el puerto 443, integrándose con el tráfico web normal para brindar mayor soporte al cliente a costa de la visibilidad empresarial.

¿Es posible que el túnel DNS logre sortear un cortafuegos? Sí. Dado que las consultas DNS prácticamente siempre pueden cruzar los perímetros de la red, los atacantes codifican datos robados o instrucciones de comando y control dentro de los nombres de las consultas y las respuestas de los registros TXT, eludiendo las reglas de salida que bloquean casi todos los demás protocolos. Para detectarlo, es necesario monitorizar el volumen, la longitud y la entropía de las consultas, no solo bloquear los puertos.

¿Necesito DANE si ya uso DNSSEC y una autoridad de certificación pública? DANE añade una comprobación independiente, respaldada por DNSSEC, sobre qué certificado TLS debe presentar un dominio, lo cual es fundamental para servicios como el envío de correo SMTP, que carecen de validación de certificados al estilo del navegador. No es obligatorio en todos los lugares donde se implementa DNSSEC, pero cubre una importante deficiencia en los protocolos de servidor a servidor que el modelo de CA pública/PKI web no abarca por completo.

¿Con qué frecuencia se deben rotar las claves DNSSEC? La clave de firma de zona (ZSK) se suele rotar cada pocos meses, ya que volver a firmar la zona conlleva poco riesgo, mientras que la clave de firma de clave (KSK) se rota con mucha menos frecuencia, a menudo anualmente o incluso con menos frecuencia, porque requiere publicar un nuevo registro DS con la zona principal o el registrador y confirmar que los resolvedores validadores hayan detectado el cambio antes de que se retire la clave antigua.

Referencias

• RFC 4033, Introducción y requisitos de seguridad DNS: https://www.rfc-editor.org/rfc/rfc4033
• RFC 4034, Registros de recursos para las extensiones de seguridad DNS: https://www.rfc-editor.org/rfc/rfc4034.html
• RFC 4035, Modificaciones del protocolo para las extensiones de seguridad DNS: https://www.rfc-editor.org/rfc/rfc4035
• RFC 7858, Especificación para DNS sobre seguridad de la capa de transporte (TLS): https://www.rfc-editor.org/rfc/rfc7858
• RFC 8484, Consultas DNS sobre HTTPS (DoH): https://www.rfc-editor.org/rfc/rfc8484.html
• RFC 6698, Autenticación basada en DNS de entidades nombradas (DANE) Protocolo TLS: TLSA: https://www.rfc-editor.org/rfc/rfc6698.html
• RFC 7672, Seguridad SMTP mediante DANE TLS oportunista: https://www.rfc-editor.org/rfc/rfc7672
• Guía de implementación del Sistema de nombres de dominio (DNS) seguro NIST SP 800-81 Rev. 3: https://csrc.nist.gov/pubs/sp/800/81/r3/final
• CISA, sistema de resolución de nombres de dominio (DNS) de protección: https://www.cisa.gov/resources-tools/services/protective-domain-name-system-dns-resolver
• Akamai, ¿Qué es NXDOMAIN DDoS? (Ataque de tortura DNS): https://www.akamai.com/glossary/what-is-nxdomain-ddos