Cloudflare recorta 85% la memoria de su DNS global

Qué cambió en el pipeline de DNS de Cloudflare

El Zone Builder de Cloudflare pasó de procesar unas 250 modificaciones de registros DNS por segundo en 2022 a unas 700 en la actualidad, más unos 100 eventos adicionales por segundo, como cambios de configuración de zona. Con un nuevo planificador de builds dirigidos y un scheduler unificado, la compañía redujo el pico de memoria de su flota en un 85% y recortó a la mitad el tiempo que tarda un cambio de DNS en quedar escrito en Quicksilver, su almacén distribuido de clave-valor.

Para un founder, la noticia no es el ahorro de RAM en sí. Es el método: cómo una empresa que sirve infraestructura crítica para buena parte de internet desarmó un cuello de botella sin reescribir el sistema desde cero, y qué de ese método se puede copiar en un equipo de producto mucho más chico.

Cómo funciona el pipeline que convierte un cambio en datos servibles

Una zona DNS es el conjunto de registros y configuraciones de un dominio. Cuando un cliente cambia un registro desde el panel o la API, o cuando otro servicio de Cloudflare modifica una configuración de zona, el cambio se guarda en una base de datos y se emite un evento a Kafka. El DNS Kafka Aggregator combina eventos de varios topics y los envía al Zone Builder, que lee los datos necesarios, los convierte al formato que entienden los servidores DNS autoritativos y compara el resultado con Quicksilver. Solo escribe lo que cambió.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Ese trabajo se llama build, y cada evento arranca un reloj que mide cuánto tarda. El problema nunca fue la cantidad de eventos: fue el tipo de trabajo que algunos exigían y cómo ese trabajo crece con el tamaño de la zona. Algunas zonas ya superan los 20 millones de registros, y la compañía espera que sigan creciendo hacia los cientos de millones.

Por qué los builds completos dejaron de escalar

El Zone Builder original tenía una virtud: no necesitaba saber por qué había cambiado una zona. Reconstruía el estado deseado desde la base de datos, leyendo cada registro, codificándolo y comparándolo. La escritura final contenía solo las claves modificadas, pero el proceso completo exigía leer y mantener toda la zona en memoria.

Eso es barato en una zona pequeña y directamente imposible en las más grandes, que no caben en memoria. En 2022, los builds por registro eran 150 veces más rápidos que los builds completos en promedio, y 4.250 veces más rápidos en una zona de prueba de un millón de registros. El siguiente paso obvio era hacer lo mismo con las configuraciones de zona, y ahí estaba la dificultad: un evento de registro dice qué cambió, pero un evento de configuración puede venir de muchos productos distintos, no explicar el motivo y alterar datos compartidos por varias zonas con el mismo nombre.

Los cinco tipos de build y la regla de oro

El planificador elige el build más pequeño que puede demostrar seguro. Hay cinco tipos:

Solo recursos: reconstruye los registros de nombres DNS específicos sin tocar los metadatos de la zona. Es el camino habitual de los cambios A, AAAA, TXT y CNAME.
Recursos y metadatos: reconstruye nombres específicos y metadatos compartidos. Lo usan los cambios de nameservers y wildcards.
Apex y metadatos: reconstruye el ápice de la zona y los metadatos. Ahí entran configuraciones como Universal SSL.
Purge: elimina una zona que ya no debe publicarse.
Zona completa: reconstruye todos los registros cuando no se puede probar que un build menor sea seguro.

La regla que sostiene todo es simple y estricta: cada clave que escribe un build dirigido debe ser idéntica, byte por byte, a la que escribiría un build completo. Si no se puede probar, se hace el build completo. La incertidumbre nunca se traduce en menos trabajo.

Cómo se combinan los eventos sin perder mensajes

Antes, el trabajo de registros y el de zona completa usaban schedulers distintos que no podían fusionar su carga. Ahora hay uno unificado: cuando llegan varios eventos de la misma zona antes de que arranque un build, el scheduler los combina. Fusionar solo agrega trabajo, nunca lo quita, y un purge anula cualquier reconstrucción.

El detalle fino está en Kafka. Los mensajes se reparten en particiones ordenadas y existe un offset comprometido: el punto antes del cual todo está completo. Cloudflare usa soft committing, así que un build puede terminar fuera de orden y marcarse completo en memoria, pero la posición comprometida solo avanza cuando terminó cada mensaje anterior. Si el servicio se reinicia, Kafka reenvía lo pendiente. La compañía elige explícitamente trabajo repetido antes que perder el cambio de un cliente.

