Cloudflare organise son écosystème autour de trois concepts : les profils utilisateurs, les comptes et les zones. Ces éléments définissent où résident les réglages spécifiques. Chaque utilisateur possède un profil contenant ses préférences de langue ou de communication. Un compte, quant à lui, est l’entité organisationnelle qui regroupe des utilisateurs et des zones.

Les zones correspondent aux domaines ou sous-domaines ajoutés à la plateforme. Elles sont cruciales car les services appliqués à ce niveau, tels que les règles de mise en cache ou les équilibreurs de charge, n’affectent que ce domaine précis, même s’il est inclus dans le même compte qu’une autre zone.

La granularité des réglages réseau

La structure montre une hiérarchie claire. Les produits de niveau compte, comme le Centre de sécurité ou les Workers, peuvent impacter l’ensemble des zones. Mais une fois qu’on se focalise sur une zone, on accède aux produits propres à ce domaine. Les enregistrements DNS, qui constituent la base de cette zone, sont gérés par des objets précis. L’API permet de manipuler divers types de records, incluant A, AAAA, CA ou OpenPGPkey, avec une gestion fine du Time To Live (TTL).

Pour les records A et AAAA, par exemple, il est possible de configurer des paramètres limitant la génération de certains types d’adresses IP. Cette option, réservée à des cas exceptionnels, permet de forcer la génération uniquement d’enregistrements IPv4 ou uniquement d’IPv6, bien que cela n’influence pas la manière dont Cloudflare communique avec l’origine.

Optimiser la propagation des changements DNS

Au-delà de l’organisation administrative, Cloudflare explique comment il gère la diffusion des modifications sur son réseau mondial. Lorsque le nombre d’événements augmente — l’entreprise reçoit aujourd’hui environ 700 changements par seconde, contre 250 en 2022 — le problème n’est plus le volume, mais la complexité du travail demandé par chaque modification. Certaines zones dépassent déjà les 20 millions d’enregistrements.

Historiquement, le système de construction de zone (Zone Builder) devait reconstruire l’état désiré à partir de la base de données actuelle. Si la zone était petite, cela fonctionnait. Mais pour les plus grandes infrastructures, contenir l’intégralité de la zone en mémoire devenait impossible. De plus, l’ajout de réglages de zone, comme l’activation de l’SSL universel, rendait le ciblage plus difficile, car ces changements pouvaient modifier des métadonnées partagées par plusieurs zones.

Cloudflare a donc mis en place un planificateur de construction ciblé. Ce système choisit le plus petit ajustement qui est prouvé comme sûr, évitant ainsi de surcharger les ressources. Selon l’entreprise, cette optimisation a permis de réduire la consommation de mémoire de pointe de 85 % et de diviser par deux le temps nécessaire pour qu’un changement DNS soit écrit dans Quicksilver, le magasin de clés distribué.

Sources

• Accounts, zones, and profiles · Cloudflare Fundamentals docs, developers.cloudflare.com
• Records, developers.cloudflare.com
• How we halved DNS build delay and cut memory use by 85%, Cloudflare, 2 novembre 2026