Cloudflare divise par deux le délai de build DNS en ciblant les zones au lieu de tout reconstruire
Le 2 novembre 2026, Cloudflare a détaillé son planificateur de build ciblé pour le pipeline DNS : au lieu de reconstruire des zones de plus de 20 millions d’enregistrements à chaque changement de paramètre, il ne réécrit que ce qu’il peut prouver sûr. Résultat mesuré : 40 % de builds complets en moins, 85 % de mémoire crête en moins, et un délai médian divisé par deux.
2 novembre 2026. Cloudflare publie un billet d’ingénierie signé Alex Fattouche sur son pipeline de propagation DNS. 700 changements par seconde. C’est le débit actuel du Zone Builder, contre environ 250 en 2022, plus une centaine d’événements de paramètres de zone. 20 millions d’enregistrements. C’est la taille des plus grosses zones, en route vers des centaines de millions. Pourquoi c’est important : jusqu’ici, changer un simple paramètre de zone — activer Universal SSL, par exemple — déclenchait la reconstruction de la zone entière, un travail qui ne tient plus en mémoire sur les plus grandes.
Le pipeline, et pourquoi le build complet ne tenait plus
Une zone DNS est l’ensemble des enregistrements et paramètres d’un domaine. Cloudflare transforme chaque changement en données exploitables par ses serveurs autoritatifs via une chaîne en plusieurs étapes : le changement est écrit en base, produit un événement Kafka, passe par un agrégateur, puis le Zone Builder lit l’état de la zone, le convertit en clés compréhensibles par les serveurs, et écrit les différences dans Quicksilver — le magasin clé-valeur distribué qui propage la configuration sur le réseau mondial.
Le Zone Builder d’origine avait une qualité précieuse : il n’avait pas besoin de savoir pourquoi une zone avait changé. Il relisait l’état désiré depuis la base et reconstruisait. Le problème n’était pas le nombre d’événements, mais le type de travail qu’ils demandaient, et la façon dont ce travail croît avec la taille de la zone. Un build complet lit, encode et compare chaque enregistrement, en gardant la zone entière en mémoire. Pour une petite zone, c’est négligeable. Pour une zone de plusieurs dizaines de millions d’enregistrements, elle ne tient plus en mémoire du tout.
Le vrai défi n’est pas d’écrire moins, c’est de prouver que moins est sûr
Un build ciblé doit répondre à trois questions qu’un build complet n’avait jamais posées : quels noms DNS peuvent changer, quelles métadonnées partagées peuvent changer, et quel état antérieur doit être retiré de Quicksilver. La règle qui gouverne tout le planificateur tient en une phrase, répétée dans le billet : chaque clé écrite par un build ciblé doit être identique octet pour octet à ce qu’un build complet aurait écrit. Si l’équipe ne peut pas le prouver, elle fait un build complet.
Le planificateur distingue donc cinq types de build :
- Ressources seulement — reconstruire les enregistrements de noms précis, sans toucher aux métadonnées (cas courant des changements A, AAAA, TXT, CNAME).
- Ressources et métadonnées — pour les changements de nameserver et de wildcard.
- Apex et métadonnées — pour des réglages comme Universal SSL, qui touchent l’apex et les enregistrements CAA.
- Purge — retirer une zone qui ne doit plus être publiée.
- Zone complète — le repli quand rien de plus petit ne peut être prouvé sûr.
La subtilité vient des zones homonymes. Une même zone publique peut correspondre à plusieurs objets internes pendant les transitions d’onboarding et d’offboarding, reliés par une clé de métadonnées partagée. Un build qui écrit cette clé la reconstruit entière depuis une vue fraîche, plutôt que de patcher une copie plus ancienne.
Le planificateur et le planificateur bis
Une autre difficulté : un événement décrit le passé. Entre la planification et l’exécution, la base a pu changer. Cloudflare planifie donc deux fois — une première liste de travail conservatrice à l’arrivée de l’événement, puis une lecture d’un snapshot de publication juste avant d’écrire. Cette relecture peut transformer un build ciblé en build complet, en purge, ou le faire sauter, selon l’état réel au moment de l’exécution.
Un ordonnanceur unifié remplace les deux anciens, et fusionne les travaux qui concernent la même zone avant qu’un build ne démarre. Côté Kafka, le billet insiste sur un point que tout opérateur de pipeline connaît : un build lent peut retarder des clients sans rapport. Les partitions Kafka sont ordonnées, et la position committée ne peut avancer que lorsque chaque message antérieur est terminé — d’où le soft committing, qui préfère rejouer du travail après un redémarrage plutôt que de perdre un changement client.
Des chiffres, pas des intentions
Les résultats sont mesurés sur 24 heures, en miroir production contre nouvel ordonnanceur. Sur la période, 92,95 % des builds ont évité la reconstruction complète de la zone — dont 86,81 % en « ressources seulement ». Les builds complets restent à 7,04 %, soit une baisse d’environ 40 % par rapport à avant.
Les gains physiques suivent. La mémoire de travail agrégée est passée de 49 Gio à 7 Gio en moyenne (soit 86 % de moins), avec des crêtes tombées de 79 Gio à 12 Gio (85 % de moins). Le délai médian de complétion d’un build — du changement DNS à l’écriture dans Quicksilver — est passé d’environ 7,7 secondes à 3,3 secondes, une division par deux obtenue en raccourcissant deux garde-fous que la baisse de charge rendait enfin sûrs. Et sur la queue de distribution, le pic de p99 est tombé de 14,6 minutes à 1,21 minute, une réduction d’un facteur 12.
Ce que ça apprend à un SRE
Le billet est une leçon d’ingénierie transférable au-delà du DNS. La tentation, face à un pipeline de distribution de configuration qui coûte cher sur les gros objets, est d’écrire moins — et de découvrir en production que « moins » laisse des données périmées. Cloudflare a inversé l’ordre : d’abord prouver l’équivalence (tests d’équivalence octet pour octet, miroir en production, échantillonnage comparatif), ensuite seulement réduire le travail. C’est la différence entre une optimisation et une régression silencieuse.
Le repli « zone complète » reste d’ailleurs assumé, pas honteux : une zone publiée pour la première fois doit écrire chaque enregistrement, et un événement qui ne dit pas ce qui a changé repart sur un build complet. Le planificateur ne transforme jamais l’incertitude en travail en moins.
Verdict
Si vous exploitez un pipeline qui distribue de la configuration à grande échelle — DNS, pare-feu, CDN — et que vos gros objets imposent des reconstructions coûteuses, reprenez l’ordre de Cloudflare : instrumentez d’abord une vérification d’équivalence (build complet contre build ciblé, octet pour octet), puis seulement réduisez le travail ciblé, en gardant le repli complet pour ce que vous ne pouvez pas prouver. Les 85 % de mémoire crête en moins et le délai divisé par deux sont la conséquence de cette discipline, pas le point de départ. Si vos zones sont petites et vos builds déjà rapides, le gain est marginal — mais la règle d’équivalence, elle, se copie partout.