DNSSEC explicado: cómo funciona, cómo configurarlo y cómo comprobarlo

Cada vez que escribes el nombre de una web, tu dispositivo le pide a DNS que lo convierta en una dirección IP. Lo incómodo es que el DNS clásico no tiene ninguna forma de demostrar que la respuesta es genuina. Si alguien introduce una respuesta falsa en la conversación, tu resolutor se la cree y te manda al servidor equivocado. DNSSEC soluciona eso. Este artículo explica qué es, por qué existe, cómo activarlo en tu propio dominio y cómo comprobar que realmente funciona.

El problema que resuelve DNSSEC

DNS se diseñó en los años 80 para una red amistosa. Un resolutor hace una pregunta, alguien responde y gana la primera respuesta verosímil. No hay firma ni prueba de quién la envió. Ataques como el envenenamiento de caché se aprovechan de esto: el atacante compite con el servidor real, falsifica una respuesta y el resolutor guarda la mentira durante todo el TTL del registro. Después, todos los que usan ese resolutor acaban en la dirección del atacante.

DNSSEC (DNS Security Extensions) añade firmas digitales a los datos de DNS. Un resolutor que valida comprueba esas firmas y se niega a entregar cualquier cosa que no verifique. El objetivo es la autenticidad y la integridad: que la respuesta venga realmente del propietario de la zona y que nadie la haya modificado por el camino.

Lo que DNSSEC no hace

• No cifra nada. Cualquiera que esté en el camino sigue pudiendo ver qué nombres consultas. Los transportes cifrados como DNS sobre TLS o DNS sobre HTTPS resuelven ese problema distinto.

• No protege la web en sí. Demuestra que la dirección IP viene del propietario del dominio, no que el servidor que hay detrás sea de fiar. Sigues necesitando HTTPS.

• Solo ayuda si el resolutor valida. Firmar tu zona no hace nada por los usuarios cuyo resolutor ignora las firmas.

Las piezas básicas

Solo necesitas conocer un puñado de tipos de registro para entender DNSSEC.

• RRSIG: la firma sobre un conjunto de registros. Cada conjunto firmado (por ejemplo, todos los registros A de www) tiene su propio RRSIG, con una fecha de inicio y otra de caducidad.

• DNSKEY: la clave pública publicada en tu zona, que sirve para verificar las firmas.

• DS (Delegation Signer): una huella (hash) de una de tus DNSKEY, publicada en la zona padre. Es el eslabón que une tu zona con la zona que tiene por encima.

• NSEC / NSEC3: registros que demuestran que un nombre no existe. Sin ellos, un atacante podría falsificar respuestas de "ese dominio no existe", y no se puede firmar algo que no está.

• CDS / CDNSKEY: registros de tu zona que le indican al padre qué DS quieres, para que el registro de dominios pueda actualizarlo automáticamente.

KSK y ZSK

Tradicionalmente una zona tiene dos tipos de claves. La Key Signing Key (KSK) firma solo el conjunto de DNSKEY, y su hash es lo que el padre guarda como DS. La Zone Signing Key (ZSK) firma todo lo demás. Separarlas permite rotar con frecuencia la ZSK, que trabaja más, sin tocar al padre. Muchas configuraciones modernas usan una sola Combined Signing Key (CSK) que hace las dos funciones, lo cual es más simple y perfectamente aceptable con algoritmos modernos.

La cadena de confianza

Esta es la idea en palabras sencillas. Tu resolutor ya confía en una sola cosa: la clave pública de la raíz de DNS, integrada en su software (el ancla de confianza). A partir de ahí:

• La zona raíz firma un registro DS para com, así que el resolutor puede confiar en las claves de com.

• La zona com contiene un registro DS para example.com, firmado con las claves de com, así que el resolutor puede confiar en las claves de example.com.

• example.com firma sus propios registros, así que el resolutor puede confiar en la respuesta para www.example.com.

Cada eslabón avala al siguiente. Si falta alguno o es incorrecto, la cadena se rompe. Por eso el registro DS en tu registrador importa tanto: sin él, tu zona está firmada pero nadie tiene motivos para confiar en ella. Ese estado se llama "insecure" (inseguro) y se comporta como un DNS normal. Con un DS incorrecto, el estado es "bogus", y los resolutores que validan devolverán un error (SERVFAIL) para tu dominio.

Elegir algoritmos en 2026

