Guía de configuración DNSSEC para DNScale — Paso a paso

Esta guía le acompaña en activar DNSSEC en una zona de DNScale, publicar el registro DS en su registrador, verificar la cadena de confianza y manejar los modos de fallo más comunes. Si quiere primero el contexto conceptual, lea ¿Qué es DNSSEC? y Cómo funciona DNSSEC.

Antes de empezar

Confirme tres cosas:

1. Su zona está delegada a DNScale. Los registros NS en su registrador apuntan a los servidores de nombres DNScale, y dig NS sudominio @1.1.1.1 devuelve el set DNScale. Si aún no ha migrado, hágalo primero — vea Delegación DNS para regiones DNScale.
2. Su TLD soporta DNSSEC. Todos los gTLDs (.com, .net, .org, etc.) y la mayoría de ccTLDs (.de, .fr, .nl, .eu, .uk, .es) soportan DNSSEC desde hace años. Un puñado de TLDs antiguos o pequeños no — compruebe el informe TLD IANA en caso de duda.
3. Su registrador soporta publicación DS. La mayoría de registradores principales sí. Si el suyo no, deberá transferir el dominio a un registrador con capacidad DNSSEC o aceptar que DNSSEC no esté disponible para ese dominio.

Paso 1 — Activar DNSSEC en DNScale

Desde el panel

1. Abra su zona en el panel DNScale.
2. Haga clic en la pestaña Seguridad (o DNSSEC según la versión del panel).
3. Haga clic en Activar DNSSEC. DNScale genera una nueva CSK usando ECDSA P-256 y comienza a firmar la zona. Esto tarda unos segundos.
4. El panel muestra el registro DS a publicar en su registrador:

example.com.   86400   IN   DS   12345 13 2 7c89aa1f3e7b4d8b...

Tome nota de los cuatro campos: Etiqueta de clave (12345), Algoritmo (13 = ECDSA P-256), Tipo de digest (2 = SHA-256), Digest (la cadena hex). Las UI de los registradores piden estos en combinaciones diferentes — la mayoría piden los cuatro; algunos piden la cadena DS completa; unos pocos calculan ellos mismos el digest y solo piden la clave pública DNSKEY.

Usando la API DNScale

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/dnssec/enable" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json"

La respuesta incluye los campos del registro DS que necesitará en el registrador:

{
  "enabled": true,
  "ds_records": [
    {
      "key_tag": 12345,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "7c89aa1f3e7b4d8b..."
    }
  ]
}

Usando Terraform

resource "dnscale_zone_dnssec" "example" {
  zone_id   = dnscale_zone.example.id
  enabled   = true
}

Tras terraform apply, el recurso expone los campos DS como salidas que puede pasar a un provider de registrador (si su registrador es gestionado por Terraform) o capturar para entrada manual.

Usando DNSControl

D("example.com", DNSCALE,
  AUTODNSSEC_ON,
  // ... sus registros
);

La directiva AUTODNSSEC_ON de DNSControl activa la firma desde el provider DNScale. El registro DS queda disponible en la salida de dnscontrol get-zones.

Paso 2 — Publicar el registro DS en su registrador

Este es el único paso manual que el proveedor DNS no puede (todavía) hacer por usted — vea automatización CDS/CDNSKEY más abajo. La UI exacta varía según el registrador; aquí los más comunes.

Patrón genérico

La mayoría de paneles de registradores tienen una sección DNSSEC o DNS avanzado por dominio. Típicamente:

1. Haga clic en Añadir registro DS.
2. Introduzca los cuatro campos: Etiqueta de clave, Algoritmo, Tipo de digest, Digest.
3. Guarde.

Algunos registradores piden la cadena completa del registro DS (por ejemplo 12345 13 2 7c89aa1f...) — pegue la línea completa. Otros le permiten pegar la clave pública DNSKEY y calcular ellos mismos el DS — ambos funcionan; use lo que el registrador prefiera.

Cloudflare Registrar

Domain → DNS → DNSSEC → Activar → Añadir registro DS. Pegue los cuatro campos. Cloudflare publica el DS en el TLD en minutos.

Gandi

Domains → su dominio → DNSSEC → Añadir clave. Pegue los campos; Gandi publica típicamente en 30 minutos.

