Cloudflare réduit le travail de construction DNS grâce aux constructions ciblées : 92,95 % évitent une reconstruction complète, mémoire moyenne de 49 Gio à 7 Gio selon ses mesures

Le 2 novembre 2026, Cloudflare a publié un article d'ingénierie d'Alex Fattouche expliquant comment l'entreprise a réduit le travail que fait son Zone Builder DNS après un changement. Le Zone Builder transforme les modifications des enregistrements DNS et des paramètres de zone en données utilisables par les serveurs DNS faisant autorité de Cloudflare, et les écrit dans Quicksilver, le magasin clé-valeur distribué qui les propage sur le réseau. Lorsque l'auteur a écrit sur ce pipeline en 2022, le constructeur recevait environ 250 changements d'enregistrement par seconde. Il en reçoit aujourd'hui environ 700, plus une centaine d'autres événements comme des changements de paramètres de zone. L'article dit que le nombre d'événements n'a jamais été le vrai problème. Le problème était le type de travail que certains événements exigeaient : certaines zones contiennent désormais plus de 20 millions d'enregistrements, et Cloudflare s'attend à ce qu'elles atteignent des centaines de millions.

L'ancienne conception avait une qualité utile. Une construction complète n'avait pas besoin de savoir pourquoi une zone avait changé. Elle lisait la zone et chaque enregistrement, les convertissait en clés Quicksilver, les comparait à ce qui était stocké et n'écrivait que la différence. C'est peu coûteux pour une petite zone, mais elle lit et compare toujours chaque enregistrement et garde toute la zone en mémoire. Un changement de paramètre de zone, comme l'activation de Universal SSL, peut modifier les métadonnées et les enregistrements d'autorisation d'autorité de certification au sommet de la zone, alors que l'événement n'indiquait souvent pas ce qui avait changé. Cloudflare a donc modifié les producteurs d'événements pour inclure les champs modifiés avec les valeurs précédentes et nouvelles lorsqu'elles existent, et a construit un planificateur qui choisit la plus petite construction qu'il peut prouver sûre.

Le planificateur choisit parmi cinq types de construction : ressources seules, ressources et métadonnées, sommet et métadonnées, purge, et zone complète. La règle énoncée est stricte : chaque clé qu'une construction ciblée écrit doit être identique, octet pour octet, à ce qu'écrirait une construction complète, et si cela ne peut pas être prouvé, le système fait une construction complète. Les détails manquants, les événements inconnus et les mises à jour limitées à l'horodatage provoquent toujours une construction complète, de sorte que l'incertitude ne se transforme jamais en moins de travail. Le nettoyage de l'ancien état fonctionne comme en 2022 : les événements d'enregistrement incluent les enregistrements supprimés et les versions précédentes, et le constructeur parcourt Quicksilver pour trouver les clés existantes sous chaque nom reconstruit et supprime les périmées. Une exception délibérée existe pour les plus grandes zones. Au-delà d'un seuil fixe d'enregistrements, le constructeur ne passe jamais à une construction complète, car elle ne pourrait pas se terminer et bloquerait d'autres changements sur sa partition Kafka. Il reconstruit à la place le sommet, les métadonnées et les noms désignés, et les rares cas restants peuvent être corrigés à la main.

Les noms partagés compliquent les choses. Quicksilver stocke séparément les clés d'enregistrement de chaque zone, mais conserve une clé de métadonnées partagée par toutes les zones portant le même nom de domaine, et cette clé indique quels identifiants de zone internes peuvent répondre aux requêtes. Lors de l'intégration et du départ de clients, plusieurs objets de zone peuvent brièvement exister pour un même domaine. L'article traite aussi de la relecture de la base entre l'événement et la construction, et de la fusion du travail d'une même zone dans un seul ordonnanceur sans perdre de message Kafka.

Cloudflare a vérifié l'affirmation de sûreté de trois façons. Des tests d'équivalence exécutent une construction complète et une construction ciblée à partir du même état de base et comparent chaque clé du plan ciblé. Pendant le déploiement, elle a aussi exécuté une construction complète à côté de chaque construction ciblée. Ensuite, un Zone Builder miroir a consommé le flux Kafka de production, lu l'état de la base de production et écrit dans un Quicksilver distinct qui ne servait aucun client. Un comparateur a contrôlé un échantillon de 20 pour cent des zones, et le tableau de bord de l'article montre un taux de différences de 0,31 pour cent sur 234 313 zones appariées, surtout des décalages temporels. La publication a été échelonnée selon un hachage du nom de zone, d'abord les zones gratuites, puis les zones payantes.

Un décompte sur 24 heures donne 86,81 pour cent de constructions de ressources seules, 2,54 pour cent de ressources et métadonnées, 2,30 pour cent de sommet et métadonnées, et 1,30 pour cent de purges : 92,95 pour cent évitent la reconstruction complète, contre 7,04 pour cent de constructions complètes. Cette part était auparavant de 11,88 pour cent, soit une baisse d'environ 40 pour cent. Dans une comparaison distincte sur les mêmes événements durant les mêmes 24 heures, l'ancien ordonnanceur de production et le nouveau miroir ont montré des délais typiques presque inchangés, mais un pic p99 maximal passant de 14,6 à 1,21 minute. Le délai s'arrête à l'écriture dans Quicksilver et exclut sa diffusion mondiale. La mémoire de travail agrégée de tout le déploiement Zone Builder est passée de 49 à 7 Gio en moyenne et de 79 à 12 Gio au pic pendant le déploiement ; le graphique ne prouve pas la même fenêtre de 24 heures. Ce n'est qu'après la réduction ultérieure de l'intervalle de reconstruction et du tampon Kafka Aggregator que le délai médian est passé d'environ 7,7 à 3,3 secondes. Le graphique à histogramme grossier couvre presque deux heures ; un histogramme plus fin sur environ quatre heures montre ensuite une médiane proche de 3,4 secondes.

Ce sont les mesures de Cloudflare rapportées par étapes et fenêtres distinctes, sans preuve que tous les chiffres viennent d'une seule journée ni de jours civils différents. La part des constructions compte les constructions ; la mémoire de travail du déploiement entier n'est pas celle d'une construction. Le délai comparatif regroupe tous les types et forfaits, sans garantie par zone. D'autres équipes peuvent préciser les changements dans les événements, prouver l'équivalence des sorties ciblées, garder le repli sûr avec l'exception des très grandes zones et tester dans un miroir avant déploiement.