Las recomendaciones oficiales se mantienen ahora en los registros de IANA para algoritmos DNSSEC y tipos de digest de DS. La RFC 9904 las movió allí desde la antigua RFC 8624, así que consulta los registros en lugar de un artículo antiguo, incluido este. En el momento de escribir esto dicen lo siguiente:

• Algoritmo 13, ECDSA P-256 con SHA-256: recomendado para firmar. Claves y firmas pequeñas, compatible con todo. Es la opción práctica por defecto.

• Algoritmo 15, Ed25519: también recomendado para firmar, compacto y moderno. Comprueba que tu software y tu registrador lo admiten antes de elegirlo.

• Algoritmo 8, RSA con SHA-256: sigue recomendado y está muy extendido, pero sus claves y firmas son más grandes.

• Algoritmos 14 (ECDSA P-384) y 16 (Ed448): permitidos (MAY), rara vez necesarios.

• Algoritmos 5 y 7 (RSA con SHA-1): MUST NOT para firmar. Los resolutores aún los validan, así que las zonas antiguas siguen funcionando, pero no crees nunca zonas nuevas así.

• Para el digest del registro DS usa SHA-256 (tipo de digest 2). Publicar registros DS con SHA-1 (tipo 1) es un MUST NOT.

Si usas NSEC3 en lugar de NSEC simple, sigue la RFC 9276: usa cero iteraciones adicionales (un MUST) y ninguna sal (un SHOULD NOT usarla). Las iteraciones extra cuestan CPU a los resolutores y no aportan protección real, así que los resolutores que validan pueden tratar una zona con muchas iteraciones como insegura o incluso rechazarla.

Puesta en marcha

Activar DNSSEC son siempre los mismos tres pasos, uses el software que uses:

• Generar las claves y firmar la zona.

• Entregar el registro DS al padre (a través de tu registrador).

• Probar toda la cadena.

Opción 1: lo hace tu proveedor de DNS

Si tu dominio usa un proveedor de DNS gestionado (Cloudflare, Route 53 y la mayoría de los demás), firmar es activar un interruptor. El proveedor genera las claves y firma la zona. Después te muestra el registro DS y tú lo pegas en tu registrador. Si el registrador y el proveedor de DNS son la misma empresa, a menudo se hace solo. Pasa a la sección de pruebas.

Opción 2: firmar en tu propio servidor BIND

El BIND 9 actual puede gestionar por sí mismo las claves, la firma y las rotaciones mediante una dnssec-policy. Ya no necesitas ejecutar las herramientas de claves a mano. Los ejemplos usan BIND 9.20. En la definición de tu zona:

zone "example.com" {
    type primary;
    file "/var/lib/bind/example.com.db";
    dnssec-policy default;
    inline-signing yes;
};

La política integrada default usa ECDSA P-256 (algoritmo 13) con una única CSK, adecuada para la mayoría de las zonas. Recarga la configuración y BIND crea la clave y firma la zona en unos pocos segundos. Puedes ver el progreso con:

rndc reload
rndc dnssec -status example.com
dig @127.0.0.1 example.com DNSKEY +multi

La salida de estado muestra la clave, por ejemplo key: 19984 (ECDSAP256SHA256), CSK, y el estado de cada parte del despliegue. Mientras no publiques el DS en el padre, el estado del DS se queda en hidden, lo cual es normal.

Mantén el archivo de zona sin firmar como tu fuente de verdad. Con la firma en línea (inline signing), BIND guarda la copia firmada aparte, así que editas el archivo normal como siempre, incrementas el número de serie del SOA y recargas. BIND firma los registros nuevos automáticamente y, por defecto, renueva las firmas antes de que caduquen. Con la política por defecto cada firma es válida durante 14 días.

Si quieres otro algoritmo, define tu propia política. Esta usa Ed25519:

dnssec-policy "ed" {
    keys { csk lifetime unlimited algorithm ed25519; };
};

Opción 3: firmar en Windows DNS Server

Si tu DNS vive en Windows Server, normalmente en tus controladores de dominio, puedes firmar zonas sin ningún software adicional. Los ejemplos usan el módulo de PowerShell DnsServer en Windows Server 2022 con una zona integrada en Active Directory. Windows también tiene un asistente de firma en el Administrador de DNS, pero PowerShell es más fácil de repetir y de documentar, así que es lo que se muestra aquí. Ejecuta los comandos en una sesión de PowerShell con privilegios elevados en el servidor DNS.

