Cloudflare anunció los resultados de una serie de optimizaciones de bajo nivel en el almacén DNS de la plataforma Big Pineapple, la plataforma que ejecuta 1.1.1.1, Gateway DNS, DNS Firewall, AS112 y varios otros servicios DNS. La plataforma almacena más de 250.000 millones de entradas DNS en cualquier momento, por lo que eliminar un solo byte por entrada ahorra más de 250 gigabytes de memoria a escala de la flota.
Cinco cambios sucesivos en la estructura de datos escrita en Rust redujeron el tamaño de cada entrada de 953 bytes a 420 bytes, es decir, un 56 %. Tras implementar los cambios en toda la plataforma, la memoria del conjunto de trabajo utilizada en la flota de Cloudflare disminuyó aproximadamente 100 terabytes, con una mejora del rendimiento en lugar de un sacrificio: la velocidad de inserción de entradas aumentó un 43 % y la latencia de búsqueda en el almacén disminuyó un 19 %.
¿Por qué era importante el tamaño de una entrada DNS?
Big Pineapple comienza con un almacén vacío al iniciarse y se llena a medida que llegan las consultas hasta alcanzar el límite máximo; entonces se eliminan las entradas más antiguas o menos utilizadas. El tamaño del almacén varía entre los centros de datos, y el uso de EDNS Client Subnet también puede provocar que se almacenen varias respuestas para la misma consulta, ya que los servidores authoritative pueden proporcionar respuestas diferentes según la red del cliente.
Cada entrada consta de una clave que identifica el nombre de dominio, el tipo de registro y algunos atributos, y de un valor que contiene una respuesta DNS, las secciones authority y additional, y metadatos como la hora de creación, un contador de usos y el TTL. A esta escala, los campos sobrantes o el espacio reservado dejan de ser pequeños detalles internos y se convierten en un enorme coste operativo.
¿De dónde procedieron los ahorros?
Cloudflare sustituyó las estructuras Vec y String ampliables por estructuras de tamaño fijo, Box<[T]> y Box<str>, después de almacenar la respuesta, porque los datos no se modifican posteriormente. Este cambio eliminó el campo de capacidad que mantienen las estructuras ampliables y también limitó el espacio reservado sin utilizar. Como cada entrada contiene ocho campos de este tipo, el ahorro fue de 64 bytes por entrada y de más de 15 terabytes en todo el almacén.
También se combinaron las listas de las secciones de respuesta, autoridad y adicionales en una sola lista, utilizando desplazamientos de tipo u16 en lugar de punteros y longitudes mayores. Esto permitió ahorrar 28 bytes por entrada. La estructura también aprovechó la compresión de varios campos booleanos en un único bitflag, lo que redujo el espacio desperdiciado por la alineación de memoria que Rust impone dentro de las estructuras.
En la mayoría de los registros DNS, el propietario del registro coincide con el dominio consultado. Por ello, Cloudflare dejó de almacenar el nombre completo del propietario en esos casos y lo recupera de la clave de almacenamiento al construir la respuesta. Cuando el nombre es diferente, como ocurre con los registros CNAME, se almacena el nombre completo. Así se eliminaron las asignaciones de memoria para la mayoría de los nombres de propietarios, manteniendo los casos que realmente necesitan el nombre.
Reducir el coste de los tipos de registro grandes
La estructura RecordData utilizaba un enum cuyo tamaño era igual al del tipo de registro más grande: NAPTR, con 144 bytes después de contabilizar la etiqueta y la alineación. Como resultado, los registros A, que solo necesitan 4 bytes, y los registros AAAA, que necesitan 16 bytes, ocupaban mucho más espacio del necesario, aunque A y AAAA representan más del 80 % del tráfico de prueba.
Se probó colocar los tipos grandes dentro de un Box separado, lo que redujo el desperdicio en los registros A y AAAA, pero añadió asignaciones independientes y problemas de locality de memoria. La solución final fue almacenar los datos de los registros como bytes sin procesar contiguos dentro de Box<[u8]>, con un prefijo de longitud de dos bytes para cada registro. Esto eliminó el coste del enum y de las múltiples asignaciones, y mejoró el aprovechamiento de la memoria caché del procesador.
Esta elección significa que los registros ya no permiten un acceso aleatorio por índice, sino que deben recorrerse secuencialmente. Cloudflare considera que el coste es limitado porque el número de registros de cada entrada es pequeño. Además, la mayoría de los tipos, incluidos A, AAAA, TXT y los registros DNSSEC, pueden copiarse directamente al mensaje DNS saliente, mientras que los tipos que contienen nombres de dominio, como CNAME, NS, MX y SOA, todavía necesitan analizarse para aplicar la compresión de nombres DNS.
¿Qué cambió en la práctica?
Las mediciones en producción mostraron una reducción de la memoria residente en el percentil 99, de 9,3 a 5,3 gigabytes, es decir, un 43 %, y de 6,5 a 3,8 gigabytes en el percentil 90, es decir, un 42 %. Las asignaciones por entrada disminuyeron de 1,1 kilobytes a 461 bytes, mientras que la velocidad de inserción aumentó de 625.000 entradas por segundo a 893.000, y la latencia de búsqueda bajó de 828 nanosegundos a 670 nanosegundos.
El despliegue de los cambios comenzó el 18 de mayo de 2026 y se completó en todos los servicios el 6 de julio de 2026. Cloudflare señala que la memoria residente en producción incluye otros datos además del almacén, por lo que el porcentaje de reducción efectivo a nivel de proceso fue menor que el resultado de la medición aislada por entrada. La empresa también planea reinvertir la memoria liberada en aumentar la capacidad del almacén sin incrementar el consumo de memoria, con el objetivo de mejorar las tasas de aciertos de la caché y reducir las consultas enviadas a los servidores ascendentes.
La importancia de este caso reside en que muestra que las mejoras en las estructuras de datos, como eliminar capacidad innecesaria, agrupar asignaciones y mejorar la locality, pueden tener un efecto mayor que añadir recursos de hardware directamente cuando un servicio opera con cientos de miles de millones de elementos. Sin embargo, persisten algunas concesiones: el almacenamiento sin procesar aumenta la complejidad de gestionar los registros, recuperar la clave de almacenamiento se vuelve necesario para reconstruir los nombres de los propietarios y los resultados de las pruebas dependen de una combinación de tráfico concreta que no coincide completamente con la producción. Por ello, las mediciones en producción, y no solo las cifras teóricas, siguen siendo la referencia más importante al evaluar este tipo de optimizaciones.