Resumen

  • RFC 9905 es un documento IETF Standards Track de noviembre de 2025 que actualiza RFC 4034 y RFC 5155.
  • RSASHA1 y RSASHA1-NSEC3-SHA1 MUST NOT crear registros DS, DNSKEY o RRSIG. Las delegaciones que solo tienen un DS afectado se tratan como inseguras cuando no existe otra ruta DS aceptada.
  • Las implementaciones de validadores MUST continuar implementando la validación con esos algoritmos. Esa obligación es distinta de la prohibición de firmar y del resultado de delegación insegura.

El mecanismo aparece en las propias filas del registro: la producción queda marcada como MUST NOT, mientras la implementación de validación conserva una obligación de continuidad. Por eso RFC 9905 no afirma que todos los validadores puedan eliminar SHA-1 ahora. Indica que los operadores deben trasladar sus zonas a algoritmos más fuertes recomendados por los registros de IANA, mientras el lado consumidor conserva la capacidad de validar los datos que aún existan durante la transición. El software que ya eliminó la validación SHA-1 puede necesitar una compilación manual para cumplir esa obligación.

La secuencia operativa tiene tres puntos de control separados. Primero, el firmante autoritativo debe dejar de generar DNSKEY y RRSIG RSASHA1 o RSASHA1-NSEC3-SHA1. Segundo, la delegación debe dejar de crear DS con esos algoritmos y publicar una ruta DS aceptada y más fuerte antes de retirar la anterior. Tercero, la infraestructura de validación recursiva debe conservar la implementación y probar que puede validar los datos heredados. Una configuración nueva del firmante no demuestra por sí sola que la delegación ni el conjunto de resolutores se hayan migrado.

Una transición controlada exige solapamiento. Publique y valide el material DNSKEY y RRSIG más fuerte, publique el DS correspondiente y observe validaciones recursivas correctas mientras la ruta antigua permanece solo como artefacto de transición. Registre respuestas autoritativas, conjuntos DS, recuperaciones DNSKEY/RRSIG, resultados de validación y tiempos relacionados con las cachés. La evidencia de reversión es igualmente concreta: conserve la configuración anterior de zona y claves, documente el último estado DS correcto y defina cómo restaurar la configuración aceptada sin crear material nuevo con SHA-1.

Revertir no equivale a tener permiso para reanudar una producción prohibida.

Comprobaciones concretas:

  1. Busque RSASHA1 y RSASHA1-NSEC3-SHA1 en la configuración del firmante y en las zonas generadas; el resultado debe ser cero para la producción nueva.
  2. Revise por separado la publicación de DS en el padre. Confirme que está presente el algoritmo más fuerte previsto y que una delegación solo SHA-1 no se trata como segura.
  3. Pruebe un validador recursivo con datos heredados controlados y con una zona que use el algoritmo más fuerte. Registre el resultado, la versión y las opciones de compilación.
  4. Compruebe si el software desplegado eliminó la validación SHA-1. Si lo hizo, planifique una compilación manual u otra implementación que cumpla la obligación de validación continua.

También es un problema de software-lifecycle-and-lock-in: una eliminación temprana puede borrar la compatibilidad necesaria para el parque instalado, mientras que un firmante sin cambios puede incumplir la nueva regla de producción. Las fuentes congeladas no aportan datos actuales sobre adopción, proveedores, incidentes, rendimiento ni cambios futuros del registro; esas cuestiones necesitan evidencia independiente.

Fuentes