Qué te dan los valores por defecto

La forma más rápida de firmar una zona es:

Invoke-DnsServerZoneSign -ZoneName "example.com" -SignWithDefault -Force

Funciona y la zona queda firmada al instante. Pero fíjate en lo que obtienes por defecto:

• Claves RSA/SHA-256: una KSK de 2048 bits y una ZSK de 1024 bits. Es el algoritmo 8, aún aceptable pero no la opción moderna que vimos antes.

• NSEC3 con 50 iteraciones y una sal de 8 bytes, lo que va en contra de la RFC 9276.

• Registros DS generados con SHA-1 y SHA-256 a la vez. No publiques los de SHA-1.

• Rotación automática de claves activada: la ZSK cada 90 días y la KSK cada 755 días.

Puedes volver a consultar todo esto cuando quieras:

Get-DnsServerSigningKey -ZoneName "example.com"
Get-DnsServerDnsSecZoneSetting -ZoneName "example.com"

Hay algo en esa salida que puede asustar: NSec3HashAlgorithm muestra RsaSha1. Es el hash que NSEC3 usa para ofuscar los nombres. Es el único definido para NSEC3, no tiene relación con el algoritmo de firma y no es el problema de firmar con SHA-1 que se mencionó antes.

Firmar con ECDSA y ajustes modernos de NSEC3

Windows ofrece RSA (SHA-1, SHA-256, SHA-512) y ECDSA (P-256 y P-384). No ofrece Ed25519, y PowerShell lo rechaza como valor no válido. Para obtener ECDSA P-256 (algoritmo 13), cero iteraciones de NSEC3 y registros DS solo con SHA-256, sigue este orden. Importa, porque Windows rechaza algunos pasos si se hacen en el momento equivocado:

# 1. Firma primero con los valores por defecto. Esto también convierte a este servidor en el Key Master de la zona.
Invoke-DnsServerZoneSign -ZoneName "example.com" -SignWithDefault -Force

# 2. Añade claves ECDSA P-256.
Add-DnsServerSigningKey -ZoneName "example.com" -Type KeySigningKey -CryptoAlgorithm ECDsaP256Sha256
Add-DnsServerSigningKey -ZoneName "example.com" -Type ZoneSigningKey -CryptoAlgorithm ECDsaP256Sha256

# 3. Quita la firma de la zona. Las claves se recuerdan.
Invoke-DnsServerZoneUnsign -ZoneName "example.com" -Force

# 4. Elimina las claves RSA (esto solo funciona mientras la zona no está firmada).
Get-DnsServerSigningKey -ZoneName "example.com" | Where-Object CryptoAlgorithm -eq "RsaSha256" | ForEach-Object { Remove-DnsServerSigningKey -ZoneName "example.com" -KeyId $_.KeyId -Force }

# 5. Configura NSEC3 con cero iteraciones y sin sal, y los registros DS solo con SHA-256.
Set-DnsServerDnsSecZoneSetting -ZoneName "example.com" -DenialOfExistence NSec3 -NSec3Iterations 0 -NSec3RandomSaltLength 0 -DSRecordGenerationAlgorithm Sha256

# 6. Vuelve a firmar, usando las claves y los ajustes que acabas de configurar.
Invoke-DnsServerZoneSign -ZoneName "example.com" -Force

Haz todo esto antes de publicar nada en tu registrador, para que el DS que publiques sea el definitivo. Tres comportamientos de Windows explican la forma de esta secuencia:

• En una zona que nunca se ha firmado, Add-DnsServerSigningKey falla con "not the Key Master", por eso el paso 1 va primero.

• Windows no elimina las claves RSA de una zona firmada (la eliminación falla), solo de una sin firmar, por eso el paso 3 va antes que el 4.

• No uses -DoResign en una zona sin firmar. Falla porque la zona no está firmada. Un simple Invoke-DnsServerZoneSign -Force usa las claves que ya están configuradas.

Ahora comprueba el resultado. Las claves deben mostrar ECDsaP256Sha256, los ajustes deben mostrar NSEC3 con 0 iteraciones, y los registros de firma y de clave en la red deben indicar el algoritmo 13:

