Resumen

  • RFC 9904 trasladó a IANA la fuente canónica de recomendaciones separadas sobre uso e implementación de algoritmos DNSSEC para firma, delegación y validación.
  • RFC 9905 exige dejar de crear material SHA-1, pero conservar su validación mientras desaparece. Esa asimetría evita nuevas dependencias sin confundir una política actualizada con una migración terminada.

Un inventario enseña dos verdades incómodas en la misma pantalla. IANA marca RSASHA1 como MUST NOT para firmar; una zona todavía publica RRSIG y DNSKEY de ese algoritmo. La tentación es elegir una de las dos como «la realidad». La operación correcta consiste en registrar ambas y reconstruir qué transición falta entre ellas.

La RFC 9904, de noviembre de 2025, reemplaza el catálogo estático de la RFC 8624 por dos registros IANA como fuente canónica. La ficha del RFC Editor conserva su identidad y la relación con la RFC 9157. No cambió por sí misma los niveles heredados: cambió el lugar donde las decisiones posteriores se publican.

El registro de algoritmos DNSSEC responde cuatro preguntas, no una. ¿Conviene usar el algoritmo para firmar? ¿Conviene usarlo para validar? ¿Debe implementarlo el firmante? ¿Debe implementarlo el validador? El registro de algoritmos de resumen DS separa de igual modo creación y validación de delegaciones. «Compatible» deja de ser una respuesta suficiente.

La RFC 9905 aplicó el nuevo mecanismo a SHA-1. Prohíbe crear DNSKEY, RRSIG y DS con RSASHA1 o RSASHA1-NSEC3-SHA1, pero exige que las implementaciones validadoras conserven soporte. No es una concesión retórica. Los firmantes pueden dejar de generar hoy un algoritmo que los validadores aún necesitan para interpretar material heredado.

El registro tampoco conoce el estado de una zona concreta. Esa prueba vive en la versión del software firmante, su configuración, el número de serie, los conjuntos DNSKEY y RRSIG emitidos, el DS publicado por el padre y lo que observan autoridades y recursivos. Cada capa tiene propietario, canal y reloj propios.

La semántica del resultado merece igual cuidado. RFC 9364 reúne el marco DNSSEC; RFC 4035 diferencia secure, insecure, bogus e indeterminate. RFC 9905 ordena tratar como insecure determinados caminos SHA-1 sin alternativa aceptada. No autoriza a declarar que cualquier presencia de SHA-1 produce el mismo desenlace.

La secuencia de retirada protege la disponibilidad. RFC 9904 advierte que cambiar a la vez el algoritmo DS y la nueva KSK puede romper la validación, y exige actualizar primero el algoritmo DS. RFC 6781 explica la publicación y retirada escalonada de RRSIG, DNSKEY y DS, dejando expirar datos anteriores en cachés. Un cambio correcto fuera de orden puede ser un fallo completo.

Por eso el cierre debe unir: instantánea IANA y RFC que la autorizó; binario y configuración del firmante; serial y huellas de RRsets; recibo de la operación en el padre; observaciones desde varios puntos; TTL previstos y reales; versiones de validadores; clasificación del resultado; errores, reversión y objetivo del servicio. Un ticket «completado» sin esa cadena solo prueba que cerró el ticket.

La especificación inicial mínima de Heng Lu mantiene estrecha la obligación común. La primacía del código en ejecución lleva la verificación a los RRsets y validadores reales. Las capas de realidad impiden convertir una celda normativa en autoridad sobre el servicio. Es una lectura editorial declarada, no otra norma IETF.

IANA puede declarar que ya no deben nacer nuevas firmas SHA-1. La retirada termina cuando el sistema distribuido aporta sus propios recibos.

Sources