Resumen

  • La referencia pública Delegation Key de ARIN identifica el tipo de condensado 3 como MD5 y anota una longitud de 32. IANA reserva ese número para GOST R34.11-94, hoy obsoleto.
  • La tabla no especifica la unidad de longitud. Los 256 bits de un condensado GOST equivalen a 32 octetos o 64 caracteres hexadecimales; no son prueba de las restricciones efectivas del servicio.
  • Las cuatro recomendaciones actuales de IANA indican MUST NOT para el tipo 3, conforme al RFC 9906. Sustituir el nombre incorrecto por GOST no lo convertiría en una opción admisible. No se probaron API, zonas ni resolutores.

Una discrepancia que cabe en una fila

La prueba no requiere interpretar una política extensa. En el apartado Delegation Key de los formatos Reg-RWS, ARIN publica una correspondencia: tipo de condensado 3, nombre MD5, longitud 32. En el registro IANA de tipos de condensado DS, el número 3 significa GOST R34.11-94. Son funciones distintas. El desacuerdo afecta a la identidad técnica del dato, no a la preferencia por una abreviatura.

Las páginas se capturaron el 14 de septiembre de 2026. Esa fecha delimita la observación, pero no permite fechar el origen del error ni atribuirle una duración. Tampoco convierte una tabla en una observación de producción. No se ha solicitado a ARIN que acepte ese dato, no se ha examinado una delegación privada y no se ha observado un registro público que contenga MD5 bajo el tipo 3.

Un registro DS lleva el número de tipo junto con el condensado. El receptor utiliza el número para identificar la función que representa el dato. El texto explicativo de una interfaz puede orientar a una persona; no puede reservar para esa interfaz una acepción diferente del número. La asignación registrada continúa teniendo significado aunque el algoritmo ya no deba utilizarse.

La consecuencia posible merece una frase condicional, no una denuncia de incidente. Si un autor de clientes calculase MD5 siguiendo la fila de ARIN y lo emparejase con el tipo 3, podría producir datos incompatibles con la función asignada. Las fuentes no demuestran que alguien haya hecho tal cosa. Demuestran que una referencia de aprovisionamiento ofrece un nombre incorrecto para ese campo.

El identificador necesita su campo

El formato incluye algorithm y digestType. El primero corresponde al algoritmo de DNSKEY; el segundo identifica la función del condensado DS. El catálogo publicado de algoritmos enumera, entre otros, 5, 7, 8, 10, 13, 14, 15 y 16, con nombres de RSA, ECDSA y EdDSA. No es la misma tabla que la de condensados, ni sirve para resolver sus asignaciones.

En esta última aparecen SHA1 para 1, SHA256 para 2, MD5 para 3 y SHA384 para 4. Las longitudes publicadas son 40, 64, 32 y 96. Describir esos valores no implica certificar una lista de algoritmos aceptados en producción. La documentación y el comportamiento ejecutado son dos objetos de prueba distintos, aunque ambos puedan ser relevantes para quien mantiene un cliente.

ARIN indica que los nombres se determinan a partir de los valores numéricos introducidos y que se descartan los nombres suministrados. En la interfaz descrita, escribir una denominación alternativa no sustituiría el significado del número. Esto aumenta la utilidad de una correspondencia fiable entre los campos numéricos y sus etiquetas, pero no prueba qué nombre devuelve actualmente el servicio.

El RFC 5933 ofrece un ejemplo claro de la separación: asigna 12 al algoritmo de firma DNSKEY ECC-GOST y 3 al condensado GOST R34.11-94. El tipo DS 3 no es un algoritmo DNSKEY numerado como 3. Tampoco es el campo de protocolo DNSKEY con valor 3 ni una etiqueta de clave que contenga ese entero. Los números repetidos no se vuelven intercambiables por aparecer cerca.

Qué representa el condensado

El RFC 4034 define el tipo de condensado DS como el identificador del algoritmo empleado para construirlo. También define la entrada del cálculo: el nombre propietario canónico de DNSKEY seguido de los datos del registro DNSKEY, incluidos indicadores, protocolo, algoritmo y clave pública. No basta con describirlo como el resumen de una cadena de clave que se vea en una pantalla.

Esta precisión importa porque una corrección de la etiqueta no resuelve por sí sola un error de entrada o de representación. Son problemas separables. El número determina la función; la especificación determina qué datos se procesan; el formato de presentación determina cómo se expresa el resultado. Una documentación útil no debería pedir al lector que deduzca uno de esos elementos a partir de otro.