Get-DnsServerSigningKey -ZoneName "example.com"
Get-DnsServerDnsSecZoneSetting -ZoneName "example.com"
Resolve-DnsName www.example.com -Type A -DnssecOk -Server 127.0.0.1 -DnsOnly
Resolve-DnsName example.com -Type DNSKEY -Server 127.0.0.1 -DnsOnly

Obtener el registro DS para tu registrador

New-Item -ItemType Directory -Path C:\Temp -Force
Export-DnsServerDnsSecPublicKey -ZoneName "example.com" -DigestType Sha256 -Path C:\Temp -Force
Get-Content C:\Temp\dsset-example.com

Esto escribe un archivo llamado dsset-example.com en formato DS estándar. También se guardan copias de los archivos dsset y keyset en C:\Windows\System32\dns del Key Master. Verás dos líneas DS, por ejemplo:

example.com. 3600 IN DS 17252 13 2 ( 3ec4...30a7 )
             3600 IN DS  6609 13 2 ( dfef...d651 )

Hay dos porque Windows mantiene una KSK de reserva, y la zona publica cuatro registros DNSKEY (dos KSK y dos ZSK). Microsoft documenta que la rotación automática de la KSK usa el método de doble firma, en el que la clave nueva se añade junto a la antigua antes de retirar esta. Con ese método, lo sensato es publicar de antemano en tu registrador el DS de la clave de reserva, si admite más de un registro DS. Windows no actualiza el registrador por ti, así que cada rotación de la KSK obliga a comprobar que el DS del padre sigue coincidiendo.

Lo que importa en un controlador de dominio

• Almacenamiento de claves y Key Master. En una zona integrada en AD, las claves se guardan en Active Directory (StoreKeysInAD muestra True). Un servidor es el Key Master, y Get-DnsServerDnsSecZoneSetting indica cuál en el campo KeyMasterServer. Apunta cuál es. Los cambios de claves y de ajustes se hacen a través del Key Master, así que mueve el rol antes de retirar o reconstruir ese servidor. Ejecuta esto en el servidor que vaya a ser el nuevo Key Master, en una sesión de inicio de sesión completa, no en una sesión remota de PowerShell (por ejemplo, una tarea programada que se ejecute en ese servidor):

  Reset-DnsServerZoneKeyMasterRole -ZoneName "example.com" -KeyMasterServer "DC2.corp.example.com" -Force

  Ambos servidores siguen sirviendo respuestas firmadas mientras se mueve el rol. Ejecutado desde una sesión remota de PowerShell, el mismo comando falla, porque el nuevo Key Master tiene que contactar con el antiguo y una sesión remota no puede transmitir tus credenciales a un segundo servidor. Si el Key Master actual ya no existe, Microsoft documenta un parámetro -SeizeRole para ese caso.

• Los demás controladores de dominio sirven la zona firmada. Una vez que se ha ejecutado la replicación de AD, los demás controladores de dominio también sirven la zona firmada. Deja tiempo para la replicación, sobre todo hacia controladores de dominio en otras subredes o sitios, antes de probar cada servidor.

• Las actualizaciones dinámicas se firman automáticamente. Los registros que se añaden a una zona firmada mediante actualización dinámica se firman de forma automática, así que no tienes que volver a firmar a mano.

• Firmar tu zona interna de AD es una decisión aparte. La mayoría de los dominios internos, como corp.example.com, nunca son accesibles desde internet. Firmar una zona pública que alojas en Windows es el motivo más habitual para usar los pasos anteriores. Si además quieres que tus propios servidores DNS validen una zona interna firmada, necesitan un ancla de confianza para ella. Lee antes la documentación de Microsoft sobre anclas de confianza de DNSSEC, porque un error ahí hace que los nombres dejen de resolverse.

• Quitar DNSSEC. Invoke-DnsServerZoneUnsign -ZoneName "example.com" -Force quita la firma de la zona, pero solo después de haber eliminado el DS del padre, como se describe en "Mantenerlo sano".

Opción 4: otros servidores

Otros servidores DNS autoritativos tienen sus propias herramientas para firmar. Los conceptos anteriores son idénticos uses lo que uses: elige un algoritmo moderno, firma y publica el DS. Consulta la documentación de tu servidor para saber exactamente qué algoritmos ofrece, porque el soporte varía.

Publicar el registro DS

Ahora el paso que todo el mundo olvida. (En Windows, usa el archivo dsset exportado que se describió antes.) Pídele a la zona los valores del DS:

