Resumen

  • RFC 9563 asigna el algoritmo DNSSEC 17 a SM2 con SM3 y el tipo de resumen DS 6 a SM3, de modo que esos formatos pueden señalarse sin ambigüedad.
  • Es un RFC Informational del Independent Stream, no una especificación Standards Track; el propio documento dice que ni el IETF ni el IRTF analizaron la idoneidad de los algoritmos para este uso.
  • Entre el registro y una respuesta DNS confiable quedan la implementación del firmante, la delegación, la capacidad del validador, su política, la verificación y el resultado de la aplicación.

Un resolutor validador recibe una respuesta firmada cuyo campo de algoritmo contiene 17. El valor ya tiene una definición pública. Eso no obliga a que el software incluya SM2, a que soporte el resumen usado por el padre ni a que su política acepte la ruta. Incluso si la firma se verifica, el cálculo no cuenta quién custodió la clave privada. El número permite formular la pregunta correcta; no aporta todas las respuestas.

RFC 9563, publicado el 4 de diciembre de 2024, describe el encaje de SM2 y SM3 en DNSSEC. Reserva el número 17, con mnemónico SM2SM3, y el tipo DS 6. También delimita su autoridad: pertenece al Independent Stream, tiene categoría Informational y no representa consenso de la comunidad IETF. El texto declara que ni el IETF ni el IRTF estudiaron si SM2 o SM3 son adecuados para el propósito, y advierte de posibles debilidades intencionadas o no.

Esa declaración impide convertir la publicación en un aval que nunca se emitió.

El código fija el significado, no la adopción

Sin un código común, dos implementaciones no pueden expresar de manera fiable el mismo algoritmo en DNSKEY, RRSIG o DS. La asignación tiene una función concreta: crea un nombre interoperable para el formato y evita que interpretaciones privadas choquen.

Consultado el 27 de septiembre de 2026, el registro IANA de algoritmos DNSSEC marcaba como MAY el uso y la implementación del algoritmo 17 para firma y validación. El registro DS hacía lo mismo con el tipo 6. Es una fotografía fechada del registro, no un censo de despliegue, una autorización de compra ni un análisis de seguridad.

RFC 6014 organiza la política de asignación. Su superficie de control es el espacio de nombres: quién obtiene un valor, mediante qué revisión y qué denota. El registro puede ser correcto aunque ningún resolutor de una red concreta implemente la entrada. También puede haber código antes de que exista aceptación amplia. Una tabla normativa no es telemetría.

RFC 7841 añade el contexto editorial. La cabecera y el texto de estado indican la corriente de publicación y la categoría. El número RFC identifica una obra estable, pero no borra “Independent Stream” ni convierte el contenido en consenso del IETF.

Validar DNSSEC exige completar un camino

DNSSEC no consiste en comprobar una sola ecuación. RFC 4033 separa servidores autoritativos, resolutores con seguridad y anclas de confianza. RFC 4034 define DNSKEY, RRSIG, DS y los registros de negación. RFC 4035 exige construir una ruta de autenticación: seleccionar algoritmos admitidos, encontrar la clave, reconstruir datos canónicos, comprobar el intervalo temporal y verificar la firma dentro de una cadena aceptada.

Un producto puede reconocer el número 17 y carecer del cálculo SM2; puede implementar SM2 sin entender el resumen DS 6. El hijo puede publicar DNSKEY y el padre no ofrecer ningún DS utilizable. Aunque estén todas las primitivas, la política local puede no admitir el camino.

RFC 6840 explica una consecuencia decisiva. Un resumen DS no soportado se descarta igual que un algoritmo DNSKEY desconocido. Si no queda ningún DS admitido, la delegación puede tratarse como insegura, no como errónea. La zona está firmada y el registro es preciso, pero ese validador no tiene una ruta de autenticación que pueda ejecutar.

Por eso RFC 8624 mantiene recomendaciones de implementación y uso. La agilidad necesita solapamiento entre quienes firman y quienes validan. Su tabla es anterior a RFC 9563, por lo que no demuestra el soporte actual del algoritmo 17 ni del tipo 6. Ese dato debe medirse por producto, versión, biblioteca criptográfica, compilación, configuración y población real de resolutores.

Una firma válida responde a una pregunta limitada

RFC 9563 establece las codificaciones de clave pública y firma. Una verificación satisfactoria permite afirmar que los datos DNS canónicos corresponden a la firma bajo una clave, unas reglas y una ventana temporal concretas. No demuestra quién controlaba la clave privada, si el uso estaba autorizado, si la rotación preservó continuidad ni si la aplicación aceptó la dirección devuelta.

RFC 7583 trata generación, almacenamiento, rotación, compromiso y retirada como labores operativas. RFC 9563 también exige agilidad: si aparece una debilidad, puede ser necesario renovar DS, DNSKEY, RRSIG y NSEC3 respetando las cachés. El registro no ejecuta esa transición.

La cadena de evidencia debe conservar la procedencia del documento, el estado actual de IANA, la compilación y configuración del firmante, los DNSKEY/DS/RRSIG observados, las capacidades del resolutor, anclas y política, el registro de validación, la continuidad de la rotación y el resultado de la aplicación. Ningún recibo puede ampliar su alcance por cortesía.

La primacía del código en ejecución de Heng Lu ofrece una regla sencilla: autoridad simbólica, intención configurada, capacidad ejecutable y observación son realidades distintas. RFC 9563 permite nombrar SM2 y SM3. Para saber qué ocurrió después hay que mirar sistemas concretos.