Resumen

  • El 12 de septiembre, el directorio de LACNIC mostraba 150 archivos de datos de DNS inverso: 75 nombres numéricos de tres cifras y 75 nombres equivalentes bajo in-addr.arpa.
  • Había 150 firmas separadas, una clave pública y una suma MD5 por nombre. La pareja de muestra era idéntica byte por byte, pero ningún manifiesto enumeraba el lote esperado.
  • Esto no demuestra una omisión, una firma inválida ni una avería del DNS. Revela una diferencia precisa entre autenticar un archivo y acreditar una generación completa.

Para un consumidor que ya sabe que necesita 002-LACNIC, el directorio resulta bastante claro. Puede descargar el archivo, la firma .asc del mismo nombre y la línea MD5. La clave pública está en el mismo nivel. Hay un camino visible para comprobar la pieza.

El panorama cambia al intentar replicar todo el directorio. En la captura aparecieron 150 nombres de datos. La mitad usaba tres dígitos, como 002-LACNIC; la otra mitad expresaba el mismo número como 2.in-addr.arpa-LACNIC. Las 75 parejas estaban presentes. También había 150 entradas de firma y 151 de MD5, porque el índice incluía además el nombre comodín vacío *-LACNIC.md5.

No apareció un README, un manifiesto, un índice SHA-256, un identificador de versión ni un archivo de publicación. Por sí sola, esa ausencia no indica que el generador haya cometido un error. Indica que la lista de miembros del lote no forma parte de la evidencia firmada que recibe el público.

La pareja que sí se pudo comprobar

Los dos nombres del ejemplo contenían 2.222 bytes y compartían el SHA-256 53986e…de697. La suma MD5 publicada para 002-LACNIC también coincidió con la calculada sobre los bytes descargados. Los encabezados HTTP fijaban sus últimas modificaciones con un segundo de diferencia.

El resultado más prudente es positivo y limitado: la pareja de muestra era equivalente en el instante observado. No se compararon las 75 parejas. Un segundo entre dos escrituras no es señal de incoherencia. Y el contenido, compuesto por directivas y delegaciones NS, no es una consulta al servicio DNS activo ni un certificado de que todos los servidores cargaron el mismo estado.

La firma separada merece la misma precisión. El RFC 9580 permite firmar datos que permanecen fuera del objeto de firma. Con una clave aceptada y un verificador operativo, eso puede vincular un archivo concreto con la firma. Este trabajo no pudo ejecutar esa verificación porque el entorno local carecía de la herramienta OpenPGP. Por tanto, no afirma que la firma sea válida ni inválida.

Archivo, par y lote son tres objetos

El archivo responde a una pregunta: ¿son estos los bytes que esperaba comprobar? El par introduce otra: ¿qué relación tiene el nombre corto con el nombre DNS? El lote agrega una tercera: ¿cuál era el conjunto completo que LACNIC declaró terminado?

Una firma individual no puede responder por los otros 149 nombres. El índice HTML sí permite contar lo que el servidor mostró, pero ese recuento depende del momento de la visita. Los tiempos Last-Modified son metadatos del transporte, no un compromiso firmado sobre la versión conjunta.

MD5 tampoco rellena el hueco. El RFC 6151 ya no lo considera aceptable donde se exige resistencia a colisiones, aunque reconoce un uso acotado para detectar errores. Aquí, una coincidencia MD5 ayuda a comprobar la transferencia. No identifica al publicador y no anuncia qué archivos faltan o sobran.

La mejor defensa de la granularidad actual

Tal vez no exista la intención de ofrecer una instantánea. Un repositorio de archivos independientes permite que cada usuario descargue sólo el fragmento conocido, conserve su caché y actualice una pieza sin trasladar todas. Para ese contrato, una lista global puede ser innecesaria.

Además, LACNIC ya publica más evidencia que un simple enlace de descarga. La presencia de firmas y clave es una base valiosa. No conviene degradarla porque falte una capa distinta. La crítica correcta consiste en preservar el control por archivo y añadir una prueba cuando el caso de uso sea copiar el conjunto.

Esa prueba puede ser pequeña. Un manifiesto firmado debería incluir versión, identificador del lote, hora de generación, hora de cierre y la lista ordenada de archivos. Para cada uno: pareja, función del nombre, tamaño, SHA-256 y firma asociada. También debería señalar la huella de la clave autorizada y el lote anterior.

Un estado explícito de publicación terminada impediría confundir una actualización en curso con un lote defectuoso. Una corrección posterior crearía una versión nueva y conservaría la anterior como reemplazada. Si dos nombres de una pareja debieran diferir, el manifiesto podría declararlo en lugar de obligar al consumidor a adivinar.

El manifiesto no tendría que afirmar que el archivo es la zona viva, que una delegación funciona o que un resolutor obtiene la respuesta correcta. Ésas son verificaciones posteriores. Su tarea sería más modesta: convertir 150 controles aislados en un registro de composición.

LACNIC ya sella las páginas. Le falta sellar el índice que dice cuáles páginas forman la edición.

Fuentes