La atribución original y el registro actual coinciden en GOST para el tipo 3. La marca de obsolescencia no convierte el código en un espacio libre para MD5. Tampoco hace necesario negar su existencia histórica. Identificar correctamente un dato antiguo y recomendar su generación son actos diferentes, con consecuencias distintas para las decisiones del operador.

No se sostiene aquí que MD5 esté ausente de todos los protocolos o de cualquier uso relacionado con DNS. El hallazgo es más concreto: MD5 no es la función asignada al tipo de condensado DS 3. Mantener esa delimitación evita que una comparación verificable de campos se convierta en una afirmación mucho más amplia que exigiría otras fuentes.

La cifra 32 no revela una validación

ARIN titula la columna Digest Length, pero no declara su unidad. Las filas vecinas de 40, 64 y 96 son coherentes con cantidades de caracteres hexadecimales. Esa pauta permite formular una hipótesis sobre cómo leer 32; no documenta un límite de longitud del servicio, una conversión interna o el orden de sus controles.

Según el RFC 5933, el condensado GOST tiene 256 bits. Ocho bits forman un octeto y cada octeto necesita dos caracteres hexadecimales. El resultado son 32 octetos y 64 caracteres en esa representación. El RFC 4034 expresa los condensados DS en hexadecimal sin distinguir mayúsculas de minúsculas y permite espacios, lo que añade otra razón para no confundir datos y texto formateado.

Si la columna pretende contar caracteres hexadecimales, 32 no representa la longitud de GOST bajo el tipo 3. Si pretende contar octetos, esa cifra sí corresponde al tamaño de GOST, pero las cifras vecinas necesitan una explicación diferente. La página deja abierta la unidad. La solución documental debe explicitarla, no convertir una inferencia del lector en una regla supuestamente comprobada.

Por tanto, no se ha demostrado que ARIN rechace un condensado de 64 caracteres ni que admita una cadena de 32. Tampoco se ha establecido cómo procesa espacios, cómo descodifica la entrada, qué errores emite o qué guarda. Serían preguntas válidas para evidencia específica del servicio. No son respuestas que pueda ofrecer una tabla de referencia sin una observación de ejecución.

Corregir GOST sin rehabilitarlo

El nombre verdadero viene acompañado de una prohibición actual. El RFC 9906, publicado en noviembre de 2025, retira ECC-GOST y GOST R34.11-94 del uso DNSSEC. Para el tipo 3, IANA indica MUST NOT en las cuatro columnas: uso en delegación, uso en validación, implementación para delegación e implementación para validación.

La recomendación histórica de implementación opcional en el RFC 5933 ayuda a explicar de dónde procede la asignación. No anula la retirada posterior. Una nota de mantenimiento no debería citar aquel texto como si concediese hoy un MAY de validación. El lector necesita dos datos a la vez: el significado histórico correcto del número y la recomendación vigente de no utilizarlo.

Un catálogo puede conservar la descripción de identificadores que aparecen al inspeccionar, modificar o retirar configuraciones antiguas. Eso no equivale a recomendar datos nuevos. Este artículo no ha probado una función de compatibilidad o eliminación de ARIN. La posibilidad descriptiva no se presenta como una capacidad real del servicio, sino como una razón para distinguir identificación y autorización.

El RFC 9906 también evita confundir estados de validación. Cuando solo existe una vía basada en los algoritmos retirados y no hay otra vía de autenticación aceptable, prescribe el tratamiento insecure, en lugar de validar con ellos y clasificar la cadena como bogus. Ninguno significa simplemente que un nombre sea inalcanzable. No se ha medido aquí ese estado en una zona de ARIN.

Un límite entre padre e hijo

La guía de DNS inverso de ARIN describe el contexto del aprovisionamiento: después de asegurar una zona inversa, el operador puede comunicar sus datos DS al padre y administrarlos por delegación mediante ARIN Online o el servicio RESTful. El campo examinado interviene, pues, en una frontera concreta entre los datos de la zona hija y la información publicada del lado padre.

Administrar datos DS del padre no equivale a firmar la zona hija, publicar sus registros DNSKEY o controlar los resolutores que puedan consultarla. La fila equivocada podría influir en una interpretación local sin atravesar toda esa cadena. Las páginas no permiten reconstruir el resultado de cada delegación ni atribuir un fallo a sistemas que esta investigación no examinó.

La petición proporcionada es pequeña y precisa: reconciliar la tabla con la asignación, declarar la unidad de longitud y separar el estado retirado del tratamiento actual del servicio. Si se discute este último, debe existir evidencia datada y reproducible aparte. No hay fundamento aquí para borrar datos DS por precaución, iniciar una transición de claves no probada o ampliar los poderes de ARIN sobre recursos numéricos.

Fuentes