Namecheap

Domain List → Manage → Advanced DNS → DNSSEC → Add Key. Pegue los campos y guarde.

OVH

Dominio → DNSSEC → Añadir → Activar DNSSEC. Pegue los campos. OVH propaga en 30 minutos para la mayoría de TLDs.

IONOS / 1&1

Dominio → SSL & DNSSEC → DNSSEC → Activar → Añadir registro. Pegue los campos. IONOS publica típicamente en una hora.

GoDaddy

Dominio → DNS → DNSSEC. Añadir clave. Pegue los campos. El tiempo de publicación varía; estime 24–48 horas.

Dominio en un registrador solo-registro

Algunos registros ccTLD aceptan registros DS directamente vía interfaz web o EPP. El registrador normalmente los pasaría — si no, contacte al soporte del registro.

Paso 3 — Verificar la cadena de extremo a extremo

Una vez publicado el DS, verifique que la cadena funciona en cada eslabón. El comando único más fiable:

dig +dnssec example.com @1.1.1.1

Busque dos cosas en la respuesta:

1. La bandera AD en la cabecera — ;; flags: qr rd ra ad; — confirma que el resolutor validó la cadena con éxito.
2. Registros RRSIG en la sección de respuesta, emparejados con cada registro de datos.

Si la bandera AD falta pero hay registros RRSIG, el resolutor no está validando (pruebe 8.8.8.8 o 9.9.9.9). Si los RRSIGs faltan, la firma no surtió efecto — re-verifique el Paso 1.

Verificar el DS en la zona padre

dig DS example.com @a.gtld-servers.net.

Para .com, consulte directamente los servidores gTLD. Para otros TLDs, encuentre los NS del padre vía dig NS .com @a.root-servers.net. o use dig +trace. Respuesta esperada: su registro DS, exactamente como lo envió.

Si el DS no aparece en el padre en 48 horas, contacte a su registrador — la publicación probablemente falló.

Usar un visualizador

Para una imagen completa, el visualizador DNSViz dibuja toda la cadena de la raíz a su zona y resalta las roturas. El DNSSEC Debugger de Verisign hace lo mismo en una presentación distinta.

Paso 4 — Probar desde múltiples resolutores

Diferentes resolutores cachean de forma distinta y despliegan actualizaciones a ritmos diferentes. Tras la verificación inicial, consulte desde al menos tres:

dig +dnssec example.com @1.1.1.1     # Cloudflare
dig +dnssec example.com @8.8.8.8     # Google
dig +dnssec example.com @9.9.9.9     # Quad9

Si los tres muestran la bandera AD, su despliegue DNSSEC está alcanzando la flota de resolutores públicos.

Modos de fallo comunes y cómo recuperarse

El DS en el registrador no coincide con el DNSKEY

Síntoma: dig +dnssec sudominio devuelve SERVFAIL. DNSViz muestra un enlace rojo entre el DS del padre y su DNSKEY.

Causa: Digest erróneo, algoritmo erróneo o etiqueta de clave errónea introducidos en el registrador.

Solución: Recuperar el DS correcto desde el panel DNScale. Actualizar en el registrador. Esperar a propagación TLD. Si la UI del registrador no acepta su edición, retire primero el DS erróneo y vuelva a añadir.

Múltiples DS desactualizados en el registrador

Síntoma: La validación funciona intermitentemente — algunos resolutores marcan AD la respuesta, otros SERVFAIL.

Causa: Una activación DNSSEC anterior dejó DS antiguos que ya no coinciden con ningún DNSKEY actual.

Solución: En el registrador, retire cada DS que no aparezca en la lista DS DNScale actual. Mantenga solo el DS de la KSK actualmente activa.

El TLD no acepta el DS

Síntoma: La UI del registrador rechaza el DS o lo muestra como "pendiente" indefinidamente.

Causa: El TLD aún no soporta DNSSEC (muy raro en 2026), o hay un retraso en el lado del registro.

Solución: Compruebe el informe TLD IANA sobre el estado DNSSEC. Si no está soportado, no puede activar DNSSEC para ese dominio; considere transferirlo a un TLD que lo soporte. Si está soportado pero atascado, contacte al soporte del registrador.

La firma se desactivó antes de retirar el DS