Los resultados en números

Durante 24 horas de medición, el 86,81% de los builds fueron solo de recursos, el 2,54% de recursos y metadatos, el 2,30% de ápice y metadatos y el 1,30% purges. En conjunto, el 92,95% evitó reconstruir la zona completa. Los builds completos que quedan son el 7,04%, y su caída ronda el 40% respecto del esquema anterior. Además, los que sobreviven promedian 0,35 segundos, porque los eventos que todavía los disparan, como la primera publicación de una zona, afectan sobre todo a zonas nuevas y chicas.

El impacto en recursos fue grande: la memoria de trabajo agregada bajó de un promedio de 49 GiB a 7 GiB (86% menos) y los picos cayeron de 79 GiB a 12 GiB (85% menos). Con ese margen, Cloudflare pudo acortar dos salvaguardas: el intervalo de reconstrucción por zona y el tiempo que el agregador de Kafka retiene cada evento. El resultado fue que la demora mediana de build se redujo de unos 7,7 segundos a unos 3,3 segundos. El mayor pico de p99 pasó de 14,6 minutos a 1,21 minutos, una reducción de 12 veces.

Cómo se validó un cambio de esta magnitud

Cloudflare no confió solo en los tests. Agregó pruebas de equivalencia que corren un build completo y uno dirigido desde el mismo estado de base de datos y comparan cada clave byte por byte. Durante el despliegue ejecutó un build completo al lado de cada build dirigido. Y después montó un Zone Builder espejo que consume el stream de producción de Kafka y lee la base de datos real, pero escribe en un entorno de Quicksilver que no sirve tráfico de clientes. Un comparador revisa una muestra del 20% de las zonas buscando claves faltantes, sobrantes o con valores distintos.

El despliegue del scheduler se hizo por hash del nombre de zona, no del ID, para que todas las zonas que comparten un nombre cayeran en el mismo scheduler y dos de ellos nunca escribieran la misma clave de metadatos.

Qué significa esto para tu startup

El patrón es trasladable aunque nunca vayas a operar millones de registros DNS.

Separa el trabajo pesado del camino crítico. Cloudflare no eliminó el build completo: lo dejó como fallback para los casos donde no puede probar seguridad. Si tu producto tiene una operación costosa que se dispara en cada cambio, pregúntate cuál es la versión mínima que produce exactamente el mismo resultado, y qué evidencia necesitas para confiar en ella.
Mide el p99, no el promedio. El promedio de demora apenas se movió en este proyecto, porque la mayoría de los builds ya eran chicos. Lo que cambió fue la cola: el peor pico pasó de 14,6 minutos a 1,21 minutos. Si solo miras promedios, no vas a ver el incidente que tus usuarios sí ven.
Valida con un espejo antes de tocar producción. Correr el sistema nuevo en paralelo sobre datos reales, comparar una muestra y revisar solo los tipos de diferencias nuevas es un patrón que cualquier equipo puede aplicar con dos entornos y un script de comparación.
Revisa cómo propaga los cambios tu proveedor de DNS. Si gestionas dominios con muchos registros, vale la pena preguntar si los cambios de configuración de zona disparan una reconstrucción completa y cuánto tarda eso en llegar al edge.

Contexto: el DNS como infraestructura crítica

El trabajo sobre el Zone Builder no es un caso aislado. TechSpot reportó que Cloudflare liberó alrededor de 100 TB de RAM en la plataforma de caché DNS detrás de su resolutor 1.1.1.1 recortando el tamaño de una entrada típica de caché de 953 a 420 bytes, con la latencia de consulta bajando de 828 a 670 nanosegundos. Esa caché aloja más de 250.000 millones de entradas DNS.

La escala importa porque la dependencia también es enorme. XDA señala que Cloudflare enruta aproximadamente el 22% del tráfico web global, y recuerda la caída de noviembre de 2025, cuando servicios sin relación directa entre sí fallaron al mismo tiempo por compartir esa dependencia. Del lado del riesgo, el informe de amenazas DDoS del primer semestre de 2026 que recogió Help Net Security ubicó a los ataques de DNS Flood y DNS Amplification como el vector de red más usado, con el 34,3% de todos los ataques de capa de red.

Conclusión

La lección del rediseño del Zone Builder no es que Cloudflare ahorró memoria, sino cómo lo hizo: eligió el trabajo más chico que podía demostrar correcto, mantuvo el camino lento como red de seguridad y validó cada paso contra un espejo de producción. Para una startup, la versión accionable es la misma: optimizar sin perder la capacidad de probar que el resultado no cambió.