Nous annonçons aujourd'hui Foundation DNS, la nouvelle offre haut de gamme de Cloudflare en matière de DNS. Avec sa fiabilité inégalée et ses performances extrêmes, ce dernier parvient ainsi à satisfaire les exigences les plus complexes des équipes chargées de l'infrastructure.
Parlons d'argent pour commencer
Lorsque vous signez un accord portant sur un DNS d'entreprise, les fournisseurs de DNS vous demandent généralement trois informations avant de générer un devis :
- le nombre de zones ;
- le nombre total de requêtes DNS par mois ;
- les enregistrements DNS totaux sur l'ensemble des zones.
Certains fournisseurs présentent un processus considérablement plus compliqué et bon nombre d'entre eux disposent d'outils de calcul de la tarification ou d'une tarification opaque du type « Contactez-nous ». La planification d'un budget autour de vos perspectives de croissance apporte une complexité inutile à l'ensemble et nous pensons pouvoir vous offrir mieux que ça. Pourquoi ne pas simplifier l'ensemble du processus ? C'est pourquoi nous avons décidé de facturer notre service Foundation DNS sur la base d'une seule information pour nos clients Enterprise : le nombre total de requêtes DNS par mois. Nous espérons ainsi permettre aux entreprises de réaliser des économies et, plus important encore, éliminer les complexités qui se cachent dans leur facture de DNS.
Et ne vous inquiétez pas, tout comme avec le reste de nos produits, l'atténuation des attaques DDoS reste illimitée. Vous n'aurez pas à payer de frais de dépassement dissimulés si vos serveurs de noms se retrouvent victimes d'une attaque DDoS ou si le nombre de requêtes DNS dépasse votre quota pendant un mois ou deux.
Pourquoi le DNS est-il si important ?
Le Domain Name System (DNS, système de noms de domaine) est presque aussi vieux que le réseau Internet lui-même. Défini à l'origine en 1983, dans la RFC 882 et la RFC 883, il résulte du besoin de créer un mappage entre les noms d'hôtes et les adresses IP. À l'époque, ses auteurs ont affirmé avec sagesse : « [Internet] est un vaste système, qui grandira probablement bien plus encore. » [RFC 882]. Aujourd'hui, près de 160 millions de noms de domaine existent uniquement sous l'extension .com, l'un des plus importants Top Level Domains (TLD, domaines de premier niveau) [source].
De par sa conception, le DNS est un système hiérarchique hautement distribué, mais en tant qu'utilisateur final, vous ne communiquerez généralement qu'avec un résolveur (1), attribué ou exploité par votre fournisseur d'accès Internet (FAI), voire directement configuré par votre employeur ou vous-même. Le résolveur communique avec l'un des serveurs racine (2), ainsi que le serveur TLD responsable (3) et le serveur de noms de référence (4) du domaine en question. Dans de nombreux cas, ces quatre organes sont chacun exploités par une entité différente, située dans des territoires, voire des continents, différents.
Comme nous l'avons vu récemment, l'effondrement de votre infrastructure DNS entraîne de graves difficultés, qui vous coûteront probablement très cher, en termes d'argent et de dégâts potentiels à votre réputation. En tant que propriétaire de domaine, vous souhaitez donc que les recherches DNS concernant votre domaine reçoivent une réponse 100 % du temps et s'effectuent, idéalement, aussi vite que possible. Quels sont les moyens à votre disposition pour ce faire ? Vous n'avez aucune influence dans le processus de décision de vos utilisateurs quant à la désignation des résolveurs qu'ils choisissent de configurer. Vous ne pouvez pas influencer le choix du serveur racine non plus. Vous pouvez choisir quel serveur TLD sera impliqué en sélectionnant un nom de domaine figurant au sein d'un TLD donné. Toutefois, si vous êtes lié à un certain TLD pour d'autres raisons, ce choix échappe à nouveau à votre sphère de contrôle. Vous pouvez néanmoins facilement influencer le choix du fournisseur de vos serveurs de noms de référence. Intéressons-nous donc de plus près à l'offre de Cloudflare en matière de DNS de référence.
Examen du DNS de référence de Cloudflare
Le DNS de référence constitue l'un de nos plus anciens produits. Nous avons consacré beaucoup de temps à son perfectionnement. Toutes les réponses aux requêtes DNS transitent par notre réseau mondial Anycast, présent dans plus de 250 villes. Nous pouvons ainsi proposer des performances extrêmes, tout en garantissant une disponibilité mondiale, en permanence. Bien entendu, notre vaste expérience de l'atténuation des attaques DDoS nous permet également d'empêcher quiconque d'abattre nos serveurs de noms et, par voie de conséquence, les domaines de nos clients.
Le DNS revêt une importance stratégique pour Cloudflare, car jusqu'au lancement de Magic Transit, il s'agissait du moyen qui permettait d'orienter chaque utilisateur d'Internet vers Cloudflare pour protéger et accélérer les applications de nos clients. Si nos réponses DNS étaient lentes, le réseau Cloudflare lui-même était lent. Si nos réponses DNS n'étaient pas disponibles, le réseau Cloudflare lui-même était indisponible. La vitesse et la fiabilité de notre DNS de référence s'avèrent primordiales pour la vitesse et la fiabilité de Cloudflare, tout comme elles le sont pour nos clients. Certains de nos clients ont également contribué à développer notre infrastructure DNS au cours de leur croissance avec Cloudflare. Aujourd'hui, notre plus vaste zone client dispose de plus de 3 millions d'enregistrements et les cinq premières atteignent presque les 10 millions, tous enregistrements combinés. Ces clients comptent sur Cloudflare pour diffuser les nouvelles mises à jour des enregistrements DNS en quelques secondes, pas en minutes. Du fait de l'importance de ce système et des besoins de nos clients, nous avons, au fil des ans, développé notre équipe d'ingénierie DNS dédiée, concentrée sur la préservation de la vitesse et de la fiabilité de notre pile DNS.
La sécurité de l'écosystème DNS se montre tout aussi importante. Cloudflare a toujours été un ardent défenseur des DNSSEC. Le processus de signature et de validation des réponses DNS par l'intermédiaire des DNSSEC permettent de s'assurer qu'un pirate en position d'interception ne puisse pas détourner les réponses et rediriger le trafic. Cloudflare a toujours proposé les DNSSEC gratuitement dans toutes ses offres et ces derniers continueront d'exister sous forme d'option gratuite pour Foundation DNS. Pour les clients qui choisissent également d'utiliser Cloudflare comme serveur d'inscription, le déploiement des DNSSEC en un seul clic constitue une autre fonctionnalité essentielle permettant de garantir les domaines de nos clients contre le détournement et la protection de leurs utilisateurs. Nous prenons également en charge la RFC 8078 concernant le déploiement en un seul clic des serveurs d'inscription externes.
D'autres problèmes sont également capables d'immobiliser Internet, mais ils se révèlent pour la plupart hors de notre contrôle : les fuites de routage ou, pire encore, le détournement de routage. Tandis que l'utilisation des DNSSEC peut permettre d'atténuer les détournements de routage, tous les résolveurs récursifs ne peuvent malheureusement pas valider les DNSSEC. Et même si le résolveur peut effectuer cette validation, une fuite ou un détournement de routage au niveau de vos serveurs de noms entraînera toujours une interruption de service. Si l'ensemble des adresses IP de votre serveur de noms sont touchées par ce type d'événement, votre domaine ne peut alors plus être résolu.
Avec de nombreux fournisseurs, chacun de vos serveurs de noms ne résout généralement qu'une seule adresse IPv4 et une seule adresse IPv6. Si cette adresse IP n'est pas joignable (en raison d'encombrements réseau ou, pire, d'une fuite de routage), l'intégralité du serveur de noms devient indisponible et votre domaine ne peut, par conséquent, plus être résolu. Pire encore, certains fournisseurs utilisent le même sous-réseau IP pour l'ensemble de leurs serveurs de noms. Si un problème affecte ce sous-réseau, tous les serveurs de noms tombent.
Examinons l'exemple suivant :
$ dig aws.com ns +short
ns-1500.awsdns-59.org.
ns-164.awsdns-20.com.
ns-2028.awsdns-61.co.uk.
ns-917.awsdns-50.net.
$ dig ns-1500.awsdns-59.org. +short
205.251.197.220
$ dig ns-164.awsdns-20.com. +short
205.251.192.164
$ dig ns-2028.awsdns-61.co.uk. +short
205.251.199.236
$ dig ns-917.awsdns-50.net. +short
205.251.195.149
Toutes les adresses IP du serveur de noms font partie du sous-réseau 205.251.192.0/21. Heureusement, AWS signe désormais ses plages par l'intermédiaire du RPKI, un cadre d'infrastructure qui permet d'éviter les fuites… pourvu que le FAI du résolveur le valide. Toutefois, si le FAI du résolveur ne valide pas le RPKI, et en cas de fuite ou de détournement du sous-réseau, les résolveurs ne seront plus en mesure de joindre ces serveurs de noms et le domaine aws.com ne pourra plus être résolu.
Il va sans dire que Cloudflare signe l'ensemble de nos itinéraires de routage et incite le reste d'Internet à les adopter afin de minimiser l'impact des fuites de routage. Mais que pouvons-nous faire d'autre pour nous assurer que nos systèmes DNS conservent leur résilience malgré ces fuites, pendant que nous attendons le déploiement universel du RPKI ?
À l'heure actuelle, lorsque vous utilisez le DNS de Cloudflare dans le cadre d'une offre gratuite, Pro, Business ou Enterprise, votre domaine bénéficie de deux serveurs de noms sous la structure <name>.ns.cloudflare.com, au sein de laquelle <name> représente un prénom aléatoire.
$ dig isbgpsafeyet.com ns +short
tom.ns.cloudflare.com.
kami.ns.cloudflare.com.
Comme nous l'avons vu précédemment, pour qu'un domaine soit disponible, il faut que ses serveurs de noms le soient également. C'est pourquoi chacun de ces serveurs résout trois adresses Anycast IPv4 et trois adresses Anycast IPv6.
$ dig tom.ns.cloudflare.com a +short
173.245.59.147
108.162.193.147
172.64.33.147
$ dig tom.ns.cloudflare.com aaaa +short
2606:4700:58::adf5:3b93
2803:f800:50::6ca2:c193
2a06:98c1:50::ac40:2193
Le détail essentiel à relever ici est que chacune des trois adresses IPv4 et IPv6 provient d'un bloc /8 IPv4 différent (/45 pour l'IPv6). Ainsi, pour que vos serveurs de noms se retrouvent indisponibles en IPv4, la fuite de routage doit précisément affecter les sous-réseaux correspondants sur l'ensemble des trois blocs /8 IPv4. Bien que toujours possible en théorie, l'occurrence d'un tel événement se révèle pour ainsi dire impossible en pratique.
Comment pouvons-nous encore améliorer ce processus ?
Les clients qui utilisent Foundation DNS se verront attribuer un nouvel ensemble de serveurs de noms avancés, hébergés sur foundationdns.com et foundationdns.net. Ces serveurs de noms seront encore plus résilients que les serveurs de noms par défaut de Cloudflare. Nous annoncerons d'autres détails sur la manière dont nous y parviendrons en début d'année prochaine, alors restez à l'écoute ! Tous les domaines externes de Cloudflare (comme cloudflare.com) migreront vers ces serveurs de nom au cours de l'année à venir.
Et ce n'est pas tout !
Nous sommes heureux d'annoncer que nous allons lancer deux fonctionnalités très demandées :
- La prise en charge des transferts de zone sortants pour le DNS secondaire
- La prise en charge de Logpush pour les requêtes au DNS de référence et au DNS secondaire
Ces deux fonctionnalités seront disponibles sans coût supplémentaire dans le cadre de Foundation DNS, ainsi que pour les clients Enterprise. Examinons chacune d'elles plus en détail et découvrons de quelle manière elles permettent d'améliorer encore notre offre DNS.
La prise en charge des transferts de zone sortants pour le DNS secondaire
Qu'est-ce que le DNS secondaire et pourquoi est-il important ? De nombreuses grandes entreprises ont comme exigence d'utiliser plus d'un fournisseur DNS afin de mettre en place une redondance, au cas où l'un des fournisseurs deviendrait indisponible. Elles peuvent satisfaire cette exigence en ajoutant les enregistrements DNS de leur domaine sur deux plates-formes indépendantes et en assurant manuellement la synchronisation des zones de fichiers. On désigne alors cette configuration sous le nom de « Multi-Primary » (multi-principale). L'utilisation d'un DNS secondaire propose deux mécanismes permettant d'automatiser le processus à l'aide d'une configuration « Primary-Secondary » (principale-secondaire) :
- DNS NOTIFY : le serveur de noms principal notifie le secondaire de chaque modification survenant dans la zone. Lorsque le serveur de noms secondaire reçoit la notification NOTIFY, il envoie une requête de transfert de zone au serveur de noms principal afin d'assurer sa synchronisation avec ce dernier.
- Requête SOA : ici, le serveur de noms secondaire interroge régulièrement l'enregistrement SOA de la zone. Il vérifie si le numéro de série trouvé sur cet enregistrement correspond au dernier numéro de série enregistré par le serveur de noms secondaire au sein de l'enregistrement SOA de cette zone. Si une nouvelle version de la zone se révèle disponible, le serveur de noms envoie une requête de transfert de zone au serveur principal afin d'obtenir les modifications.
Si vous souhaitez en savoir plus, Alex Fattouche a rédigé un article de blog très instructif sur la manière dont le DNS secondaire agit en coulisses. L'un des autres rôles de la configuration « principale-secondaire » consiste à masquer le serveur principal, alors nommé « hidden primary » (serveur principal masqué). La différence apportée par cette configuration réside dans le fait que seuls les serveurs de noms secondaires sont considérés comme des serveurs de référence (en d'autres termes, configurés au niveau du serveur d'inscription du domaine). Le schéma ci-dessous présente les différentes configurations.
Depuis 2018, nous avons soutenu la configuration « principale-secondaire », au sein de laquelle Cloudflare adopte le rôle du serveur de noms secondaire. De notre point de vue, cette configuration implique que nous acceptons les transferts de zone entrants issus des serveurs de noms principaux.
À compter d'aujourd'hui, nous prenons également en charge les transferts de zone sortants. Nous adoptons ainsi le rôle du serveur de noms principal avec un ou plusieurs serveurs de noms secondaires externes recevant des requêtes de transfert de zone en provenance de Cloudflare. Tout comme pour les transferts entrants, nous prenons en charge :
- les transferts de zone via AXFR et IXFR ;
- les notifications automatiques via DNS NOTIFY afin de déclencher les transferts de zone à chaque modification ;
- les transferts signés utilisant TSIG pour garantir l'authentification des zones de fichiers au cours du transfert.
Logpush pour les requêtes au DNS de référence et au DNS secondaire
Chez Cloudflare, nous adorons les logs. Au cours du troisième trimestre 2021, nous avons traité une moyenne de 28 millions de requêtes HTTP par seconde et de 13,6 millions de requêtes DNS par seconde, tout en bloquant 76 milliards de menaces chaque jour. Tous ces événements sont enregistrés sous forme de logs pendant une durée limitée, afin de fournir à nos utilisateurs des analyses en quasi temps réel dans le tableau de bord. Pour les clients qui souhaitent (ou doivent) stocker ces logs de manière permanente, nous avons d'ailleurs conçu Logpush en 2019. Logpush vous permet de transférer vos logs quasiment en temps réel vers l'un de nos partenaires d'analyse (Microsoft Azure Sentinel, Splunk, Datadog et Sumo Logic) ou vers n'importe quelle destination de stockage cloud grâce à une API compatible R2.
Nous ajoutons aujourd'hui un ensemble de données supplémentaire pour Logpush : les logs DNS. Pour configurer Logpush et commencer à transférer les logs DNS de votre domaine, il vous suffit de vous rendre dans le tableau de bord Cloudflare, de créer une nouvelle tâche Logpush, de sélectionner « Logs DNS » et de définir les champs de log qui vous intéressent.
N'hésitez pas à consulter notre documentation destinée aux développeurs pour profiter d'instructions détaillées sur la manière dont vous pouvez effectuer cette opération via l'API. Vous y trouverez également une description approfondie des nouveaux champs de logs DNS.
Encore une chose (ou deux…)
Lorsque vous passez en revue le DNS dans son ensemble au sein de votre infrastructure, il est important de prendre en compte la circulation de votre trafic à travers vos systèmes, ainsi que la manière dont ce trafic se comporte. En fin de compte, les ressources en termes de puissance de traitement, de mémoire, de capacité serveur et de calcul en général ne sont disponibles qu'en quantités limitées. La solution Load Balancing constitue l'un des meilleurs et des plus importants outils à notre disposition, de même que la fonctionnalité de surveillance de l'intégrité !
Disponible depuis 2016, la solution Load Balancing proposée par Cloudflare permet aux clients de tirer parti de leurs ressources existantes de manière évolutive et intelligente. Notre équilibreur de charge se trouvait toutefois limité aux enregistrements A, AAAA et CNAME. Ces derniers couvraient une bonne partie des principaux scénarios d'utilisation requis par les clients, mais pas tous. Bon nombre de clients ont des besoins supplémentaires, comme l'équilibrage de charge des enregistrements MX ou du trafic des serveurs de courrier électronique. D'autres besoins doivent également être pris en compte, comme les enregistrements SRV, afin de définir les caractéristiques respectives du trafic (ports et poids) qui doit circuler pour un service spécifique, ou les enregistrements HTTPS, qui permettent de s'assurer que le trafic de chaque enregistrement respectif utilise le protocole sécurisé, indépendamment du port. Nous souhaitons nous assurer que l'ensemble des besoins de nos clients sont couverts, afin de soutenir leur capacité à aligner leurs objectifs commerciaux et leurs possibilités de mise en œuvre technique.
Nous sommes heureux d'annoncer l'ajout de nouvelles méthodes de surveillance de l'intégrité afin de prendre en charge l'équilibrage de charge du trafic des enregistrements MX, SRV, HTTPS et TXT, sans configuration supplémentaire requise. Créez vos enregistrements DNS respectifs dans Cloudflare et définissez votre équilibreur de charge en tant que destination… Vous n'avez rien de plus à faire ! Grâce aux méthodes ICMP Ping, SMTP et UDP-ICMP, les clients gardent toujours un œil sur l'état de leurs serveurs et peuvent appliquer des décisions d'acheminement intelligent reposant sur les informations relatives à l'intégrité de chacun de ces derniers.
Il n'existe pas de réponse unique en matière d'acheminement intelligent. Les entreprises différentes présentent des besoins différents, notamment concernant la position géographique de leurs serveurs et de leurs clients à travers le monde. L'une des règles générales les plus suivies s'articule autour du fait de placer vos serveurs à l'endroit où vos clients se situent. Ce positionnement permet de s'assurer de disposer d'une expérience aussi performante et localisée que possible. Un scénario courant consiste à acheminer votre trafic en fonction du lieu d'origine des requêtes émises par vos utilisateurs finaux et de créer un mappage vers le serveur le plus proche de cette zone. La fonctionnalité de routage géolocalisé du trafic proposée par Cloudflare permet à nos clients de réaliser très exactement cette opération : créer un mappage de régions vers des pools. Nous pouvons ainsi garantir qu'en cas de réception d'une requête en provenance d'Europe de l'Est, par exemple, nous l'adresserons au serveur approprié afin de la satisfaire. Les régions peuvent parfois se révéler particulièrement vastes et entraîner divers problèmes, comme la possibilité que les associations au sein du mappage ne se montrent pas aussi précises que l'on pourrait le souhaiter.
Nous sommes très enthousiastes à l'idée d'annoncer aujourd'hui la prise en charge du pays au sein de notre fonctionnalité de routage géolocalisé du trafic. Nos clients pourront désormais choisir soit l'une de nos treize régions, soit un pays spécifique à associer à leurs pools, afin de bénéficier d'un contrôle plus précis sur la manière dont le trafic client doit se comporter au cours de son trajet sur leurs systèmes. La fonctionnalité d'acheminement du trafic au niveau du pays et les nouvelles méthodes de surveillance de l'intégrité permettant de soutenir l'équilibrage de charge d'un nombre plus important d'enregistrements DNS seront disponibles en janvier 2022 !
Faire progresser l'écosystème DNS
Nous avons encore d'autres actualités passionnantes à annoncer : nous sommes en train de terminer le travail sur le modèle Multi-Signer DNSSEC (RFC8901) et prévoyons de le déployer au cours du premier trimestre 2022. Pourquoi ce modèle est-il important ? Les grandes entreprises présentent généralement deux exigences :
- Redondance : le fait de disposer de plusieurs fournisseurs DNS émettant les réponses de référence pour leurs domaines.
- Authenticité : le fait de déployer les DNSSEC afin de garantir que les réponses DNS puissent être convenablement authentifiées.
Ces deux exigences peuvent être satisfaites en demandant au serveur de noms principal de signer le domaine et de transférer ses enregistrements DNS, plus les signatures des enregistrements, au serveur de noms secondaire, qui traitera les deux éléments en l'état. Cette configuration est actuellement prise en charge par le DNS secondaire de Cloudflare. Les fonctionnalités DNS non standard, comme l'acheminement du trafic au niveau du pays, par exemple, ne peuvent toutefois pas être prises en charge lors du transfert de zones présignées. C'est là que le modèle Multi-Signer DNSSEC (modèle DNSSEC à plusieurs signataires) entre en jeu. Les deux fournisseurs DNS doivent connaître les clés de signature de l'autre fournisseur et procéder à leur propre signature en ligne (ou à la volée). Si vous souhaitez en savoir plus sur le fonctionnement du modèle Multi-Signer DNSSEC, rendez-vous sur cet excellent article de blog publié par APNIC.
Dernier point, mais non des moindres, Cloudflare rejoint le DNS Operations, Analysis, and Research Center (DNS-OARC) en tant que membre Gold. Aux côtés d'autres chercheurs et exploitants d'infrastructure DNS, nous souhaitons ainsi nous atteler à la résolution des problèmes les plus difficiles, tout en travaillant de manière continue à la mise en œuvre de nouvelles normes et fonctionnalités.
« Le DNS constitue un outil essentiel en matière de gestion et de diffusion de contenu à la périphérie, c'est-à-dire l'endroit même où les clients exigent des performances et de la fiabilité. Cloudflare est un membre important de la communauté DNS et a régulièrement participé aux ateliers de l'OARC. Pendant de nombreuses années, l'entreprise a ainsi présenté ses innovations et ses découvertes opérationnelles à notre public axé sur le DNS. C'est un plaisir d'accueillir aujourd'hui cette entreprise en tant que membre à part entière de notre communauté. Nous nous réjouissons à l'idée de pouvoir bientôt nous appuyer sur ses contributions uniques à titre de membre Gold de l'OARC.
– Keith Mitchell, président de l'OARC
Si nous sommes présents dans l'univers DNS depuis le premier jour de Cloudflare, nous n'en sommes encore qu'au commencement. Nous savons que nos clients nous demanderont des fonctionnalités plus précises et plus spécifiques à l'avenir. Le lancement de Foundation DNS constituera la portée d'entrée, le point d'appui, qui nous permettra de poursuivre nos investissements à tous les niveaux du DNS, tout en continuant à développer la plate-forme DNS la plus riche du monde en termes de fonctionnalités pour les entreprises. Si vous avez des idées, n'hésitez pas à nous faire part de vos rêves concernant tout ce que vous avez toujours souhaité que votre fournisseur DNS puisse faire pour vous. De même, si vous souhaitez nous aider à concevoir ces fonctionnalités, nous recrutons.