Síntoma: El dominio devuelve SERVFAIL desde resolutores validadores; los resolutores no validadores siguen resolviendo normalmente.

Causa: Orden de operaciones incorrecto — el registro DS en el padre ahora apunta a una clave que ya no existe en su zona.

Solución: Reactivar DNSSEC en DNScale (que restaura la firma con las mismas etiquetas de clave si es posible), o retirar el DS en el registrador. El orden correcto para desactivación permanente es: retirar DS → esperar 48h → desactivar firma.

Respuestas negativas pre-cacheadas persisten

Síntoma: Tras corregir una mala configuración DNSSEC, algunos usuarios siguen viendo SERVFAIL durante un tiempo.

Causa: Los resolutores validadores cachean fallos de validación (típicamente hasta 5 minutos). Los resolutores públicos que sirven datos rancios bajo RFC 8767 pueden mantener fallos rancios más tiempo.

Solución: Espere. Los fallos cacheados expiran; nada en su lado cambia el tiempo. Verificar desde un resolutor recursivo nuevo (dig +dnssec sudominio @1.0.0.1 en vez de @1.1.1.1) confirma si el estado subyacente está bien ahora.

Opcional: Automatizar el DS vía CDS/CDNSKEY

RFC 7344 y RFC 8078 definen los registros CDS y CDNSKEY — registros del lado del hijo que indican al padre qué registros DS publicar. Un registrador que soporte el escaneo CDS/CDNSKEY puede recoger cambios DS automáticamente sin entrada manual.

El soporte es desigual:

• ✅ Cloudflare Registrar — automatización CDS completa
• ✅ Gandi — soporta CDS para algunos TLDs
• ⚠️ La mayoría de los demás — gestión DS manual aún
• ❌ Algunos registradores legacy — sin soporte DNSSEC

DNScale publica registros CDS y CDNSKEY automáticamente cuando DNSSEC está activado. Si su registrador soporta escaneo CDS, no es necesaria entrada manual de DS — las rotaciones DS durante el rollover de claves ocurren sin su intervención.

Qué pasa después — Operaciones automáticas

Una vez activado DNSSEC en una zona DNScale:

• Las firmas se refrescan continuamente. Los registros RRSIG se re-firman antes de la expiración; los resolutores ven firmas frescas en cada consulta.
• La rotación de claves ocurre según planificación. La ZSK rota más a menudo (cuando está separada de la KSK); la KSK rota raramente (cada varios años). Con CSK (el predeterminado), las rotaciones involucran al registrador — DNScale le notifica cuando se necesita acción del registrador.
• Las actualizaciones de algoritmo son rolls coordinados. Si la industria cambia (por ejemplo, a Ed25519), DNScale ejecuta una rotación de algoritmo sin tiempo de inactividad de datos de zona.
• Actualizaciones del registro DS durante la rotación: con automatización CDS, el DS del padre se actualiza sin su intervención; sin ella, DNScale le notifica que un nuevo DS necesita publicarse.

No debería tener que pensar en DNSSEC de nuevo tras la configuración inicial — hasta que decida migrar o cambie la UX del registrador.

Referencias

• RFC 4033/4034/4035 — especificación núcleo DNSSEC
• RFC 7344 — Automating DNSSEC delegation trust maintenance (CDS/CDNSKEY)
• RFC 8078 — Managing DS records from the parent via CDS/CDNSKEY
• RFC 8901 — Modelos DNSSEC multi-firmante (para despliegues multi-proveedor)
• Anclas de confianza raíz IANA
• Visualizador DNSViz
• DNSSEC Debugger de Verisign

Lecturas relacionadas

• ¿Qué es DNSSEC? — introducción top-of-funnel
• Cómo funciona DNSSEC — mecánica KSK/ZSK/DS/DNSKEY
• Gestión de claves DNSSEC — procedimientos operativos de rotación
• Despliegue DNS multi-proveedor — añadir un segundo proveedor DNS de forma segura con DNSSEC
• Delegación DNS para regiones DNScale — apuntar su zona a DNScale antes de activar DNSSEC
• Envenenamiento de caché DNS — el ataque que DNSSEC derrota
• NIS2 y cumplimiento DNS — DNSSEC como control regulatorio