Resumen

  • Un ensayo de la Universidad de Twente y SIDN Labs ahorró once bytes en la firma Falcon-512 comprimida mediana frente a la variante fija con relleno. Al repetir consultas reales de .nl, ese ahorro apenas movió respuestas DNSSEC por debajo de los límites de tamaño analizados.
  • Las respuestas sobre nombres inexistentes llevaban varias pruebas firmadas y superaron todos los umbrales del estudio. Elegir un formato por el peso de una sola firma dejaría fuera la carga que realmente viaja.

El portero conoce el tamaño del grupo

En la puerta de una sala llena, uno de los invitados adelgaza once gramos. El portero mira la lista: viene acompañado por dos personas y tres maletas. Se acabó la discusión sobre el cinturón. La seguridad del DNS tiene un problema parecido. El paquete que debe cruzar la red no es una firma aislada, sino la respuesta completa, y algunas respuestas traen varias firmas.

La investigación publicada en 2025 por la Universidad de Twente y SIDN Labs comparó dos formas de firmar con Falcon-512 para DNSSEC. La forma comprimida produce firmas de longitud variable; la versión con relleno produce una longitud fija. En la zona de prueba, la firma comprimida mediana midió 655 bytes frente a 666 bytes fijos. Once bytes menos son una cifra defendible. La investigación hizo la pregunta incómoda: ¿cuántas respuestas completas pasan a caber en un mensaje de 1.232 o 1.500 bytes?

Los autores utilizaron la zona .nl del 3 de abril de 2025. Retiraron sus datos DNSSEC existentes, firmaron dos copias con Falcon-512 y repitieron un día de consultas registradas contra dos instancias de prueba de NSD. Para el análisis conservaron 59.312.128 respuestas que siguieron siendo NOERROR y 113.348.878 que siguieron siendo NXDOMAIN. La procedencia de las consultas era operativa; las respuestas con Falcon salieron de una reproducción experimental. Ese método permite medir tamaños con rigor sin convertir el ensayo en un anuncio de despliegue de .nl.

En las respuestas NOERROR, la mayoría ya cabía bajo ambos umbrales con cualquiera de los formatos. Había, sin embargo, un grupo menor y nada despreciable que se pasaba de tamaño. Un motivo era la prueba NSEC3 firmada adicional cuando faltaba el registro DS de un dominio hijo sin firma. El formato comprimido reducía algo el peso, pero casi nunca cambiaba el resultado de la prueba de entrada. El coste decisivo estaba en añadir otra prueba firmada.

Para NXDOMAIN, que informa de un nombre inexistente, el portero podía irse a tomar café: todas las respuestas analizadas superaban los dos límites. Las que incluían dos registros NSEC3 firmados medían entre 2.269 y 2.420 bytes; las que llevaban tres, entre 3.075 y 3.767. La compresión ahorra más bytes absolutos cuando hay varias firmas, pero ninguna de esas respuestas entró por la puerta de 1.232 o 1.500. Vender la diferencia de once bytes como solución de transporte sería una contabilidad hecha de espaldas al paquete.

Hay una curiosidad más. Entre 9.912.711 firmas de la zona experimental apareció una firma sin relleno de 667 bytes, uno más que el tamaño fijo de 666. La variante con relleno vuelve a generar la firma si excede su límite. El caso es rarísimo; su utilidad analítica consiste en recordar que «comprimido» describe una distribución, no una promesa de longitud idéntica para cada respuesta. Quien implementa debe hacerse cargo de los extremos de esa distribución.

Los autores concluyen que el formato fijo puede resultar preferible para DNSSEC por su previsibilidad y por reducir ocasiones de error de implementación, dado el escaso beneficio de la compresión en sus tamaños de mensaje. El estudio se concentra en tamaño, así que no calcula una factura total de CPU, memoria, hardware y despliegue. Tampoco elige por sí mismo un estándar. Sí desarma una justificación concreta: en el tráfico probado, la firma más corta no resolvió el problema de los mensajes demasiado grandes.

El resto de la mesa de decisiones sigue en movimiento. La página de estandarización poscuántica del NIST, actualizada el 27 de octubre de 2026, indica que Falcon fue seleccionado y que FIPS 206 aún está en desarrollo. Un borrador individual de Paul Hoffman, de ICANN, reúne los criterios que enfrenta DNSSEC: tamaño de registros, velocidad de adopción, CPU, cambios de protocolo, módulos de seguridad, criptoanálisis y patentes. El borrador carece de rango formal en el proceso de estándares del IETF. Su inventario, aun así, impide que una sola columna suplante a la discusión completa.

El programa de RIPE 93 anuncia que Ginevra Fabrizio expondrá el trabajo el 29 de octubre. El 28 de octubre no existe todavía una conclusión de esa charla que citar. El artículo científico ya ofrece un guion suficiente para interrogar cualquier propuesta: mostrar la zona, las consultas, las respuestas enteras, los límites atravesados y los costes de que la respuesta termine en TCP. Las medallas a la firma ligera deben entregarse después del control de acceso.

La unidad de medida también gobierna

Un comité puede ordenar formatos por un número limpio: bytes por firma. El DNS introduce nombres de longitudes distintas, tipos de consulta, delegaciones y pruebas de inexistencia. El propio estudio muestra que la variación de longitud de los nombres está en el mismo orden que la variación de tamaño de la firma comprimida. La cifra más fácil de poner en un titular no necesariamente dirige el comportamiento del mensaje completo.

La primacía del código que funciona exige un trámite humilde: probar propuestas contra patrones de consulta observados y publicar las distribuciones. Elegir el componente que gana en una tabla sin comprobar qué sucede al paquete entero concede autoridad a una abstracción. Cuando una respuesta sigue midiendo más de tres mil bytes, el portero no se conmueve por la dieta de once.