Resumen

  • RFC 9904 es una RFC del IETF perteneciente al standards track, publicada en noviembre de 2025. Sustituye formalmente a RFC 8624 y actualiza RFC 9157.
  • Traslada los requisitos de implementación y las recomendaciones de uso de DNSSEC a los registros IANA DNS Security Algorithm Numbers y DS Digest Algorithms.
  • Las cuatro celdas no son intercambiables: lo que se pide al validador puede diferir de lo que se pide al firmante, y la recomendación para validar puede diferir de la recomendación para firmar.
  • La propia RFC 9904 no cambia ningún estado MUST, MAY, RECOMMENDED ni otro estado heredado. Un cambio posterior requiere Standards Action y debe explicar sus consecuencias para la transición y la interoperabilidad.

La novedad está en la forma de gobernar la información, no en una nueva clasificación de los algoritmos. RFC 8624 reunía los requisitos de implementación y la orientación de uso en una tabla estática. RFC 9904 coloca esa información en dos registros de IANA. De este modo, una futura RFC puede actualizar las columnas que correspondan mediante una acción de normalización concreta, sin tener que sustituir una tabla completa en otro documento general.

Para un mismo número de algoritmo hay cuatro preguntas: ¿debe implementarlo el validador?, ¿debe implementarlo el firmante?, ¿se recomienda para validar? y ¿se recomienda para firmar? Una etiqueta única como «compatible» no responde a todo. Después de RFC 9904, los registros de IANA son la referencia de las recomendaciones; el texto de las RFC sigue siendo la autoridad sobre el procedimiento que permite modificar esas columnas.

RFC 9157 aporta el contexto de las consideraciones de IANA para DNSSEC, y RFC 9364 aporta el contexto del protocolo para la autenticación DNSSEC y las pruebas de no existencia. El conjunto de fuentes congelado no permite afirmar nada sobre adopción actual, soporte de proveedores, incidentes, rendimiento, coste de migración o futuras conclusiones criptográficas.

Análisis de Theo March: para tomar una decisión puede ser útil conservar una copia fechada de los dos registros pertinentes, la fuente consultada y las cuatro celdas que se han tenido en cuenta. Cuando el entorno lo permita, el análisis también puede proponer una prueba de solapamiento entre el algoritmo antiguo y el nuevo, una comprobación separada de validadores y firmantes, un cambio gradual y material para volver atrás. Son prácticas del análisis de Theo March sobre gestión del cambio; RFC 9904 no las convierte en operaciones obligatorias.

La advertencia concreta de RFC 9904 es que retirar demasiado pronto un algoritmo puede hacer que una zona firmada solo con él parezca efectivamente sin firma para los validadores. La retirada debe estudiarse con cuidado y, preferiblemente, hacerse de forma gradual. El análisis de Theo March convierte esa advertencia en preguntas de trabajo: qué celda cambia, qué función está implicada, qué texto describe la transición y qué consecuencias de interoperabilidad deben revisarse. Las fuentes no indican si ese escenario es actual, habitual, rápido o costoso.

Pauta de decisión propuesta por Theo March

  1. Anotar: registra la versión y la hora de los registros IANA utilizados.
  2. Separar: identifica si la decisión afecta a la implementación del validador, a la del firmante, al uso para validar o al uso para firmar.
  3. Leer: revisa la Standards Action aplicable y la explicación de sus efectos en la transición y la interoperabilidad.
  4. Contrastar: cuando proceda, compara los caminos de firma y validación y examina los resultados de las pruebas de solapamiento.
  5. Dejar constancia: según el análisis de Theo March, conserva los elementos que expliquen la decisión y permitan valorar una vuelta atrás.

Esta pauta es una propuesta analítica de Theo March para gestionar el ciclo de vida; no añade requisitos a RFC 9904.

Fuentes