Lancement de notre résolveur DNS, 1.1.1.1 (et ce n'est pas un poisson d'avril)

La mission de Cloudflare est d'aider à bâtir un internet toujours plus performant et aujourd'hui, nous lançons notre résolveur DNS, 1.1.1.1,un service DNS récursif. Avec cette offre, nous remettons sur pied le fondement d'internet en construisant un résolveur DNS public plus rapide, plus sûr et plus axé sur la confidentialité. Le résolveur DNS 1.1.1.1.1 est accessible au public. Il s'agit du premier service de Cloudflare s'adressant avant tout au grand public.

Nous utilisons les adresses IPv4 suivantes pour notre résolveur : 1.1.1.1 et 1.0.0.1. Plutôt facile à retenir. Ces adresses ont été fournies à Cloudflare par l'APNIC pour la recherche conjointe et pour ce service. Pour mieux connaître leur travail, vous pouvez consulter le blog de l’APNIC.

Le résolveur DNS 1.1.1.1. est géré par le réseau mondial Anycast de Cloudflare.

Nos amis de chez DNSimple ont réalisé cet excellent tutoriel destiné à quiconque souhaite combler ses lacunes dans sa connaissance du fonctionnement des DNS. Ils expliquent de manière très complète tout ce qu'il faut savoir sur les résolveurs, les serveurs racine, et bien plus encore.

Lors de la résolution d'un nom de domaine, une requête passe de votre système final (c'est-à-dire votre navigateur) à un service DNS récursif. Si l'enregistrement DNS n'est pas dans le cache local du service, le Recursor interrogera la hiérarchie DNS de référence pour trouver les informations d'adresse IP que vous recherchez. Le résolveur DNS, 1.1.1.1.1 joue le rôle du Recursor. Il doit être rapide et, de nos jours, il doit aussi être sécurisé !

