Por qué un error de DS es una caída y no un defecto
DNSSEC se apoya en una cadena de confianza: la zona padre (por ejemplo la de la extensión) publica un registro DS, huella de la clave de firma de la zona del cliente, y los resolvedores validadores comparan esa huella con las claves que la zona publica realmente. Si la huella ya no corresponde a ninguna clave, el resolvedor no puede probar que las respuestas sean auténticas y se niega a responder: el usuario recibe un SERVFAIL.
Eso es lo que hace traicionero el error. El dominio sigue respondiendo en un resolvedor que no valida, así que una prueba rápida desde un equipo o una red de empresa puede parecer correcta, mientras los usuarios detrás de un resolvedor público validador no resuelven nada. Un DS huérfano no reduce la seguridad: corta el dominio. El resto de la guía sirve para no fabricar nunca uno y para saber salir de él.
Quién hace qué: operador DNS, registrador, registro
Intervienen tres actores, y la confusión entre ellos causa la mayoría de los incidentes. El operador DNS aloja la zona y posee las claves: firma y publica los registros DNSKEY y RRSIG. El registrador es la interfaz comercial donde el titular gestiona su nombre, y transmite el registro DS al registro. El registro mantiene la zona padre y publica el DS.
El DS nunca se crea, por tanto, solo en el registrador: copia una información producida por el operador DNS. Si el dominio está en un registrador pero sus servidores de nombres apuntan a otro operador, la firma se pide al operador DNS y el DS se introduce en el registrador. Aquí se da por conocida la definición general de DNSSEC y su papel contra el envenenamiento de caché; el artículo sobre el cambio de clave raíz del 11 de octubre de 2026, desde el lado del resolvedor, trata el otro extremo de la cadena.
Activar DNSSEC en el orden correcto
Comprobar que la extensión y el registrador aceptan el DS
Antes de tocar la zona, confirme que el registrador ofrece un campo DS para esa extensión y que el registro acepta el algoritmo previsto. No todos los registros aceptan todos los algoritmos: la lista de la extensión es la que cuenta, no la del operador DNS. Algunas extensiones no ofrecen DNSSEC en absoluto, por norma del registro.
Escribir el plan de vuelta atrás antes de empezar
Anote el estado actual: servidores de nombres, TTL de la zona, ausencia de DS. Obténgalo con
dig NS your-domain.com +shortydig DS your-domain.com +short. Escriba también quién puede eliminar el DS en el registrador, y por qué canal, si surge un problema. Una vuelta atrás que depende de una persona ilocalizable no lo es.Firmar la zona en el operador DNS
Active la firma en la interfaz del operador, o con sus herramientas si gestiona usted mismo el servidor. El operador genera la clave de firma de clave (KSK) y la clave de firma de zona (ZSK), y publica después los DNSKEY y los RRSIG. En esta fase nada cambia para los resolvedores: sin DS en la zona padre, la zona está firmada pero no validada, así que no hay riesgo.
Esperar la propagación de los DNSKEY y las firmas
Los resolvedores conservan en caché las respuestas antiguas hasta que termina su TTL. Espere al menos el TTL más largo de la zona antes de continuar y compruebe que
dig +dnssec your-domain.com DNSKEYdevuelve las claves y su firma desde cada uno de los servidores de nombres.Obtener los parámetros del DS
El operador DNS proporciona cuatro valores: el key tag, el algoritmo, el tipo de digest y la huella. Compruebe que corresponden a la KSK publicada (el campo flags vale 257) y elija el digest SHA-256, tipo 2. Cópielos y péguelos en lugar de teclearlos: un solo carácter erróneo produce un DS huérfano.
Publicar el DS en el registrador
Introduzca los cuatro valores en el campo DS del registrador. El registro publica entonces el DS en la zona padre, con un retraso propio de la extensión. Mientras ese retraso no haya pasado, algunos resolvedores ven todavía el estado anterior: concluya solo tras verificar.
Verificar la cadena de extremo a extremo
Consulte el servidor del padre, luego un resolvedor validador y después
delv, como se detalla en la sección siguiente. Mantenga abierto el plan de vuelta atrás hasta que los tres controles sean correctos desde al menos dos resolvedores públicos validadores distintos.
Algoritmos y digests: lo que exige la RFC 8624
Desplace la tabla
| Parámetro | Valor | Estado en la RFC 8624 |
|---|---|---|
| Firma ECDSAP256SHA256 | 13 | MUST, elección habitual |
| Firma RSASHA256 | 8 | MUST |
| Firma ED25519 | 15 | RECOMMENDED |
| Firma ED448 y ECDSAP384SHA384 | 16 y 14 | MAY |
| Firmas RSASHA1 y variantes | 5, 7 y 10 | NOT RECOMMENDED |
| Digest del DS: SHA-256 | 2 | MUST |
| Digest del DS: SHA-1 y GOST | 1 y 3 | MUST NOT para la delegación |
Verificar con dig y delv, con salidas reales
Bastan cuatro controles. El primero, dig +dnssec your-domain.com DNSKEY, debe devolver dos DNSKEY con los flags 256 (ZSK) y 257 (KSK) y un RRSIG. El segundo, dig DS your-domain.com @<servidor del padre>, consulta directamente la zona padre y debe devolver una línea de la forma <key tag> <algoritmo> <tipo de digest> <huella>, por ejemplo 2371 13 2 <huella> (valores ilustrativos): el key tag debe ser el de la KSK publicada por el operador.
El tercero, dig +dnssec your-domain.com A @1.1.1.1, debe mostrar la bandera ad (authenticated data) en la línea flags, por ejemplo flags: qr rd ra ad. El cuarto, delv your-domain.com A @1.1.1.1, debe mostrar ; fully validated antes de la respuesta. Un fallo tiene este aspecto: dig devuelve status: SERVFAIL, a menudo con EDE 9 DNSKEY Missing, y delv indica resolution failed.
Lo que puede bloquear en el registrador o el registro
- Sin campo DS — el registrador no ofrece la entrada para esa extensión, o solo mediante ticket: pregúntelo antes de firmar la zona.
- Algoritmo rechazado — el registro solo acepta una parte de los algoritmos de la RFC 8624; lea la lista de la extensión y no la del operador DNS.
- Digest limitado — algunos formularios solo aceptan SHA-256; es la elección correcta, pero hay que saberlo antes de generar el DS.
- Retraso de publicación — la zona padre no se actualiza al instante; el retraso depende de la extensión, así que no pruebe demasiado pronto.
- Extensión sin DNSSEC — algunas extensiones no ofrecen la función; el dominio sigue siendo válido pero no puede firmarse.
- Validación manual — la solicitud pasa por un ticket del registrador o un contacto, lo que alarga la vuelta atrás: inclúyalo en el plan.
Cambiar de proveedor DNS sin dejar un DS huérfano
Es el caso que más caídas produce. El DS se queda en el registrador mientras cambian los servidores de nombres: si el nuevo operador no firma, o firma con otras claves, el antiguo DS no corresponde a nada y los resolvedores validadores responden SERVFAIL. El mismo incidente ocurre en una migración de zona en la que se conserva el DS antiguo.
La RFC 6781 distingue dos casos, según coopere o no el operador anterior. Si coopera, ambos operadores intercambian sus claves públicas y publican los dos juegos durante el cambio, lo que evita cualquier periodo sin firmar. Si no coopera, la RFC concluye que la única operación viable es dejar que la zona pase a no firmada: retirar el DS, cambiar los servidores de nombres y luego insertar un DS que apunte a la zona recién firmada. En caso de duda, aplique la versión prudente que sigue, válida en ambos casos.
Procedimiento prudente para cambiar de proveedor DNS
Preparar la zona en el nuevo operador
Recree todos los registros, sin firmar ni cambiar los servidores de nombres. Compare las dos zonas registro por registro, por ejemplo con
dig @<servidor antiguo> your-domain.com MX +shorty luegodig @<servidor nuevo> your-domain.com MX +short, y lo mismo para A y TXT.Anotar el TTL del DS
Consulte
dig DS your-domain.com @<servidor del padre>y anote el TTL mostrado: es el tiempo durante el cual los resolvedores pueden seguir creyendo en el DS antiguo.Eliminar el DS en el registrador
Haga eliminar el DS y compruebe su desaparición con el mismo comando sobre el servidor del padre. La zona pasa a no estar firmada para los resolvedores, lo que es un estado válido y sin caída.
Esperar a que expire el TTL del DS
Espere al menos la duración anotada antes de tocar los servidores de nombres. Retirar las claves antes de que el DS haya expirado de las cachés recrea exactamente el DS huérfano que se quiere evitar.
Cambiar los servidores de nombres
Modifique los NS en el registrador. Compruebe el cambio con
dig NS your-domain.com @<servidor del padre>y pruebe la resolución desde un resolvedor validador. La guía sobre el cambio de servidores de nombres detalla la operación en el área de cliente.Firmar en el nuevo operador y republicar el DS
Active la firma, espere la propagación de los DNSKEY, obtenga los nuevos parámetros y publique el DS como en la activación inicial. Termine con los cuatro controles de dig y delv.
Rollover de claves, CDS y CDNSKEY
Dos operaciones de mantenimiento se parecen pero no tienen el mismo efecto en el registrador. Un rollover de ZSK no requiere ninguna acción en el registrador, porque el DS solo cubre la KSK. Un rollover de KSK exige un nuevo DS: la RFC 6781 describe la doble firma en cuatro fases, con una espera de al menos el TTL del DS antes de retirar la clave antigua. En un cambio de algoritmo, la misma RFC pide retirar primero el DS del padre y después el DNSKEY y las firmas.
Para evitar la introducción manual, la RFC 7344 define los registros CDS y CDNSKEY: el operador DNS publica en la zona el DS deseado y el agente del padre puede consumirlo, tras la validación DNSSEC. La RFC 8078 añade la supresión, mediante CDS 0 0 0 0 o CDNSKEY 0 3 0 0. Aun así, el registro o el registrador decide si los consume, y su compatibilidad depende de la extensión. El 13 de octubre de 2026, ICANN abrió una consulta pública sobre la evaluación de seguridad y estabilidad de la automatización del DS, abierta hasta el 23 de noviembre de 2026. El anuncio no menciona CDS ni CDNSKEY: la automatización ni está adoptada ni es inminente en esta fase.
Síntomas, causas y remedios
Desplace la tabla
| Síntoma | Causa probable | Remedio |
|---|---|---|
| SERVFAIL en 1.1.1.1 u 8.8.8.8, respuesta normal en otros | DS huérfano o clave ausente de la zona | Retirar el DS, esperar su TTL, republicar un DS correcto |
| `EDE: 9 (DNSKEY Missing)` en la salida de dig | Ningún DNSKEY corresponde al DS | Comparar el key tag del DS con la KSK publicada |
| `delv` responde `resolution failed` | Cadena de confianza rota | Probar con `dig +cd` para confirmar que la zona responde sin validación |
| Sin bandera `ad` pero sin error | Resolvedor no validador o DS aún no publicado | Consultar otro resolvedor, esperar el retraso del registro |
| Caída tras cambiar los servidores de nombres | Nuevo operador sin firmar, DS antiguo conservado | Seguir el procedimiento prudente, empezando por retirar el DS |
| Firmas caducadas | Firma automática detenida en el operador | Reactivar la firma, comparar las fechas del RRSIG |
El plan de vuelta atrás se redacta antes, no durante
Anote por escrito el estado inicial, el comando que prueba cada etapa y la persona que puede eliminar el DS en una urgencia. En caso de duda, la salida más corta es siempre la misma: eliminar el DS en el registrador y esperar su TTL. La zona vuelve a no estar firmada pero accesible, y después se diagnostica sin presión con dig +cd.
Lo que hace ServOrbit.com y lo que no hace
DNSSEC no se activa en autoservicio desde el área de cliente. Para solicitarlo, abra un ticket desde su área de cliente o escriba a [email protected]. La compatibilidad depende de la extensión y de su registro, en particular para los dominios .ma. ServOrbit.com no firma las zonas por usted y no expone un campo DS en el área de cliente: esta guía describe el método, no una función automática. El DNS gestionado de Cloudflare, presentado en la guía de activación correspondiente, solo se menciona aquí en un punto: cambiar de servidores de nombres en un dominio ya firmado expone al DS huérfano. Para añadir o modificar registros durante la preparación, la guía sobre registros DNS sigue siendo la referencia, y la de la transferencia saliente cubre el caso de un cambio de registrador. Guía proporcionada, sin soporte incluido.
La documentación oficial
RFC 6781, prácticas operativas de DNSSEC: https://www.rfc-editor.org/rfc/rfc6781.html
RFC 8624, algoritmos y digests: https://www.rfc-editor.org/rfc/rfc8624.html
RFC 7344, CDS y CDNSKEY: https://www.rfc-editor.org/rfc/rfc7344.html
RFC 8078, gestión del DS por el hijo: https://www.rfc-editor.org/rfc/rfc8078.html
Consulta de ICANN sobre la automatización del DS: https://www.icann.org/en/announcements/details/icann-seeks-input-on-security-stability-assessment-of-dnssec-ds-automation-13-10-2026-en
Cambio de KSK de la raíz: https://www.icann.org/resources/pages/ksk-rollover-en
