Resumen

  • ICANN pide revisar si su evaluación de seguridad de la automatización DNSSEC de registros DS identifica los riesgos y propone medidas suficientes, proporcionadas y aplicables.
  • La conclusión favorable depende de siete requisitos obligatorios y siete aspectos que cada operador debe documentar; no es una autorización universal.

La cuestión de los bloqueos es la prueba concreta que ICANN debe resolver antes de acelerar la vía DNSSEC. El aviso de consulta pública fija el plazo y el alcance de la revisión.

El informe de Interisle, fechado el 23 de junio, se limita a un mecanismo. El operador de la zona hija publica registros CDS o CDNSKEY; el agente parental —normalmente un registro o registrador— los comprueba antes de actualizar el DS en la zona padre. La evaluación cubre mantenimiento, primera provisión y transición a una delegación sin DNSSEC. Excluye notificaciones push, API externas y CSYNC. Por eso su conclusión no certifica todos los diseños ni el servicio de una empresa concreta. El informe concluye que el mecanismo no plantea problemas significativos de seguridad o estabilidad cuando se cumplen las condiciones que enumera. El documento completo deja esa condición en el centro de la propuesta.

Siete requisitos son el suelo técnico para una evaluación positiva. El padre debe comprobar que cada DS anunciado corresponde a una clave DNSKEY de la zona hija y que el conjunto DNSKEY está firmado por una clave indicada en el nuevo DS. También debe contrastar las respuestas de todos los servidores autoritativos y detener el cambio si no coinciden. El informe exige mantener una interfaz manual, permitir que los registradores excluyan dominios de la automatización, procesar correctamente la retirada del DS y notificar al registrador cuando el registro cambia la zona padre.

Otros siete puntos deben documentarse, como la frecuencia de consulta, el tiempo de respuesta, la política para múltiples firmantes y quién recibe los avisos. Cuatro prácticas adicionales se recomiendan, pero no son condición de la conclusión.

El diseño diferencia obligaciones comunes de opciones locales. La coherencia entre servidores de nombres, ya exigida por RFC 9975, no es una preferencia del operador. En cambio, la frecuencia con que se consultan los datos y la forma de avisar influyen en cuánto tarda una corrección y en quién puede detectar un problema. Una actualización rechazada o un DS que ya no coincide con las claves puede permanecer invisible hasta que fallen las consultas de los usuarios. El informe reconoce la falta de un mecanismo de aviso normalizado para todos esos casos y la convierte en una cuestión de transparencia.

La fecha del análisis también merece revisión. El informe está fechado el 23 de junio; RFC 10026 se publicó como Best Current Practice de la IETF en julio. La página de la consulta ya incluye RFC 10026 entre los documentos de apoyo, mientras que el cuerpo del informe fechado en junio conserva la cronología anterior del borrador. Ya lo alcanzó: RFC 10026 trata los controles de aceptación, la información sobre resultados, los bloqueos y las actualizaciones concurrentes. Esto no invalida el trabajo de junio, pero permite preguntar si la lista de siete requisitos y siete divulgaciones refleja la guía definitiva y cómo se probará esa correspondencia.

La diferencia aparece en el análisis de los bloqueos. El informe adopta la posición de SAC126: un bloqueo serverUpdateProhibited debe detener la automatización dirigida por el registro, mientras que clientUpdateProhibited por sí solo no debe hacerlo. El texto final del IETF toma la postura contraria sobre el bloqueo del registro: RFC 10026 dice que la automatización del propio registro no debe suspenderse únicamente por ese estado, que el registro puede reemplazar; la exclusión solicitada por el registrador es el control para expresar una preferencia distinta. La lista consolidada de requisitos obligatorios sí incluye el bloqueo del cliente, pero no formula una regla paralela para el bloqueo del registro. Como la página actual de ICANN cita RFC 10026, los comentarios pueden pedir qué criterio regirá las solicitudes futuras y las cláusulas contractuales.

El consejo de ICANN había ordenado en septiembre de 2025 crear una vía rápida RSEP para los registros, siempre que no se detectaran problemas de seguridad o estabilidad. También señaló que los registradores no necesitan aprobación de ICANN para desplegar el servicio. RSEP mantiene una evaluación preliminar y puede remitir los casos de riesgo importante a un panel técnico. La evaluación pretende ofrecer una base común para futuras solicitudes; no aprueba una implementación ni elimina el examen de cada propuesta. La resolución de la junta y la política RSEP describen el proceso.

Los comentarios pueden comprobar si las siete condiciones se alinean con el BCP 246, si las divulgaciones explican de verdad la latencia, las alertas y la recuperación, y si el futuro texto contractual mantiene una evaluación adaptada a cada diseño. Como la consulta del borrador de cláusulas vendrá después, el resumen de comentarios y esa siguiente etapa deberán leerse por separado. La lista es un instrumento para evaluar solicitudes; no demuestra por sí misma que un cambio sea seguro en todos los registros.