Resumen

  • El operador DNS hijo publica CDS y CDNSKEY para indicar qué parámetros de delegación desea. El agente parental solo puede actuar después de autenticar la señal, consultar todas las direcciones autoritativas, resolver cualquier contradicción entre formatos y comprobar que el DS resultante conserva una ruta de validación.
  • NOTIFY(CDS) avisa de que hay algo que revisar; no autoriza el cambio. Aceptación, publicación en el padre, caducidad de cachés y validación observada requieren pruebas propias.

El indicador verde que llegó demasiado pronto

Un sistema de aprovisionamiento muestra “publicado”. La nueva DNSKEY está firmada y la consulta directa al primario devuelve los CDS y CDNSKEY esperados. Desde el punto de vista del panel, el trabajo del hijo terminó.

El agente parental consulta la delegación completa. Una dirección IPv6 de un secundario todavía responde con el conjunto anterior. Cancela la operación sin tocar el DS existente.

No se trata de un incidente atribuido a una empresa concreta, sino de un escenario analítico. Sirve para identificar el error del panel: describió la intención del control plane como si fuera el estado del servicio autoritativo. El padre no recibió una orden inequívoca. Recibió respuestas autenticadas pero incompatibles.

La cancelación protege algo más importante que la velocidad. El DS del padre es un vínculo de confianza utilizado por validadores que no participan en la relación contractual entre el dominio y su proveedor DNS. Si el agente parental interpreta una mayoría o escoge la respuesta que parece más nueva, asume una voluntad que el hijo no ha expresado de forma uniforme.

La zona hija no firma el padre

DNSSEC conecta dos ámbitos administrativos en el corte de zona. El padre publica un DS que referencia una DNSKEY del hijo; el hijo publica y firma su conjunto DNSKEY. Ninguna de esas partes puede sustituir por completo a la otra.

RFC 7344 define CDS y CDNSKEY para transportar hacia un agente parental la configuración de confianza deseada. CDS usa el formato de un DS. CDNSKEY entrega la clave para que el lado parental calcule el DS. Ambos viven en el hijo, no en el padre.

Por eso “publicar CDS” no significa “cambiar el DS”. Significa hacer una propuesta legible por máquinas. El agente parental —registro, registrador, revendedor u otra entidad autorizada— decide si la propuesta es auténtica, coherente y segura. Después, el operador de la zona padre debe publicarla.

Esta separación no es una defensa de la discrecionalidad institucional. Es una asignación mínima de responsabilidades. El hijo controla claves, firma y despliegue autoritativo. El padre controla la zona que firma y sirve. El protocolo debe reducir la coordinación a reglas verificables, sin convertir al padre en gobernador del negocio del hijo ni al hijo en administrador remoto del padre.

Consistencia significa cada dirección

RFC 9975 especifica una comprobación que suele perderse en implementaciones sencillas. El agente parental obtiene todas las direcciones IP de cada hostname de servidor de nombres que aparece en la delegación del padre, usando un resolvedor validador e incorporando el glue disponible. Después consulta cada dirección.

No basta con resolver un nombre una vez. Un hostname puede tener A y AAAA, varias direcciones o nodos anycast. En una configuración con varios proveedores, cada destino puede depender de un sistema de publicación diferente. La intención solo es plausible cuando las respuestas recibidas son coherentes.

NODATA cuenta como respuesta. Una diferencia obliga a abortar: no se crea el nuevo RRset, no se altera el existente y no se ejecuta una eliminación. El algoritmo no vota, no promedia y no presupone que el serial más alto representa la voluntad correcta.

Una falta de respuesta se trata de otro modo. El agente debería reintentar, preferentemente con retroceso exponencial, y puede usar otro punto de red para descartar un problema de ruta local. El registro operativo debe distinguir “inaccesible”, “inconsistente” e “inválido”. Si todos se resumen en un error genérico, el equipo de guardia no sabrá si debe corregir propagación, conectividad o firma.

Dos formatos no son dos votos

CDS permite que el hijo controle el tipo de resumen incluido en el DS. CDNSKEY permite que el padre calcule ese resumen y aplique su propia elección. Como no existe un descubrimiento universal de la preferencia del padre, RFC 10026 exige publicar ambos cuando dicha preferencia no es conocida.

La duplicidad mejora la interoperabilidad, pero impone igualdad semántica. CDS y CDNSKEY deben identificar el mismo conjunto de claves. Si difieren, el padre rechaza la petición en lugar de elegir la versión que comprende mejor.

La política criptográfica tampoco puede congelarse en una constante de hace años. Los registros de IANA indican qué algoritmos de firma y qué resúmenes DS tienen estados adecuados para implementación y validación. Una decisión auditable conserva la política aplicada, los datos de entrada y el DS calculado.

La regla general es útil más allá de DNSSEC: dos expresiones firmadas que pretenden describir una sola transición no se convierten en una intención mediante una heurística. La parte emisora debe eliminar la ambigüedad.

El DS calculado debe conservar una cadena

La coherencia no garantiza seguridad. Un hijo puede servir uniformemente un conjunto que, convertido en DS, deje al validador sin ninguna ruta correcta. RFC 10026 obliga a comprobar que el resultado permite continuar la validación y a cancelar el cambio si la prueba falla.