dig @127.0.0.1 example.com DNSKEY | dnssec-dsfromkey -2 -f - example.com

Esto imprime un registro DS: un key tag, un número de algoritmo, el tipo de digest 2 y un digest hexadecimal largo. Introduce esos cuatro valores en la sección DNSSEC o DS del panel de control de tu registrador. Algunos registradores aceptan la propia DNSKEY y calculan el DS por ti. Copia con cuidado. Un error de tecleo aquí hace que tu dominio sea inaccesible para los resolutores que validan.

Algunos registros de dominios pueden tomar el DS directamente de tu zona. Para eso, tu zona publica registros CDS y CDNSKEY (RFC 7344 y RFC 8078), que indican qué DS quieres. La política integrada default de BIND no los publica. Para activarlos, define una política con estas dos líneas:

dnssec-policy "with-cds" {
    keys { csk lifetime unlimited algorithm ecdsap256sha256; };
    cdnskey yes;
    cds-digest-types { "sha-256"; };
};

Después, dig example.com CDS +short devuelve una línea con formato de DS una vez que la clave se ha publicado. Los registros de dominios que admiten la RFC 9615 pueden incluso arrancar el primer DS a partir de estas señales, pero el soporte dista mucho de ser universal, así que cuenta con introducir el primer DS a mano y considera la automatización un extra.

Pruebas

Prueba por capas. No des nada por bueno solo porque el registrador haya aceptado el DS.

1. ¿Está firmada la zona?

dig +dnssec example.com A

Busca un registro RRSIG junto a tu registro A. Si está ahí, la zona se está firmando.

2. ¿Tiene el padre el DS correcto?

dig example.com DS +short
dig example.com DNSKEY +short

El DS del padre debe coincidir con una DNSKEY de tu zona. Puedes regenerar el DS a partir de tu DNSKEY con dnssec-dsfromkey y comparar el key tag y el digest.

3. ¿Lo acepta un resolutor que valida?

dig @1.1.1.1 +dnssec example.com A

En las flags de la cabecera, busca ad (Authenticated Data). Significa que el resolutor validó la respuesta. Si no ves la flag ad, o bien la cadena está incompleta (sigue siendo insegura) o bien el resolutor no valida. Prueba con otro resolutor público que valide para saber cuál es el caso. Recuerda que ad solo tiene sentido si confías en el camino hasta el resolutor, porque un atacante en medio podría activarla.

La herramienta delv, que se incluye con BIND, hace su propia validación y muestra exactamente dónde se rompe una cadena:

delv @1.1.1.1 example.com A +vtrace

Un resultado sano dice fully validated.

4. Distinguir "bogus" de "simplemente roto"

Si un dominio da SERVFAIL, vuelve a preguntar con la comprobación desactivada:

dig @1.1.1.1 example.com A
dig @1.1.1.1 example.com A +cd

La flag +cd significa "checking disabled" (comprobación desactivada). Si la primera falla pero la segunda devuelve una respuesta, el problema es la validación de DNSSEC, no el registro en sí. Esa es la firma típica de una firma caducada o de un DS que no coincide. Puedes verlo en directo con el nombre de prueba deliberadamente roto:

dig @1.1.1.1 sigfail.verteiltesysteme.net A       # estado: SERVFAIL
dig @1.1.1.1 +cd sigfail.verteiltesysteme.net A   # estado: NOERROR, con respuesta

Un DS en el padre que no coincide con la clave del hijo produce exactamente esto: SERVFAIL en la consulta normal, una respuesta con +cd, y delv informando de "broken trust chain". El log del resolutor indica la causa (Unbound registra "DS hash mismatches key"), así que lee el log del resolutor cuando tengas acceso a él.

El caso contrario es más silencioso. Si tu zona está firmada pero el padre no tiene DS, todo se resuelve con normalidad, solo que sin la flag ad. No se rompe nada y nada queda protegido.

5. Comprobadores en línea

Las herramientas web dan una imagen completa en segundos: DNSViz (dnsviz.net) dibuja toda la cadena de confianza y resalta los errores, y DNSSEC Analyzer de Verisign y Zonemaster comprueban tanto DNSSEC como problemas generales de delegación. Ejecuta uno después de cada cambio.

Pruebas desde Windows

No necesitas herramientas de Linux para comprobar una zona. Resolve-DnsName puede pedir directamente registros DNSSEC:

