Resumen

  • CDS/CDNSKEY comunica el estado que el lado hijo desea ver reflejado en el DS del padre. Si ya existe un DS válido, la cadena actual puede autenticar un cambio de clave; en el alta inicial esa misma cadena todavía no existe.
  • RFC 9615 autentica el primer enlace mediante copias coincidentes bajo las zonas seguras de cada servidor de nombres externo al hijo. El acuerdo acredita control y consentimiento de los operadores publicados, pero no demuestra propiedad ni conocimiento humano.
  • La política del agente parental, la selección de huellas, la escritura del DS, los TTL y la prueba desde validadores siguen siendo actos distintos. La señal de algoritmo cero elimina toda la confianza delegada y necesita control destructivo propio.

El formulario correcto que no podía aprobarse solo

Una empresa traslada su DNS autoritativo a un servicio gestionado. El nuevo proveedor genera una KSK, firma el DNSKEY y publica CDS y CDNSKEY. Las tres autoridades devuelven el mismo material. El panel del proveedor marca la zona como preparada, pero el TLD todavía no contiene DS.

La firma no resuelve ese vacío. Un validador no puede escoger la nueva DNSKEY porque ella misma avale el RRset donde aparece. Necesita el DS parental para enlazar una confianza anterior con la clave del hijo. Precisamente en el primer alta, el objeto que permitiría validar al hijo aún está ausente.

La empresa puede haber autorizado la migración. También puede haber sufrido un cambio automático no anunciado. El operador demuestra que controla la zona servida. El registrador conoce la cuenta. El registro puede escribir el DS. Son evidencias complementarias, no una sola identidad.

La finalidad de CDS/CDNSKEY es quitar una fricción histórica: cada cambio de KSK o CSK no debería requerir copiar a mano una larga huella entre organizaciones. El valor empresarial es real. La condición de seguridad es no convertir la facilidad de lectura mecánica en una presunción de mandato ilimitado.

El hijo expresa; el padre registra

El DS que consultan los validadores vive en la zona padre. Contiene la referencia que permite comprobar una DNSKEY del hijo. CDS usa la estructura de DS con un tipo de registro diferente. CDNSKEY transporta la clave pública para que el agente parental calcule el DS bajo su política.

RFC 7344 define una intención de reemplazo. El RRset publicado describe cómo debería quedar el DS después del cambio. El consumidor calcula la diferencia y actúa en el sistema del padre. No es una transferencia de autoridad sobre la zona superior ni una modificación directa hecha por el hijo.

La ausencia de ambos registros significa conservar el estado. Un operador puede retirarlos una vez sincronizado el DS. Un fallo de consulta o una respuesta vacía no licencia el borrado. Este pequeño detalle separa una señal explícita de una ausencia ambigua.

El padre puede elegir CDS o CDNSKEY como mecanismo preferente. Al calcular desde CDNSKEY, puede limitar los tipos de huella permitidos y producir un conjunto distinto solo en ese atributo. El hijo controla la clave que propone; el padre conserva la compatibilidad y su política de huellas.

La decisión distribuida queda así: el operador hijo publica, el agente parental autentica y admite, la zona padre registra y los validadores comprueban. Una automatización segura preserva la trazabilidad entre esos verbos.

La rotación parte de un DS existente

Cuando el padre ya publica un DS que corresponde a una clave vigente, el nuevo CDS/CDNSKEY puede validarse por esa cadena. RFC 7344 exige una firma respaldada tanto por el DNSKEY actual como por el DS actual, y prohíbe aplicar una transición que rompa la continuidad.

La clave anterior actúa como puente a la siguiente. Eso no exime al agente parental de recoger el RRset correcto, comparar estados y evitar la reproducción de una observación antigua. La fecha de inicio de RRSIG o el número de serie SOA ayudan a reconocer el orden, pero el consumidor necesita memoria propia de lo aceptado para que una vista antigua no revierta la nueva.

Después de publicar el DS continúa la fase temporal. Algunos cachés mantienen la referencia antigua; otros ya observan la nueva. El hijo debe servir las claves necesarias en todas sus autoridades durante el solapamiento. Retirar la antigua al ver una única respuesta del padre convierte una actualización nominalmente exitosa en SERVFAIL para validadores retrasados.

BIND muestra este límite operativo: puede crear las señales y consultar parental-agents, pero pausa la rotación si no todos confirman el DS esperado. Cuando el padre no consume CDS/CDNSKEY, el administrador vuelve al canal manual. Ninguna opción local obliga al otro lado a participar.

El alta inicial se autentica desde los nombres de operador

RFC 8078 propuso controles para el primer DS: interfaz autenticada, verificaciones de cuenta, retraso con observación desde diversos lugares, desafío o tratamiento al crear la delegación. Son políticas razonables en ciertos mercados, aunque no construyen por sí mismas una cadena DNSSEC desde el hijo inseguro.

