Cloudflare publicó el 27 de agosto de 2026 una optimización de escala poco habitual en el mecanismo que sirve 1.1.1.1: cinco cambios en la representación de las entradas de caché liberaron unos 100 terabytes de memoria y redujeron un 19% la latencia interna de búsqueda.
El resultado importa porque la caché es la ruta rápida de un resolver. Mientras una respuesta sigue siendo válida, el servicio no tiene que repetir todo el recorrido hasta los servidores autoritativos. Localiza los datos, ajusta los campos necesarios y responde al usuario.
La cifra del 19% debe interpretarse bien. La medición bajó de 828 a 670 nanosegundos dentro del proceso de caché. No afirma que cada consulta entre un teléfono y 1.1.1.1 sea un 19% más rápida en cualquier red.
La escala de la caché de 1.1.1.1
La plataforma Big Pineapple de Cloudflare sostiene 1.1.1.1, Gateway DNS, DNS Firewall, AS112 y otros servicios. Según la empresa, mantiene más de 250 mil millones de entradas de caché en un momento dado.
A esa escala, desperdiciar un byte por entrada cuesta más de 250 GB en toda la flota. Cloudflare optimizó las estructuras en Rust que almacenan la clave de consulta, registros, TTL, hora de creación, contadores y errores extendidos.
Su benchmark aproximó la mezcla de producción:
- 56% de registros
A; - 25% de registros
AAAA; - 19% de registros
TXT, como sustituto de tipos de longitud variable; - entre uno y cuatro registros por entrada.
El equipo también midió memoria residente en instancias de producción durante el despliegue, iniciado el 18 de mayo y completado el 6 de julio de 2026.
Los resultados
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Memoria neta por entrada | 953 bytes | 420 bytes | -56% |
| Asignaciones por entrada | 1,1 KB | 461 bytes | -58% |
| Inserciones en caché | 625 mil/s | 893 mil/s | +43% |
| Latencia de búsqueda | 828 ns | 670 ns | -19% |
La memoria total del proceso en producción cayó menos del 56% porque incluye código y datos ajenos a la caché. Aun así, en p99 bajó de 9,3 GB a 5,3 GB por instancia. La reducción agregada fue de unos 100 TB, equivalente, según Cloudflare, a la RAM de 130 servidores de su generación 13.
Cómo menos memoria también aceleró la caché
Ahorrar memoria puede añadir procesamiento. Aquí, varios cambios redujeron ambos.
Una estructura genérica puede reservar espacio para el mayor tipo de registro incluso si contiene un A o AAAA pequeño. Otros diseños crean muchas asignaciones separadas en el heap. Ambos desperdician bytes y dispersan datos, obligando al procesador a seguir punteros hasta regiones distintas.
El diseño final almacena los datos de registros DNS en un búfer compacto y contiguo en formato binario. Los tipos comunes pueden copiarse casi directamente a la respuesta. Solo los registros que contienen nombres, como CNAME, NS, MX y SOA, necesitan procesamiento para la compresión DNS.
Menos asignaciones y mejor localidad de memoria explican el aumento de inserciones y la caída de latencia pese a usar menos RAM.
¿Hace más rápida la conexión del usuario?
Puede ayudar, pero no en proporción directa al 19%. Una consulta medida en un móvil suele durar milisegundos, no nanosegundos. El tiempo total incluye:
- Wi-Fi o red móvil hasta el router;
- ruta del proveedor al punto de presencia anycast;
- procesamiento del resolver;
- ante un fallo de caché, consultas a raíz, TLD y autoritativo;
- validación DNSSEC y posibles reintentos.
Ahorrar 158 nanosegundos es poco frente a un viaje de 10 o 30 milisegundos. El efecto más interesante puede llegar después: Cloudflare quiere reinvertir la memoria liberada en mayor capacidad de caché. Más entradas pueden elevar los aciertos y evitar consultas externas mucho más costosas.
El beneficio tampoco es uniforme. TTL cortos, nombres raros y variantes por EDNS Client Subnet reducen la reutilización. Los dominios populares con TTL adecuado se benefician más.
Cómo buscar la diferencia en un benchmark
No compares una consulta anterior al anuncio con otra posterior. Ruta, congestión y estado de caché producen variaciones mayores que esta optimización interna.
Usa un método repetible:
- ejecuta varias rondas en el mismo dispositivo y conexión;
- compara Cloudflare, Google, Quad9 y el DNS del proveedor en la misma ventana;
- separa consultas calientes y repetidas de nombres aleatorios que provocan fallos de caché;
- registra mediana, P95, jitter y tasa de éxito;
- repite en distintos horarios y confirma el endpoint alcanzado.
Una mejora consistente de P95 o estabilidad es más útil que una diferencia mínima en la media. Consulta cómo comparar Cloudflare y Google DNS y cómo encontrar el DNS más rápido.
Qué demuestra realmente la noticia
La optimización no convierte a 1.1.1.1 en ganador universal. El resolver más rápido aún depende del proveedor, ubicación, ruta anycast, horario y tipo de consulta.
Demuestra que eficiencia de memoria y velocidad están conectadas en un resolver global. Compactar cientos de miles de millones de objetos deja espacio para una caché mayor, reduce presión sobre el asignador y ahorra trabajo de CPU. El efecto por consulta puede ser sutil, pero se multiplica a escala y puede mejorar capacidad y consistencia.
