De 79 a 12 GiB de memoria y la mitad de espera: Cloudflare reforma el sistema DNS que recibe 700 cambios de registros por segundo

• Adrián Villellas @AdrianVillellas
• Ingeniero informático, divulgador y creador de contenido tecnológico desde 2017, escribiendo para blogs y medios tanto en español como en inglés.
• • 13/11/2026 22:04
  • Actualizado: 13/11/2026 22:04

Cloudflare ha reducido un 85 % el pico de memoria del programa que alimenta su sistema DNS, de 79 a 12 GiB. El retraso mediano al publicar un cambio ha bajado de unos 7,7 a unos 3,3 segundos. La compañía lo detalló el 2 de noviembre en su blog técnico, en una entrada firmada por Alex Fattouche.

El DNS es el servicio que traduce un nombre de dominio en la dirección de un servidor. Cuando un cliente modifica uno de sus registros, un componente llamado Zone Builder prepara ese cambio para la red global de la empresa. Hoy recibe unos 700 cambios de registros por segundo, casi el triple que los 250 de 2022.

Zonas con 20 millones de registros

A esos cambios se suman otros 100 eventos por segundo, como los ajustes de zona. Una zona es el conjunto de registros y ajustes de un dominio. Algunas ya superan los 20 millones de registros y la empresa espera verlas crecer hacia los cientos de millones.

Fattouche escribe que el número de eventos «nunca fue el verdadero problema». Lo que pesaba era el tipo de trabajo que pedían algunos de ellos. En una reconstrucción completa, el programa lee, codifica y compara todos los registros de la zona.

Durante ese proceso mantiene la zona entera en memoria. En un dominio pequeño el coste apenas se nota, pero las zonas más grandes directamente no caben.

Cloudflare ya había resuelto el caso de los registros sueltos en una entrada de 2022. Los ajustes de zona resultaron más difíciles, porque llegan de muchos productos y a veces no indican qué ha cambiado. Activar Universal SSL, por ejemplo, puede modificar los registros CAA, que autorizan a emitir certificados para un dominio.

Planificador de cinco caminos

Los ingenieros crearon un planificador que elige la reconstrucción más pequeña cuya seguridad puede demostrar. Tiene cinco opciones. La más ligera rehace solo unos nombres concretos, otras dos añaden los metadatos, una cuarta borra zonas retiradas y la última repasa la zona completa.

Cada clave escrita por una reconstrucción parcial debe ser idéntica, byte a byte, a la que produciría una completa. Si un evento no aclara qué ha cambiado, el sistema rehace todo. Según la entrada, «el planificador nunca convierte la incertidumbre en menos trabajo».

A esa pieza se suma un único programador de tareas, que sustituye a los dos anteriores. Su función es agrupar en una sola operación los cambios pendientes de una misma zona. En una medición de 24 horas, el 92,95 % de las reconstrucciones evitó rehacer la zona entera.

Un espejo sin clientes

Para comprobar el resultado, Cloudflare mantiene un Zone Builder espejo que consume los eventos reales. Lee la base de datos de producción, aunque escribe en un entorno separado sin tráfico de clientes. Un comparador revisa una muestra del 20 % de las zonas en busca de claves ausentes, sobrantes o distintas.

En la captura que publica la empresa, las diferencias afectan al 0,31 % de 234.313 zonas comparadas. Cloudflare atribuye la mayoría a desfases de tiempo, que desaparecen cuando ambos sistemas se ponen al día. El despliegue empezó por las zonas gratuitas y continuó después con las de pago.

De 79 a 12 GiB

La memoria media en uso cayó de 49 a 7 GiB, un 86 % menos. El programa carga ahora zonas grandes completas con mucha menos frecuencia. El gráfico de Cloudflare muestra el escalón que dejó el despliegue.

Con el sistema antiguo y el nuevo trabajando sobre los mismos eventos, las diferencias aparecieron en los peores momentos. El percentil 99 marca el tiempo en el que termina el 99 % de los cambios. Su mayor pico bajó de 14,6 a 1,21 minutos.

Las colas de mensajes también se estabilizaron. Antes, el programa se retrasaba y luego recuperaba terreno a ráfagas de hasta 1.550 mensajes por segundo.

El recorte de la mediana llegó después, gracias a ese margen de capacidad. Cloudflare acortó en la mayoría de sus planes el intervalo mínimo entre reconstrucciones de una misma zona. También redujo el tiempo que retiene cada evento hasta que las réplicas de la base de datos están al día.

Tiempos sin garantía por dominio

La propia empresa advierte de que los tiempos mezclan todos los tipos de reconstrucción y de planes. Por eso «no son una garantía de latencia para una zona concreta». Además, la medición termina cuando los datos llegan a Quicksilver, su almacén distribuido, y deja fuera el reparto por los centros de datos.

Conviene leer con cuidado el 92,95 %, porque el 86,81 % eran cambios en nombres concretos y ese camino ya existía. Las reconstrucciones completas pasaron del 11,88 % al 7,04 %, cerca de un 40 % menos. Cloudflare subraya que ese porcentaje se queda corto, ya que en él figuraban las zonas más grandes.

Por encima de un número de registros que la entrada no revela, el sistema nunca hace una reconstrucción completa, porque no podría terminarla. En algunos casos raros, los técnicos deben rehacer nombres a mano.

El texto tampoco relaciona este trabajo con las caídas que dejaron sin servicio a webs como ChatGPT o X o a cientos de páginas más.

Todos los datos se han publicado en el blog de Cloudflare, con fecha del 2 de noviembre de 2026.

Crédito de la imagen: Cloudflare.