RFC 9615 aporta una fuente criptográfica externa. Para cada nombre de host de servidor de nombres indicado en la delegación del padre, crea un dominio añadiendo _signal. En él, un nombre _dsboot específico del hijo publica una copia del CDS/CDNSKEY del ápice.

La zona que contiene el dominio de señal debe tener una cadena DNSSEC válida previa. El agente parental puede validar esa copia bajo el espacio del operador de nombres y compararla con la respuesta directa del hijo. No se confía en una autofirma aislada; se importa una autenticación desde la infraestructura que ya representa al operador.

El proceso comprueba primero que no existe DS y que hay al menos un servidor de nombres externo al dominio hijo. Luego pregunta, sin caché, a todos los servidores autoritativos incluidos en el NS del padre. Después resuelve cada señal externa con validación DNSSEC. Finalmente exige igualdad por tipo de RRset.

Una sola anomalía aborta: servidor sin respuesta, dato no autenticado, registro ausente en una vista y presente en otra, o claves distintas. Si todos los servidores de nombres están dentro del dominio hijo, no hay una ruta independiente y el método no puede utilizarse.

Esta unanimidad limita el poder de un proveedor en despliegues múltiples. Ninguno puede conseguir que el padre publique solo su DS si las demás autoridades presentan otro estado. RFC 8901 exige además que los múltiples firmantes intercambien las claves y señales necesarias para sostener una vista común durante las rotaciones.

El operador prueba control, no propiedad

La señal RFC 9615 dice que los operadores expuestos por la delegación están dispuestos a firmar para ese hijo y conocen el mismo material. No establece quién celebró el contrato, quién es titular del dominio o si el cambio fue aprobado en la organización.

El propio RFC advierte que un proveedor podría publicar esas señales sin conocimiento explícito del dueño y recomienda transparencia. Por eso una activación automática legítima, un error y una cuenta comprometida pueden generar registros igualmente bien firmados. La criptografía distingue alteración; no resuelve una disputa de mandato.

El agente parental necesita una política que conecte el control técnico con una relación autorizada. Debe indicar qué actor puede pedir alta, rotación o baja, qué aviso recibe el titular y qué canal cancela una acción inesperada. La validación DNSSEC no reemplaza esa contabilidad.

RFC 9615 también recomienda la minimización de QNAME. Sin ella, un ancestro del dominio de señal ve el nombre completo y podría intentar contestar con datos firmados bajo su propia autoridad. Reducir esa exposición ayuda a llegar al corte correcto; no transforma una firma técnica en autorización institucional.

Borrar DS cambia la condición de seguridad

Las formas exactas CDS 0 0 0 0 y CDNSKEY 0 3 0 0 ordenan retirar todo el DS parental. El algoritmo cero no valida firmas. Es una señal especial de eliminación, no una nueva clave ni una lista vacía.

El padre verifica el RRset y aplica sus controles antes de borrar. El hijo espera los TTL parentales antes de dejar de firmar. Si elimina DNSKEY mientras aún existen DS en caché, los validadores ven una cadena que apunta a una clave inexistente y califican la zona como no válida.

Los estados actuales de Cloudflare ofrecen un ejemplo concreto: durante la desactivación mantiene la firma y publica la señal cero hasta que el DS desaparece; solo después elimina el material DNSSEC. No todas las plataformas usan los mismos nombres o mecanismos, pero todas deben respetar que solicitud, publicación y agotamiento de caché son tiempos diferentes.

Volver a un estado no seguro exige más prudencia que una rotación. Reduce protección y puede destruir el camino con el que se autenticaría una reparación. Debe tener notificación, ventana de recuperación y evidencia de que la señal exacta, no un fallo de lectura, causó la decisión.

La cadena de evidencia continúa después del cambio

Antes de actuar, se archivan NS y DS parentales, respuestas de todos los hijos, nombres de señal, cadenas de validación, igualdad, actualidad, regla de huellas, autoridad de cuenta y diferencia propuesta. El registro debe permitir reconstruir quién controlaba cada superficie.

Después se observan todas las autoridades del padre, se esperan los TTL, se comprueban DNSKEY y RRSIG en cada servidor hijo y se hacen consultas con validadores independientes. Un API 200 no demuestra publicación. Una respuesta autoritativa no demuestra agotamiento de cachés. Un validador exitoso no demuestra todos los caminos, pero completa una pieza que ningún panel puede sustituir.

También se registran los abortos. Disenso entre operadores, señal no validable, huella no permitida o delegación con todos sus servidores dentro del dominio hijo son resultados explicables. El control funciona cuando se niega a convertir evidencia incompleta en una mutación irreversible.

Fuentes