Resolve-DnsName example.com -Type A -DnssecOk -Server 1.1.1.1
Resolve-DnsName example.com -Type DNSKEY -Server 1.1.1.1
Resolve-DnsName example.com -Type A -DnssecOk -DnssecCd -Server 1.1.1.1

Con -DnssecOk deberías ver registros RRSIG en la salida junto al registro A. El último comando activa la flag de comprobación desactivada, así que es el equivalente en Windows de dig +cd. Ten en cuenta que nslookup a secas no puede pedir tipos de registro DNSSEC (responde "unknown query type: RRSIG"), así que usa Resolve-DnsName. Windows no incluye delv, así que para esa comprobación usa una máquina Linux o WSL, o apóyate en los comprobadores en línea descritos arriba.

¿Está validando tu propio resolutor?

Tus usuarios solo están protegidos si el resolutor que usan valida. Para comprobar el tuyo, consulta un dominio deliberadamente roto. Un resolutor que valida debe rechazarlo:

dig sigfail.verteiltesysteme.net A
dig sigok.verteiltesysteme.net A

Son nombres de prueba públicos creados exactamente para esto. El primero debería devolver SERVFAIL en un resolutor que valida, y el segundo debería funcionar y llevar la flag ad. Cloudflare (1.1.1.1), Google (8.8.8.8) y Quad9 (9.9.9.9) se comportan así, igual que una instalación local de Unbound con el ancla de confianza de la raíz. Unbound y BIND normalmente validan de serie en las distribuciones actuales.

Mantenerlo sano

DNSSEC no es de "configurar y olvidar" como el DNS normal. Las firmas caducan, así que algo tiene que seguir firmando de nuevo. Las herramientas modernas lo automatizan, pero conviene conocer los modos de fallo.

• Firmas caducadas. Si se deja de renovar la firma (un servicio caído, un secundario detenido), las firmas se agotan y los resolutores que validan rechazan la zona entera. Monitoriza la caducidad de las firmas.

• Rotaciones de claves. Las claves deben sustituirse periódicamente o tras un compromiso. Una rotación debe seguir un orden estricto: primero se publican las claves nuevas, luego se usan y después se retiran las antiguas, con esperas basadas en los TTL. Deja que la política de tu software se ocupe de esto y no lo hagas a mano salvo que sea imprescindible.

• Cambiar de proveedor de DNS. Es la forma más habitual de dejar un dominio fuera de línea. Pasar a un proveedor que no puede servir las firmas antiguas mientras el DS antiguo sigue en el padre rompe la validación. O bien eliminas primero el DS en el registrador y esperas a que caduque su TTL, o bien usas una configuración multi-firmante documentada. Después vuelve a activar DNSSEC en el nuevo proveedor.

• Desactivar DNSSEC. Elimina siempre el DS del padre primero, espera a que pase el TTL antiguo y solo entonces deja de firmar. Hacerlo al revés rompe el dominio: un resolutor que valida devuelve SERVFAIL para una zona servida sin firmar mientras el padre aún tiene su DS ("No DNSKEY record"), y eliminar el DS lo arregla.

• Respuestas más grandes. Las firmas hacen más grandes los paquetes DNS. Asegúrate de que tu firewall permite DNS sobre TCP además de UDP, y de que no descarta respuestas UDP fragmentadas o grandes.

¿Merece la pena?

Para la mayoría de los dominios públicos, sí. Es gratis con la mayoría de los proveedores, es un interruptor sencillo y protege a los usuarios contra una clase de ataque real. También habilita funciones de seguridad más nuevas que dependen de respuestas DNS de confianza, como DANE para el correo. El coste es operativo: un error provoca caídas en lugar de fallos silenciosos, así que prueba con cuidado y monitoriza. Empieza con un dominio de poco riesgo, familiarízate con las herramientas anteriores y luego extiéndelo a los que importan.

Referencia rápida

• Algoritmo: 13 (ECDSA P-256), o 15 (Ed25519) si es compatible en todos los sitios donde lo necesitas.

• Digest del DS: SHA-256 (tipo 2).

• NSEC3, si se usa: 0 iteraciones, sin sal.

• Firma, publica el DS en el registrador y luego prueba con dig +dnssec, delv y DNSViz.

• Elimina el DS antes de desactivar la firma o de cambiar de proveedor.

• Busca la flag ad en un resolutor que valide, y usa +cd para aislar los fallos de validación.