Introducción
El servicio DNS de Cloudflare, Big Pineapple, maneja más de 250 mil millones de entradas en cache en cualquier momento. A esa escala, desperdiciar un solo byte por entrada equivale a 250 GB de RAM en toda la infraestructura. En un contexto donde el cache DNS debe responder millones de consultas por segundo con baja latencia, el uso eficiente de memoria no es solo un problema de costos, sino de rendimiento. Cada byte ahorrado reduce la presión sobre el garbage collector, mejora la localidad de cache y permite almacenar más entradas en el mismo hardware.
La optimización del cache DNS es un desafío único: las entradas son estructuras complejas con metadatos, múltiples registros DNS y datos de longitud variable. El lenguaje Rust, con su control preciso sobre el layout en memoria y su sistema de tipos, ofrece herramientas para eliminar el overhead oculto en estas estructuras. El equipo de Cloudflare implementó cinco optimizaciones sucesivas que redujeron el tamaño por entrada en más del 50%, liberando aproximadamente 100 TB de memoria en su flota, sin sacrificar velocidad.
Qué ocurrió
Between August 2023 and February 2024, Cloudflare rollout cinco cambios en el formato de almacenamiento de las entradas del cache DNS de Big Pineapple. Cada optimización redujo el footprint de memoria por entrada, con un impacto acumulativo que liberó alrededor de 100 TB de RAM en toda la infraestructura. Sorprendentemente, estas optimizaciones también mejoraron el rendimiento: el throughput de inserciones aumentó un 43% y la latencia de búsquedas disminuyó un 19%. Este resultado contrintuitivo se explica por la menor cantidad de allocaciones y la mejor localidad de memoria.
El cache DNS de Cloudflare almacena respuestas a consultas para evitar consultas recursivas repetidas. Cada entrada es una tupla clave-valor: la clave identifica la consulta (nombre de dominio, tipo de registro y, opcionalmente, el subred del cliente para EDNS Client Subnet), y el valor contiene la respuesta DNS (secciones answer, authority y additional), metadatos como el TTL y un contador de hits. Con EDNS Client Subnet (ECS) habilitado, los servidores autoritativos devuelven respuestas diferentes según la red del cliente, lo que multiplica el número de entradas en cache para el mismo nombre de dominio.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de infraestructura, este caso demuestra cómo optimizaciones a nivel de lenguaje pueden tener un impacto masivo en la eficiencia de servicios a gran escala. Liberar 100 TB de RAM equivale a la memoria de 130 servidores Gen 13 de Cloudflare, lo que permite reducir el hardware dedicado al cache DNS o reasignar recursos a otros servicios. En términos de costos, a precios actuales de RAM en la nube (aproximadamente USD 0.006 por GB/mes), 100 TB representan un ahorro de USD 600,000 mensuales.
Para equipos de seguridad, la reducción del uso de memoria fortalece la postura de seguridad. Menos memoria consumida significa menos superficie de ataque para exploits que corrompen datos en memoria (como las vulnerabilidades de tipo heap overflow o use-after-free). Además, un cache DNS más eficiente reduce el riesgo de ataques de cache poisoning: con más capacidad para almacenar entradas legítimas, hay menos oportunidades para que un atacante inserte respuestas falsas.
El impacto en rendimiento también es relevante para DevOps: un throughput de inserciones 43% mayor significa que el cache se llena más rápido durante un cold start o después de un cache flush, reduciendo la carga sobre los resolvers recursivos. La reducción del 19% en latencia de búsquedas se traduce en respuestas más rápidas para los usuarios finales.
Detalles técnicos
1. Reemplazar Vec y String por Box<[T]> y Box
En Rust, Vec
Cada entrada del cache de Big Pineapple usaba 8 campos de tipo Vec
2. Unificar las secciones DNS en una sola lista
Las respuestas DNS contienen tres secciones: answer, authority y additional. Originalmente, cada sección se almacenaba en un Box<[T]> separado, lo que implicaba 3 punteros (8 bytes cada uno) y 3 longitudes (8 bytes cada una). Al unificarlas en una sola lista con offsets a cada sección, se redujo el overhead a dos offsets de 2 bytes (ya que el número de registros por sección cabe en u16). Esto ahorró 28 bytes por entrada.
3. Eliminar el owner redundante en los registros DNS
Cada registro DNS tiene un owner (el nombre de dominio al que pertenece). En la mayoría de los casos, el owner coincide con el nombre consultado (por ejemplo, una consulta a example.com A devuelve registros con owner example.com). Sin embargo, cuando hay un CNAME involucrado, el owner puede diferir (por ejemplo, example.com CNAME foo.example.com puede devolver registros con owner foo.example.com).
Originalmente, cada registro almacenaba el owner completo. Esto era innecesario para el 80% de los casos, donde el owner se puede inferir de la clave del cache. La optimización consistió en:
- Eliminar el campo owner de los registros.
- Durante la construcción de la respuesta, si el owner coincide con el nombre consultado, usarlo directamente desde la clave del cache.
- Si el owner difiere, almacenar el nombre completo en un Box
en el registro.
Esta cambio ahorró 16 bytes por registro (el puntero y la longitud del String original). Dado que cada entrada contiene entre 1 y 4 registros, el ahorro promedio fue de 40 bytes por entrada.
4. Optimizar el enum de tipos de registros DNS
Los registros DNS pueden ser de diferentes tipos (A, AAAA, CNAME, TXT, etc.). Una implementación natural en Rust es usar un enum:
enum DnsRecord {
A { address: [u8; 4], … },
AAAA { address: [u8; 16], … },
CNAME { target: Box
NAPTR { … }, // 136 bytes
// otros tipos
}
El tamaño de un enum en Rust es el máximo de sus variantes, más el espacio para el tag (1 byte, pero alineado a 8 bytes). En este caso, la variante NAPTR (136 bytes) determinaba el tamaño del enum: 144 bytes. Sin embargo, los registros A (4 bytes) y AAAA (16 bytes) representan el 80% del tráfico. Esto significaba que la mayoría de los registros desperdiciaban más de 120 bytes de padding.
La solución fue boxear las variantes grandes:
enum DnsRecord {
A { address: [u8; 4], … },
AAAA { address: [u8; 16], … },
CNAME { target: Box
NAPTR(Box
// otros tipos
}
Ahora, las variantes pequeñas (A, AAAA, etc.) ocupan solo el espacio que necesitan, mientras que las grandes se almacenan en el heap. Esto reduce el tamaño del enum a 24 bytes (23 bytes de datos + 1 byte de tag, alineado a 24 bytes). Para registros A y AAAA, el ahorro es de 120 bytes por registro.
5. Agrupar flags booleanos en un bitflag
Varias flags booleanas (como authoritative, authentic data, recursive desire) se almacenaban como campos separados en el struct de la entrada. Cada bool en Rust ocupa 1 byte, pero debido al alineamiento, pueden introducir padding. Por ejemplo, si un struct contiene tres bool seguidos de un u32, el compilador inserta 1 byte de padding después de los booles para alinear el u32 a 4 bytes.
Al agrupar estas flags en un bitflags::BitFlags:
bitflags::bitflags! {
struct DnsFlags: u8 {
const AUTHORITATIVE = 0b00000001;
const AUTHENTIC_DATA = 0b00000010;
const RECURSIVE_DESIRED = 0b00000100;
// …
}
}
Se reduce el espacio de 1 byte por flag a 1 byte para hasta 8 flags. Además, al ocupar menos espacio, se reduce el padding en el struct. En el caso de Big Pineapple, esta cambio redujo el tamaño de la entrada en cache en 4 bytes.
Qué deberían hacer los administradores y equipos técnicos
Las lecciones de este caso son aplicables a cualquier sistema que maneje grandes cantidades de datos en memoria. Para equipos que desarrollan servicios en Rust:
Para equipos que no usan Rust, muchos de estos principios aplican a otros lenguajes. Por ejemplo, en Go, []byte tiene overhead similar a Vec
Conclusión
El caso de Cloudflare demuestra que, en sistemas a gran escala, incluso pequeñas optimizaciones a nivel de layout de datos pueden tener un impacto enorme. Reducir el uso de memoria no solo ahorra costos, sino que puede mejorar el rendimiento y la seguridad. Las herramientas que ofrece Rust —como control preciso sobre el layout en memoria, enums y patterns de ownership— hacen que este tipo de optimizaciones sean más accesibles y seguras que en otros lenguajes.
Para el cache DNS de 1.1.1.1, cinco cambios relativamente simples liberaron 100 TB de RAM y mejoraron el rendimiento. Este enfoque de optimización iterativa, guiado por mediciones, es un modelo a seguir para cualquier equipo que busque maximizar la eficiencia de sus servicios.
Fuentes
- https://blog.cloudflare.com/dns-cache-memory-optimization-1111/