En términos operativos, al menos una clave referenciada por el DS resultante debe validar la firma del RRset DNSKEY hijo con combinaciones criptográficas aceptables. Durante una rotación puede haber solapamiento entre claves viejas y nuevas; esa superposición es lo que permite que cachés con tiempos diferentes sigan validando.

Aquí se encuentra el mandato legítimo del agente parental. Debe proteger el vínculo de interoperabilidad que el padre publica. No necesita aprobar al proveedor DNS, la ubicación de los clientes ni el propósito económico del dominio. Los requisitos locales adicionales pueden ser válidos, pero han de ser explícitos, versionados y reproducibles.

La primacía del código en funcionamiento evita confundir documentos con realidad. Un RFC puede definir el mecanismo y un dominio puede publicar el registro, pero la adopción solo existe cuando las implementaciones realizan las comprobaciones, el padre publica y los validadores construyen la cadena.

La primera vez necesita otra raíz de autenticidad

Una delegación ya segura puede autenticar actualizaciones posteriores a través de su cadena DNSSEC. El alta inicial carece de ese DS parental. Una firma en el hijo no puede crear por sí sola el enlace del que dependería su autenticidad.

RFC 9615 resuelve gran parte del problema mediante señales autenticadas alojadas bajo zonas de señalización firmadas por el operador DNS. El agente parental valida esos dominios y usa la información _dsboot para autenticar los CDS/CDNSKEY del hijo todavía inseguro.

No todos los dominios encajan. Hay límites para nombres excesivamente largos y para delegaciones que usan únicamente servidores dentro del propio dominio. Por eso las capacidades deben declararse por operación: bootstrap autenticado, mantenimiento de una delegación segura y canal convencional no son la misma cosa.

RFC 8078 también define una señal explícita de borrado: CDS con algoritmo 0, tipo de resumen 0 y resumen 00. La ausencia de CDS no significa desactivar DNSSEC. Puede ser una publicación incompleta, una vista distinta o un secundario atrasado. Quitar el DS requiere una petición reconocible y todas las comprobaciones pertinentes.

NOTIFY reduce espera, no controles

La exploración periódica de millones de delegaciones puede ser lenta. RFC 9859 introduce DSYNC para que el padre anuncie un endpoint de notificaciones. El operador hijo descubre el destino y envía NOTIFY(CDS) cuando cambia sus CDS/CDNSKEY.

El mensaje es un disparador de lectura. El agente parental no usa su contenido como RRset autorizado. Vuelve a consultar los servidores, valida, compara, calcula y comprueba continuidad. Si la notificación se duplica, la operación debe ser idempotente. Si se pierde, un sondeo de reconciliación puede descubrir el cambio más tarde. Si se falsifica, los datos autoritativos sin cambios no producen un nuevo DS.

Esta arquitectura permite métricas precisas: destino descubierto, aviso recibido, recolección iniciada, consistencia alcanzada, decisión tomada, publicación observada y validación confirmada. Una entrega HTTP o DNS exitosa solo acredita la etapa que le corresponde.

El padre publicó; Internet aún está cambiando

Una aceptación puede quedarse en una cola de aprovisionamiento. La evidencia de publicación es el RRset DS observado en los servidores autoritativos del padre, junto con la versión de zona y el TTL. Aun entonces, resolvedores recursivos conservan la versión anterior hasta que caduca.

RFC 10026 recomienda que, tras un cambio, el nuevo RRset use temporalmente un TTL de aproximadamente cinco a quince minutos para facilitar un rollback. El valor normal se restaura después, nunca antes de que el conjunto anterior haya tenido tiempo de salir de las cachés.

Esa reducción no afecta a copias viejas ya almacenadas. Por ello, bajar primero el TTL antiguo en el mismo instante no acelera mágicamente la transición: ese valor antiguo también tendría que expirar. La planificación debe conocer el horizonte previo antes de retirar la clave que todavía necesitan algunos validadores.

Las sondas externas se ejecutan desde varias redes y durante al menos ese horizonte. Deben registrar DS visto, DNSKEY utilizada y resultado de validación. Un éxito demuestra una ruta; varios éxitos aumentan confianza. Ninguna muestra finita autoriza a afirmar convergencia universal.

Un sistema automático sin recuperación es una trampa

La rotación de claves es mantenimiento normal, por lo que un bloqueo ordinario de actualización en el registro o registrador no debería suspenderla por sí solo. Ese bloqueo suele limitar cambios desde un portal, no los actos del propio intermediario autorizado.

Al mismo tiempo, RFC 10026 exige otro canal para mantener DS. El hijo puede perder las claves, un operador puede no implementar la automatización o una migración puede enfrentar a dos fuentes de cambios. El canal alternativo debe autenticarse fuera del mecanismo roto y dejar un expediente equivalente.

Una acción manual puede establecer un nuevo baseline y pausar temporalmente la automatización. El peligro aparece cuando el sistema no sabe cuándo reanudarla o cuando el único procedimiento de rescate necesita precisamente la clave perdida.

Fuentes