Nos objectifs avec le résolveur public sont simples : Cloudflare entend mettre en place le résolveur public le plus rapide du monde tout en améliorant la protection de la vie privée des utilisateurs. Pour rendre internet plus rapide, nous construisons déjà des centres de traitement de données dans le monde entier pour réduire la distance (c'est-à-dire la latence) entre les utilisateurs et le contenu. Nous souhaitons que chacun soit à moins de 10 millisecondes d'au moins un de nos sites.

Au cours du seul mois de mars, nous avons permis la création de 31 nouveaux centres de traitement de données à l'échelle mondiale (Istanbul, Reykjavík, Riyad, Macao, Bagdad, Houston, Indianapolis, Montgomery, Pittsburgh, Sacramento, Mexico City, Tel-Aviv , Durban, Port-Louis, Cebu City, Edinburgh, Riga, Tallinn, Vilnius, Calgary, Saskatoon, Winnipeg , Tallahassee Jacksonville, Memphis,, Bogotá, Ville de Luxembourg et Chișinău) et, comme toutes les autres villes de notre réseau, les nouveaux sites utilisent le résolveur DNS 1.1.1.1.1 depuis le premier jour !

Notre réseau rapide et bien distribué est conçu pour supporter n'importe quel protocole et nous sommes actuellement le fournisseur DNS de référence le plus rapide sur internet, ce dont bénéficient plus de sept millions de sites internet. De plus, nous fournissons déjà un service anycast à deux des treize serveurs racines. L'étape logique suivante consistait à fournir un service DNS récursif plus rapide aux utilisateurs. Notre Recursor peut tirer profit des serveurs de référence qui cohabitent avec nous, ce qui accélère les recherches pour tous les noms de domaine.

Bien que DNSSEC assure l'intégrité des données entre un résolveur et un serveur de référence, il ne protège pas la confidentialité lors de la dernière phase de transfert vers vous. Le résolveur DNS 1.1.1.1.1 est compatible avec les deux nouvelles normes de confidentialité DNS - DNS-over-TLS et DNS-over-HTTPS, qui permettent un cryptage de dernier niveau pour protéger vos requêtes DNS et éviter toute altération de leur confidentialité.

Auparavant, le Recursor envoyait le nom de domaine complet à n'importe quel intermédiaire lorsqu'il arrivait à la racine ou au DNS de référence. Cela signifiait que si vous alliez sur  www.cloudflare.com, le serveur racine et le serveur en .com étaient tous deux interrogés avec le nom de domaine complet (c'est-à-dire les parties www, cloudflareet com), même si les serveurs racines devaient simplement rediriger le récursif vers .com (indépendamment de toute autre partie du domaine complet). Cette facilité d'accès à toutes ces informations de navigation personnelle via DNS présente un grave problème de confidentialité pour de nombreuses personnes. Plusieurs résolveurs en ont tenu compte, mais toutes les solutions n'ont pas été adaptées ou déployées à grande échelle.

Le résolveur DNS 1.1.1.1.1.1 fournit dès le début tous les mécanismes de protection de la confidentialité DNS définis et proposés, à utiliser entre le résolveur minimum et le résolveur récursif. Pour les moins expérimentés, un résolveur minimal est un composant de votre système d'exploitation qui communique avec le résolveur récursif. En utilisant uniquement la minimisation des noms de requête DNS définie dans RFC7816, le résolveur DNS 1.1.1.1.1 réduit les risques de fuite d'informations vers les serveurs DNS intermédiaires, tels que le serveur racine et le TLD. Cela signifie que le résolveur DNS 1.1.1.1.1 envoie seulement une partie suffisante du nom pour que le DNS de référence puisse dire au résolveur où poser la question suivante.

Le résolveur DNS 1.1.1.1.1 prend également en charge les requêtes TLS de confidentialité sur le port 853 (DNS over TLS) pour que nous puissions empêcher les réseaux d'espionnage d'accéder aux requêtes. De plus, en proposant un protocole DoH expérimental (DNS via HTTPS), nous améliorons à la fois la confidentialité et d'autres services futurs pour les utilisateurs finaux, car les navigateurs et autres applications peuvent désormais combiner le trafic DNS et HTTPS en une seule connexion.

Avec la mise en cache négative agressive des DNS, telle que décrite dans RFC8198, nous pouvons encore diminuer la charge sur le système DNS global. Cette technique consiste d'abord à utiliser le cache négatif des résolveurs existants qui conserve les informations négatives (ou inexistantes) pendant un certain temps. Pour les zones signées avec DNSSEC et à partir des enregistrements NSEC en cache, le résolveur peut déterminer si le nom demandé existe ou non sans autre requête. Donc, si vous tapez wwwwww.xxx puis wwww.xxx, la seconde requête pourrait bien donner lieu à un « non » très rapide (NXDOMAIN dans le domaine des DNS. La mise en cache négative agressive ne fonctionne qu'avec les zones signées DNSSEC, qui comprennent à la fois le serveur racine et 1400 des 1544 TLD signés à ce jour.

Nous utilisons la validation DNSSEC dans la mesure du possible, car cela nous permet de nous assurer que les réponses sont exactes et non falsifiées. Le coût des vérifications de signature est faible, et les économies potentielles que nous réalisons grâce à la mise en cache négative agressive le compensent largement. Nous voulons que nos utilisateurs aient confiance dans les réponses que nous leur donnons, par conséquent nous effectuons tous les contrôles possibles pour éviter de leur apporter de mauvaises réponses.

Toutefois, le protocole DNSSEC est impitoyable. Des erreurs de configuration DNSSEC par des opérateurs DNS de référence peuvent rendre insolubles les domaines mal configurés. Pour contourner ce problème, Cloudflare configurera des « certificats approuvés négatifs » sur les domaines avec des erreurs DNSSEC détectées et vérifiées et les supprimera une fois la configuration corrigée par les opérateurs de référence. Ceci limite l'impact des domaines DNSSEC défectueux en désactivant temporairement la validation DNSSEC pour un domaine mal configuré spécifique et en restaurant l'accès aux utilisateurs finaux.

Au départ, nous avons envisagé de créer notre propre résolveur, mais nous avons écarté cette idée en raison de sa complexité et de considérations liées à sa commercialisation. Ensuite, nous avons examiné tous les résolveurs open source disponibles sur le marché ; à partir de cette longue liste, nous en avons sélectionné deux ou trois qui répondaient à la plupart des impératifs de ce projet. En fin de compte, nous avons décidé de créer le système autour du Knot Resolver de CZ NIC. Il s'agit d'un résolveur moderne sorti il y a environ deux ans et demi. En choisissant le résolveur Knot, nous favorisons également la diversité des logiciels. Ce qui a fini de nous convaincre, c'est qu'il possédait un grand nombre des caractéristiques de base que nous voulions, avec une architecture modulaire similaire à celle de OpenResty. Le résolveur Knot est en cours d'utilisation et de développement.

Nous voulions disposer des fonctionnalités avancées suivantes :

• Minimisation de requêtes RFC7816,

• DNS-over-TLS (Sécurité de la couche de transport)RFC7858,

• DNS-over-HTTPSDoH,

• Les réponses négatives agressives RFC8198,

Petit avertissement : le développeur principal original de Knot Resolver, Marek Vavruša, travaille depuis plus de deux ans dans l’équipe de Cloudflare consacrée aux DNS.

De nombreux facteurs ont une incidence sur la rapidité d'un résolveur. Le premier et le plus important d'entre eux est de savoir s'il peut répondre à partir du cache Si c'est le cas, alors le temps de réponse correspond uniquement à la durée de l'aller-retour d'un paquet entre le client et le résolveur.

Quand un résolveur a besoin d'obtenir une réponse de la part d'une source de référence, les choses deviennent un peu plus compliquées. Un résolveur doit suivre la hiérarchie DNS pour résoudre un nom, ce qui signifie qu'il doit communiquer avec plusieurs serveurs de référence en commençant par le serveur racine. Par exemple, notre résolveur de Buenos Aires, en Argentine, prendra plus de temps à suivre une hiérarchie DNS que notre résolveur de Francfort, en Allemagne, du fait de sa proximité avec les serveurs de référence. Afin de contourner ce problème, nous remplissons au préalable notre cache, hors bande, avec les noms populaires, ce qui signifie que lorsqu'une requête arrive, les réponses peuvent être extraites du cache, ce qui est beaucoup plus rapide. Au cours des prochaines semaines, nous publierons des articles sur notre blog pour vous parler d'autres mesures que nous prenons pour rendre le résolveur plus rapide et l'améliorer, comme notre méthode de mise en cache rapide.

L'un des problèmes de notre réseau étendu est que le taux de réponse du cache est inversement proportionnel au nombre de nœuds configurés dans chaque centre de traitement de données. S'il n'y avait qu'un seul nœud dans le centre de traitement de données le plus proche de chez vous, alors vous pourriez être sûr(e) qu'en posant deux fois la même question, la deuxième réponse se retrouverait en cache. Cependant, étant donné que chacun de nos centres de données compte des centaines de nœuds, vous pourriez obtenir une réponse qui ne serait pas mise en cache, mais vous devriez subir un temps de latence pour chaque requête. Une solution courante consiste à mettre un répartiteur de charge en cache devant tous vos résolveurs, ce qui a pour effet regrettable d'introduire un point individuel de défaillance. Nous ne nous contentons pas de points individuels de défaillance.

Au lieu de s'appuyer sur un cache centralisé, le résolveur DNS 1.1.1.1.1 utilise un cache distribué innovant, dont nous parlerons dans un autre article.

En fait, nous ne stockons jamais les adresses IP des clients et nous n'utilisons que des noms de requêtes pour des éléments qui améliorent les performances du résolveur DNS (comme le pré-remplissage de tous les caches d'après des noms de domaines populaires dans une région et/ou après une offuscation ou une recherche APNIC).

Cloudflare ne stockera jamais dans ses registres des informations permettant d'identifier un utilisateur final, et tous les registres récupérés par notre résolveur public seront supprimés dans les 24 heures. Nous continuerons à respecter notre politique de confidentialité et nous veillerons à ce qu'aucune donnée de nos utilisateurs ne soit vendue à des annonceurs ou utilisée pour cibler des consommateurs.

C’est simple : rendez-vous sur https://1.1.1.1/ .

Nous remercions l'APNIC, notre partenaire, pour les adresses IPv4 1.0.0.1 et 1.1.1.1 (dont tout le monde s’accorde à dire qu’elles sont on ne peut plus simples à retenir). Sans les années de recherche et d'essais qu'ils ont consacrées à ces adresses, il serait impossible de les exploiter. Pourtant, il nous reste encore un long chemin à parcourir... Vous en saurez plus sur nos aventures avec ces adresses IP dans les prochains articles.

Pour IPv6, nous avons choisi 2606:4700:4700::1111 et 2606:4700:4700::1001 pour notre service. Il n'est pas aussi facile d'obtenir des adresses IPv6 faciles à retenir ; cependant, nous avons choisi une adresse qui n'utilise que des chiffres.

Mais pourquoi utiliser des adresses faciles à retenir ? Qu'est-ce que les résolveurs publics ont de spécial ? Bien que nous utilisions des noms pour presque tout ce que nous faisons, il faut qu'il y ait une première étape dans le processus et c'est là que ces chiffres entrent en jeu. Nous avons besoin d'un numéro inscrit dans n'importe quel ordinateur ou appareil connecté que vous utilisez afin de trouver un service de résolveur.

N'importe qui sur internet peut utiliser notre résolveur public et vous pouvez apprendre comment sur https://1.1.1.1/ et en cliquant sur COMMENCER.

Dans la plupart des pays du monde, la date de ce dimanche est le 1/4/2018 (en Amérique, le jour et le mois sont inversés, ce qui donne 4/1/2018). Voyez-vous le 4 et le 1 ? Nous l’avons remarqué, c’est pourquoi nous annonçons 1.1.1.1 aujourd'hui. Quatre chiffres un ! Si cela vous permet de vous souvenir 1.1.1.1, alors nous avons bien fait !

Bien sûr, c’est aussi le jour des poissons d’avril et pour une bonne partie des gens, c'est un jour de blagues, de bêtises ou de farces inoffensives. Il ne s'agit ni d'une blague, ni d'une farce, ni d'une bêtise. Il s’agit de notre résolveur DNS, 1.1.1.1 ! Suivez-le sur #1dot1dot1dot1