Información general sobre DNSSEC (vista previa)
Este artículo proporciona información general sobre las Extensiones de seguridad del sistema de nombres de dominio (DNSSEC) e incluye una introducción a la terminología de DNSSEC. Se describen las ventajas de la firma de zona DNSSEC y se ofrecen ejemplos para visualizar registros de recursos relacionados con DNSSEC. Cuando esté listo para firmar su zona DNS pública de Azure, consulte las siguientes guías prácticas:
- Cómo firmar la zona DNS pública de Azure con DNSSEC (versión preliminar).
- Cómo anular la firma de la zona DNS pública de Azure (versión preliminar)
Nota:
La firma de zonas DNSSEC está actualmente en VERSIÓN PRELIMINAR.
Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
¿Qué es DNSSEC?
DNSSEC es un conjunto de extensiones que aportan seguridad al protocolo del Sistema de Nombres de Dominio (DNS) al permitir que las respuestas DNS sean validadas como auténticas. DNSSEC proporciona entidad de origen, integridad de datos y denegación de existencia autenticada. Con DNSSEC, el protocolo DNS es mucho menos susceptible a determinados tipos de ataque, especialmente ataques de suplantación de identidad de DNS.
Las principales extensiones DNSSEC se especifican en las siguientes Solicitudes de Comentarios (RFC):
- RFC 4033: "Introducción a la seguridad de DNS y requisitos"
- RFC 4034: "Registros de recursos para las extensiones de seguridad de DNS"
- RFC 4035: "Modificaciones del protocolo para las extensiones de seguridad de DNS"
Para obtener un resumen de las RFC de DNSSEC, consulte RFC9364: Extensiones de seguridad de DNS (DNSSEC).
Cómo funciona DNSSEC
Las zonas DNS se protegen con DNSSEC mediante un proceso denominado firma de zona. Firmar una zona con DNSSEC aporta soporte de validación sin cambiar el mecanismo básico de una consulta y respuesta DNS. Para firmar una zona con DNSSEC, el servidor DNS autoritativo principal de la zona debe admitir DNSSEC.
Las firmas de registros de recursos (RRSIG) y otros registros criptográficos se agregan a la zona cuando está firmada. En la siguiente ilustración se muestran los registros de recursos DNS en la zona contoso.com antes y después de la firma de zona.
La validación DNSSEC de las respuestas DNS se produce mediante el uso de estas firmas digitales con una cadena de confianza ininterrumpida.
Nota:
Los registros de recursos relacionados con DNSSEC no se muestran en Azure Portal. Para obtener más información, consulte Ver registros de recursos relacionados con DNSSEC.
¿Por qué firmar una zona con DNSSEC?
La firma de una zona con DNSSEC es necesaria para cumplir algunas directrices de seguridad, como la SC-20: Servicio seguro de resolución de nombres y direcciones.
La validación DNSSEC de las respuestas DNS puede prevenir tipos comunes de ataques de secuestro DNS, también conocidos como redireccionamiento DNS. El secuestro de DNS se produce cuando un dispositivo cliente es redirigido a un servidor malicioso mediante el uso de respuestas DNS incorrectas (suplantadas). El envenenamiento de la caché DNS es un método común utilizado para falsear las respuestas DNS.
En la siguiente figura se muestra un ejemplo de cómo funciona el secuestro de DNS.
Resolución DNS normal:
- Un dispositivo cliente envía una consulta DNS para contoso.com a un servidor DNS.
- El servidor DNS responde con un registro de recursos DNS para contoso.com.
- El dispositivo cliente solicita una respuesta de contoso.com.
- La aplicación contoso.com o el servidor web devuelve una respuesta al cliente.
Secuestro de DNS
- Un dispositivo cliente envía una consulta DNS para contoso.com a un servidor DNS secuestrado.
- El servidor DNS responde con un registro de recursos DNS no válido (suplantado) para contoso.com.
- El dispositivo cliente solicita una respuesta para contoso.com al servidor malicioso.
- El servidor malicioso devuelve una respuesta falsa al cliente.
El tipo de registro de recursos DNS que se falsifica depende del tipo de ataque de secuestro DNS. Un registro MX podría ser suplantado para redirigir los correos electrónicos de los clientes, o un registro A suplantado podría enviar a los clientes a un servidor web malicioso.
DNSSEC evita el secuestro de DNS mediante la validación de las respuestas DNS. En el escenario de secuestro de DNS ilustrado aquí, el dispositivo cliente puede rechazar respuestas DNS no validadas si el dominio contoso.com está firmado con DNSSEC. Para rechazar respuestas DNS no validadas, el dispositivo cliente debe aplicar la validación DNSSEC para contoso.com.
DNSSEC también incluye Next Secure 3 (NSEC3) para evitar la enumeración de zonas. La enumeración de zonas, también conocida como recorrido de zonas, es un ataque mediante el cual el atacante establece una lista de todos los nombres de una zona, incluidas las zonas secundarias.
Antes de firmar una zona con DNSSEC, asegúrese de comprender cómo funciona DNSSEC. Cuando esté listo para firmar una zona, consulte Cómo firmar su zona de DNS público de Azure con DNSSEC.
Validación de DNSSEC
Si un servidor DNS es compatible con DNSSEC, puede establecer el indicador DNSSEC OK (DO) en una consulta DNS con un valor de 1
. Este valor indica al servidor DNS de respuesta que incluya registros de recursos relacionados con DNSSEC con la respuesta. Estos registros DNSSEC son registros de firma de registro de recursos (RRSIG) que se utilizan para validar que la respuesta DNS es auténtica.
Un servidor DNS recursivo (no autoritativo) realiza la validación DNSSEC en registros RRSIG utilizando un anclaje de confianza (DNSKEY). El servidor utiliza una DNSKEY para descifrar las firmas digitales de los registros RRSIG (y otros registros relacionados con DNSSEC), luego calcula y compara los valores hash. Si los valores hash coinciden, proporciona una respuesta al cliente DNS con los datos DNS que solicitó, como un registro de dirección de host (A). Observe el diagrama siguiente:
Si los valores hash no coinciden, el servidor DNS recursivo responde con un mensaje SERVFAIL. De este modo, los servidores DNS de resolución (o reenvío) con capacidad DNSSEC con un anclaje de confianza válido instalado pueden proteger contra el secuestro de DNS en la ruta entre el servidor recursivo y el servidor autoritativo. Esta protección no requiere que los dispositivos cliente DNS sean compatibles con DNSSEC o que apliquen la validación de respuesta DNS, siempre que el servidor DNS recursivo local (último salto) esté protegido contra el secuestro.
Los dispositivos cliente de Windows 10 y Windows 11 son solucionadores de código auxiliar no validadores conscientes de la seguridad. Estos dispositivos cliente no realizan la validación, pero pueden imponer la validación DNSSEC mediante la directiva de grupo. El NRPT puede utilizarse para crear y aplicar una directiva de validación de DNSSEC basada en el espacio de nombres.
Anclajes de confianza y validación DNSSEC
Nota:
La validación de la respuesta DNSSEC no la realiza el resolver predeterminado proporcionado por Azure. La información de esta sección es útil si está configurando sus propios servidores DNS recursivos para la validación de DNSSEC o para solucionar problemas de validación.
Los anclajes de confianza funcionan en base a la jerarquía del espacio de nombres DNS. Un servidor DNS recursivo puede tener cualquier número de anclajes de confianza, o no tener ninguno. Se pueden agregar anclajes de confianza para una única zona DNS hija o para cualquier zona principal. Si un servidor DNS recursivo tiene un anclaje de confianza raíz (.), puede realizar la validación DNSSEC en cualquier zona DNS. Para obtener más información, consulte Información del operador de zona raíz.
El proceso de validación DNSSEC funciona con anclajes de confianza como se muestra a continuación:
- Si un servidor DNS recursivo no tiene un anclaje de confianza DNSSEC para una zona o el espacio de nombres jerárquico principal de la zona, no realizará la validación DNSSEC en esa zona.
- Si un servidor DNS recursivo tiene un anclaje de confianza DNSSEC para el espacio de nombres principal de una zona y recibe una consulta para la zona secundaria, comprueba si hay un registro DS para las zonas secundarias en la zona principal.
- Si se encuentra el registro DS, el servidor DNS recursivo realiza la validación DNSSEC.
- Si el servidor DNS recursivo determina que la zona padre no tiene un registro DS para la zona secundaria, asume que la zona secundaria es insegura y no realiza la validación DNSSEC.
- Si hay varios servidores DNS recursivos implicados en una respuesta DNS (incluidos los reenviadores), cada servidor debe poder realizar la validación DNSSEC de la respuesta para que haya una cadena de confianza ininterrumpida.
- Los servidores recursivos que tienen deshabilitada la validación DNSSEC o no son compatibles con DNSSEC no realizan la validación.
Cadena de confianza
Se produce una cadena de confianza cuando todos los servidores DNS implicados en el envío de una respuesta para una consulta DNS son capaces de validar que la respuesta no se modificó durante el tránsito. Para que la validación DNSSEC funcione de extremo a extremo, la cadena de confianza debe estar intacta. Esta cadena de confianza se aplica tanto a los servidores autorizados como a los no autorizados (recursivos).
Servidores autorizados
Los servidores DNS autoritativos mantienen una cadena de confianza mediante el uso de registros de firmante de delegación (DS). Los registros DS se utilizan para verificar la autenticidad de las zonas secundarias en la jerarquía DNS.
- Para que se produzca la validación DNSSEC en una zona firmada, el elemento principal de la zona firmada también debe estar firmado. La zona principal también debe tener un registro DS para la zona secundaria.
- Durante el proceso de validación, se consulta el registro DS del padre de una zona. Si el registro DS no está presente, o los datos del registro DS en la zona principal no coinciden con los datos DNSKEY en la zona secundaria, la cadena de confianza se rompe y la validación falla.
Servidores recursivos
Los servidores DNS recursivos (también llamados servidores DNS de resolución o almacenamiento en caché) mantienen una cadena de confianza mediante el uso de anclas de confianza DNSSEC.
- El anclaje de confianza es un registro DNSKEY, o un registro DS que contiene un hash de un registro DNSKEY. El registro DNSKEY se crea en un servidor autoritativo cuando una zona está firmada, y se elimina de la zona si ésta no está firmada.
- Los anclajes de confianza deben instalarse de forma manual en los servidores DNS recursivos.
- Si existe un anclaje de confianza para una zona principal, un servidor recursivo puede validar todas las zonas secundarias del espacio de nombres jerárquico. Esto incluye las consultas reenviadas. Para admitir la validación DNSSEC de todas las zonas DNS firmadas por DNSSEC, puede instalar un anclaje de confianza para la zona raíz (.).
Sustitución de claves
La clave de firma de zona (ZSK) de una zona firmada con DNSSEC es renovada (reemplazada) periódicamente de forma automática por Azure. No debería ser necesario reemplazar su clave de firma de claves (KSK), pero esta opción está disponible poniéndose en contacto con el soporte de Microsoft. El reemplazo de la KSK requiere que también actualice su registro DS en la zona principal.
Algoritmo de firma por zonas
Las zonas están firmadas DNSSEC utilizando el Algoritmo de Firma Digital de Curva Elíptica (ECDSAP256SHA256).
Registros de recursos relacionados con DNSSEC
La siguiente tabla ofrece una breve descripción de los registros relacionados con DNSSEC. Para obtener información más detallada, consulte RFC 4034: Registros de recursos para las extensiones de seguridad del DNS y RFC 7344: Automatización del mantenimiento de la confianza de delegación DNSSEC.
Grabar | Descripción |
---|---|
Firma de registro de recursos (RRSIG) | Un tipo de registro de recurso DNSSEC que se utiliza para contener una firma, que cubre un conjunto de registros DNS para un nombre y tipo concretos. |
DNSKEY | Un tipo de registro de recurso DNSSEC que se utiliza para almacenar una clave pública. |
Firmante de la delegación (DS) | Un tipo de registro de recurso DNSSEC que se utiliza para proteger una delegación. |
Siguiente seguro (NSEC) | Tipo de registro de recurso DNSSEC que se utiliza para demostrar la no existencia de un nombre DNS. |
Siguiente seguro 3 (NSEC3) | El registro de recursos NSEC3 que proporciona una denegación de existencia autenticada y con hash para los conjuntos de registros de recursos DNS. |
Siguiente parámetros de seguridad 3 (NSEC3PARAM) | Especifica los parámetros para los registros NSEC3. |
Delegación secundaria firmante (CDS) | Este registro es opcional. Si está presente, el registro CDS puede ser utilizado por una zona secundaria para especificar el contenido deseado del registro DS en una zona principal. |
DNSKEY secundario (CDNSKEY) | Este registro es opcional. Si el registro CDNSKEY está presente en una zona secundaria, puede utilizarse para generar un registro DS a partir de un registro DNSKEY. |
Ver registros de recursos relacionados con DNSSEC
Los registros relacionados con DNSSEC no se muestran en Azure Portal. Para ver los registros relacionados con DNSSEC, utilice herramientas de línea de comandos como Resolve-DnsName o dig.exe. Estas herramientas están disponibles utilizando Cloud Shell, o de forma local si están instaladas en su dispositivo. Asegúrese de establecer la bandera DO en su consulta utilizando la opción -dnssecok
en Resolve-DnsName o la opción +dnssec
en dig.exe.
Importante
No utilice la herramienta de línea de comandos nslookup.exe para buscar registros relacionados con DNSSEC. La herramienta nslookup.exe utiliza un cliente DNS interno que no es compatible con DNSSEC.
Consulte los siguientes ejemplos:
PS C:\> resolve-dnsname server1.contoso.com -dnssecok
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
server1.contoso.com A 3600 Answer 203.0.113.1
Name : server1.contoso.com
QueryType : RRSIG
TTL : 3600
Section : Answer
TypeCovered : A
Algorithm : 13
LabelCount : 3
OriginalTtl : 3600
Expiration : 9/20/2024 11:25:54 PM
Signed : 9/18/2024 9:25:54 PM
Signer : contoso.com
Signature : {193, 20, 122, 196…}
C:\>dig server1.contoso.com +dnssec
; <<>> DiG 9.9.2-P1 <<>> server1.contoso.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61065
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;server1.contoso.com. IN A
;; ANSWER SECTION:
server1.contoso.com. 3600 IN A 203.0.113.1
server1.contoso.com. 3600 IN RRSIG A 13 3 3600 20240920232359 20240918212359 11530 contoso.com. GmxeQhNk1nJZiep7nuCS2qmOQ+Ffs78Z2eoOgIYP3j417yqwS1DasfA5 e1UZ4HuujDk2G6GIbs0ji3RiM9ZpGQ==
;; Query time: 153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 15:23:45 2024
;; MSG SIZE rcvd: 179
PS C:\> resolve-dnsname contoso.com -Type dnskey -dnssecok
Name Type TTL Section Flags Protocol Algorithm Key
---- ---- --- ------- ----- -------- --------- ---
contoso.com DNSKEY 3600 Answer 256 DNSSEC 13 {115, 117, 214,
165…}
contoso.com DNSKEY 3600 Answer 256 DNSSEC 13 {149, 166, 55, 78…}
contoso.com DNSKEY 3600 Answer 257 DNSSEC 13 {45, 176, 217, 2…}
Name : contoso.com
QueryType : RRSIG
TTL : 3600
Section : Answer
TypeCovered : DNSKEY
Algorithm : 13
LabelCount : 2
OriginalTtl : 3600
Expiration : 11/17/2024 9:00:15 PM
Signed : 9/18/2024 9:00:15 PM
Signer : contoso.com
Signature : {241, 147, 134, 121…}
C:\>dig contoso.com dnskey
; <<>> DiG 9.9.2-P1 <<>> contoso.com dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46254
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;contoso.com. IN DNSKEY
;; ANSWER SECTION:
contoso.com. 3600 IN DNSKEY 256 3 13 laY3Toc/VTyjupgp/+WgD05N+euB6Qe1iaM/253k7bkaA0Dx+gSDhbH2 5wXTt+uLQgPljL9OusKTneLdhU+1iA==
contoso.com. 3600 IN DNSKEY 257 3 13 LbDZAtjG8E9Ftih+LC8CqQrSZIJFFJMtP6hmN3qBRqLbtAj4JWtr2cVE ufXM5Pd/yW+Ca36augQDucd5n4SgTg==
contoso.com. 3600 IN DNSKEY 256 3 13 c3XWpTqZ0q9IO+YqMEtOBHZSzGGeyFKq0+3xzs6tifvD1rey1Obhrkz4 DJlEIxy2m84VsG1Ij9VYdtGxxeVHIQ==
;; Query time: 182 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 16:35:10 2024
;; MSG SIZE rcvd: 284
Terminología DNSSEC
Esta lista se proporciona para ayudar a entender algunos de los términos comunes utilizados cuando se habla de DNSSEC. Consulte también: Registros de recursos relacionados con DNSSEC
Término | Descripción |
---|---|
Bit de datos autentificados (AD) | Bit de datos que indica en una respuesta que todos los datos incluidos en las secciones de respuesta y autoridad de la respuesta han sido autenticados por el servidor DNS de acuerdo con las directivas de dicho servidor. |
Cadena de autenticación | Una cadena de registros DNS firmados y validados que se extiende desde un anclaje de confianza preconfigurado hasta alguna zona secundaria en el árbol DNS. |
Extensión DNS (EDNS0) | Registro DNS que contiene información ampliada del encabezado DNS, como el bit DO y el tamaño máximo del paquete UDP. |
Extensiones de seguridad DNS (DNSSEC) | Extensiones del servicio DNS que proporcionan mecanismos para firmar y resolver de forma segura los datos DNS. |
Bit DNSSEC OK (DO) | Un bit en la parte EDNS0 de una solicitud DNS que indica que el cliente es compatible con DNSSEC. |
Validación de DNSSEC | La validación DNSSEC es el proceso de verificación del origen y la integridad de los datos DNS mediante claves criptográficas públicas. |
Isla de seguridad | Una zona firmada que no tiene una cadena de autenticación de su zona principal delegada. |
Clave de firma de clave (KSK) | Clave de autenticación que corresponde a una clave privada que se utiliza para firmar una o varias claves de firma de una zona determinada. Normalmente, la clave privada que corresponde a una KSK firma una clave de firma de zona (ZSK), que a su vez tiene una clave privada correspondiente que firma otros datos de zona. La directiva local puede exigir que la ZSK se cambie con frecuencia, mientras que la KSK puede tener un periodo de validez más largo para ofrecer un punto de entrada a la zona más estable y seguro. Designar una clave de autenticación como KSK es una cuestión puramente operativa: la validación DNSSEC no distingue entre KSKs y otras claves de autenticación DNSSEC. Es posible utilizar una misma clave como KSK y como ZSK. |
Resolución de código auxiliar no validada con seguridad | Un solucionador de código auxiliar consciente de la seguridad que confía en uno o más servidores DNS conscientes de la seguridad para realizar la validación DNSSEC en su nombre. |
clave de punto de entrada seguro (SEP) | Un subconjunto de claves públicas dentro del DNSKEY RRSet. Una clave SEP se utiliza para generar un DS RR o se distribuye a los solucionadores que utilizan la clave como anclaje de confianza. |
Servidor DNS compatible con la seguridad | Un servidor DNS que implementa las extensiones de seguridad DNS definidas en los RFCs 4033 [5], 4034 [6] y 4035 [7]. En particular, un servidor DNS consciente de la seguridad es una entidad que recibe consultas DNS, envía respuestas DNS, admite la extensión de tamaño de mensaje EDNS0 [3] y el bit DO, y admite los tipos de registro DNSSEC y los bits de encabezado de mensaje. |
Zona firmada | Una zona cuyos registros están firmados tal y como se define en RFC 4035 [7] Sección 2. Una zona firmada puede contener registros de recursos DNSKEY, NSEC, NSEC3, NSEC3PARAM, RRSIG y DS. Estos registros de recursos permiten que los solucionadores validen los datos DNS. |
Anclaje de confianza | Una clave pública preconfigurada que está asociada a una zona determinada. Un anclaje de confianza permite a un solucionador DNS validar registros de recursos DNSSEC firmados para esa zona y crear cadenas de autenticación para zonas secundarias. |
Zona sin firmar | Cualquier zona DNS que no haya sido firmada tal y como se define en RFC 4035 [7] Sección 2. |
Firma de zona | La firma de zona es el proceso de crear y agregar registros de recursos relacionados con DNSSEC a una zona, haciéndola compatible con la validación DNSSEC. |
Anulación de la firma de zona | La anulación de la firma de zona es el proceso de eliminación de los registros de recursos relacionados con DNSSSEC de una zona, restaurándola a un estado sin firma. |
Clave de firma de zona (ZSK) | Una clave de autenticación que corresponde a una clave privada que se utiliza para firmar una zona. Normalmente, una clave de firma de zona forma parte del mismo DNSKEY RRSet que la clave de firma de clave cuya clave privada correspondiente firma este DNSKEY RRSet, pero la clave de firma de zona se utiliza para un propósito ligeramente distinto y puede diferir de la clave de firma de clave en otros aspectos, como el tiempo de validez. Designar una clave de autenticación como clave de firma de zona es una cuestión puramente operativa; la validación DNSSEC no distingue entre claves de firma de zona y otras claves de autenticación DNSSEC. Es posible utilizar una misma clave como clave de firma y como clave de firma de zona. |
Pasos siguientes
- Obtenga información sobre cómo firmar una zona DNS con DNSSEC.
- Obtenga información sobre cómo anular la firma de una zona DNS.
- Aprenda cómo hospedar la zona de búsqueda inversa para el intervalo IP asignado por el ISP en DNS de Azure.
- Aprenda a administrar registros de DNS inversos para servicios de Azure.