Qu’est-ce que le DNS (Domain Name System) ?

Souvent appelé « annuaire téléphonique de l’Internet », le DNS gère les noms de domaine comme un smartphone gère les contacts, pour faire une analogie plus actuelle. Les smartphones évitent aux utilisateurs de mémoriser tous les numéros de téléphone en les stockant dans des listes de contacts faciles à consulter.

De même, le DNS permet aux utilisateurs de se connecter aux sites Web à l’aide de noms de domaine Internet à la place des adresses IP. Au lieu d’avoir à se souvenir que le serveur Web se trouve sur « 192.0.2.1 », par exemple, les utilisateurs peuvent simplement se rendre sur la page Web « www.exemple.com » pour obtenir les résultats escomptés.

Pour comprendre le fonctionnement du DNS, il est important de connaître les composants impliqués.

Dès le départ, le DNS a été conçu avec une structure de base de données hiérarchique et distribuée, afin de faciliter une approche plus dynamique de la résolution des noms de domaine, capable de suivre l’évolution rapide des réseaux d’ordinateurs. La hiérarchie commence par le niveau racine, désigné par un point (.), et se ramifie en domaines de premier niveau (TLD) comme « .com », « .org », « .net », ou en TLD de code pays (ccTLD) tels que « .uk » et « .jp », et en domaines de deuxième niveau.

Les architectures DNS se composent de deux types de serveurs DNS : les serveurs récursifs et les serveurs faisant autorité. Les serveurs DNS récursifs sont ceux qui font la « demande », recherchant les informations qui connectent l’utilisateur à un site Web. Les serveurs faisant autorité fournissent les « réponses ».

Les serveurs récursifs, également appelés résolveurs récursifs ou résolveurs DNS, sont généralement gérés par les fournisseurs d’accès Internet (FAI) ou par des fournisseurs de services DNS tiers. Une entreprise peut également héberger et gérer son propre résolveur.

Les résolveurs récursifs agissent pour le compte de l’utilisateur final afin de convertir le nom de domaine en adresse IP. Les résolveurs récursifs mettent également en cache (stockent temporairement les résultats des recherches DNS récentes) les réponses aux requêtes pendant une durée donnée (définie par la valeur de durée de vie ou TTL), afin d’améliorer l’efficacité du système lors des futures requêtes sur le même domaine.

Lorsqu’un utilisateur tape une adresse Web dans son navigateur, ce dernier se connecte à un serveur DNS récursif pour résoudre la requête. Si le serveur récursif dispose de la réponse en cache, il peut connecter l’utilisateur et répondre à la requête. Sinon, le résolveur récursif interroge la hiérarchie DNS jusqu’à ce qu’il trouve les enregistrements A (ou AAAA) contenant l’adresse IP du domaine concerné.

Les serveurs de noms faisant autorité conservent les enregistrements définitifs d’un domaine et répondent aux requêtes sur les noms de domaine stockés dans leurs zones respectives (généralement avec des réponses configurées par le propriétaire du domaine). Il existe différents serveurs faisant autorité, chacun responsable d’une partie distincte de l’espace de noms.

Les serveurs racines de noms de domaine se situent au sommet de la hiérarchie DNS et desservent la zone racine (la base de données centrale du DNS). Il existe 13 « identités » ou « autorités » de serveurs racines de noms de domaine (groupes logiques de serveurs racines) identifiées par les lettres A à M. Ils répondent aux requêtes concernant les enregistrements stockés dans la zone racine et les renvoient au serveur de noms TLD approprié.

Les serveurs TLD sont responsables de la gestion du niveau suivant de la hiérarchie, y compris les domaines génériques de premier niveau (gTLD). Les serveurs de noms TLD dirigent les requêtes vers les serveurs de noms faisant autorité pour les domaines concernés au sein de leur TLD. Ainsi, le serveur de noms TLD pour « .com » dirigera les domaines se terminant par « .com », le serveur de noms TLD pour « .gov » dirigera les domaines se terminant par « .gov », et ainsi de suite.

Les serveurs de noms de domaine de second niveau, à savoir la majorité des serveurs de noms de domaine, contiennent des fichiers de zone avec l’adresse IP du nom de domaine complet (par exemple (« ibm.com »).

Outre les principaux types de serveurs, le DNS utilise des fichiers de zone et plusieurs types d’enregistrements pour faciliter le processus de résolution. Les fichiers de zone sont des fichiers texte qui incluent des mappages et des informations sur les domaines au sein d’une zone DNS.

Chaque ligne d’un fichier de zone spécifie un enregistrement de ressources DNS, une information sur un type ou un élément de donnée particulier. Les enregistrements de ressources permettent de s’assurer que lorsqu’un utilisateur soumet une requête, le DNS peut rapidement convertir les noms de domaine en informations exploitables qui dirigent les requêtes vers le bon serveur.

Les fichiers de zone DNS commencent par deux enregistrements obligatoires : l’enregistrement du serveur de noms (NS), qui indique le serveur de noms faisant autorité pour un domaine, et l’enregistrement SOA (start of authority), qui spécifie le serveur de noms principal faisant autorité pour la zone DNS.

Après les deux enregistrements principaux, un fichier de zone peut contenir plusieurs autres types d’enregistrements. Exemples :

Chaque requête (parfois appelée requête DNS) suit la même logique pour résoudre les adresses IP. Il existe différentes façons d’initier les requêtes. Prenons l’exemple d’une personne qui utilise un navigateur Web.

Lorsque l’utilisateur saisit une URL dans son navigateur Web, celui-ci envoie la requête au résolveur DNS, qui interroge progressivement les serveurs DNS faisant autorité pour localiser celui qui contient les enregistrements du domaine, y compris l’adresse IP associée. L’adresse IP est renvoyée au navigateur, et l’utilisateur est connecté au site Web.

Plus précisément, la résolution des requêtes dans le DNS implique plusieurs processus et composants clés.

• Initiation de la requête. L’utilisateur saisit un nom de domaine, tel que « ibm.com », dans un navigateur ou une application. Si l’adresse IP du site en question ne se trouve pas dans le cache du navigateur, la requête est envoyée à un résolveur DNS récursif. En règle générale, l’appareil de l’utilisateur dispose de paramètres DNS prédéfinis fournis par le FAI, qui déterminent quel résolveur récursif recevra la requête.
  
  *Ce processus évolue, car de nombreux navigateurs modernes prennent en charge le DNS sur HTTPS (DoH), ce qui permet la recherche DNS via HTTPS, et de nombreux fournisseurs disposent de serveurs configurés pour ce type de recherche. Par exemple, si vous utilisez Firefox aux États-Unis, il enverra par défaut la requête à un serveur DoH de Cloudflare, et non au résolveur du fournisseur d’accès local. La technologie DoH gagne en popularité, car elle offre une confidentialité accrue, une meilleure performance et d’autres avantages.

• Résolveur récursif. Le résolveur récursif vérifie si l’adresse IP correspondant au domaine se trouve dans son propre cache. Si le résolveur récursif ne possède pas les enregistrements nécessaires dans son cache, il initie le processus de recherche, en commençant par le serveur racine.

• Serveur racine de noms de domaine. Le résolveur récursif interroge un serveur racine de noms de domaine, qui répond avec une référence au serveur TLD approprié pour le domaine en question (le serveur de noms TLD responsable des domaines « .com » dans ce cas).

• Serveur de noms TLD. Le résolveur interroge le serveur de noms TLD « .com », lequel répond avec l’adresse du serveur de noms faisant autorité pour « ibm.com ».

• Serveur de noms de domaine. Le résolveur interroge le serveur de noms du domaine, lequel recherche le fichier de zone DNS et répond avec l’enregistrement correspondant au nom de domaine fourni.

• Résolution des requêtes. Le résolveur récursif renvoie l’adresse IP à l’appareil de l’utilisateur. Le navigateur ou l’application peut alors établir une connexion au serveur hôte à cette adresse IP et accéder au site Web ou au service demandé. Le navigateur et le résolveur mettent en cache les enregistrements conformément à leurs configurations et TTL respectifs.

Le DNS est en fait un protocole public. Les termes et concepts de DNS public et privé ne sont pas nécessairement exacts, universellement employés et compris, et leur utilisation est souvent imprécise.

Le terme de DNS public est souvent utilisé pour désigner le processus de résolution DNS « standard », ou les résolveurs DNS publics : un résolveur récursif interroge une succession de serveurs faisant autorité qui détiennent des enregistrements DNS accessibles publiquement, afin de localiser une adresse IP et, en fin de compte, de connecter l’utilisateur au site Web qu’il recherche. Il s’agit souvent d’un résolveur fourni par le fournisseur de services Internet de l’utilisateur ou par un service DNS comme le DNS public « quad 8 » de Google. Les résolveurs privés peuvent également être configurés pour interroger le DNS public, mais ils sont plus souvent utilisés pour les réseaux restreints ou les réseaux d’entreprise.

Cette requête DNS standard est probablement appelée « DNS public » en raison de ces résolveurs accessibles au public et du fait que les enregistrements DNS sur ces serveurs faisant autorité sont accessibles à toute personne ayant accès à Internet.

L’utilisation du terme « DNS privé » est encore plus floue. Il est parfois employé pour désigner l’utilisation protocoles de chiffrement tels que DNS over TLS (DoT) ou DNS over HTTPS (DoH). Toutefois, il serait plus juste de parler de « fonctionnalités de confidentialité » ou de « protocoles de protection de la vie privée » plutôt que de « DNS privé ». Le processus de résolution reste le même, en ce sens qu’un résolveur utilise le DNS accessible au public pour trouver ce dont il a besoin. Dans ce cas, il s’agit simplement d’un transfert chiffré.

Le terme « DNS privé » est également utilisé pour désigner une recherche au sein d’un réseau interne fermé, comme les réseaux d’entreprise ou les clouds privés virtuels, avec un accès restreint aux seuls utilisateurs autorisés. Dans un tel système, les résolveurs privés configurés localement interrogent les serveurs privés pour localiser les ressources et sites au sein d’un réseau interne. Ces serveurs sont configurés pour ne desservir que des zones privées et des adresses IP internes, et le réseau conserve les URL et les adresses IP internes masquées du reste de l’Internet. Ce type de DNS privé offre aux entreprises un contrôle et une sécurité accrus.

Il existe de nombreuses façons de configurer ce type de réseau. L’une d’entre elles consiste à utiliser un domaine à usage spécial tel que .local pour la résolution sur les réseaux locaux. Une autre solution consiste à créer des sous-domaines privés à partir des domaines accessibles au public sur Internet. Ce sous-domaine privé n’est accessible qu’aux personnes ou aux agents qui utilisent des résolveurs au sein du réseau interne.

Une configuration courante en entreprise, qui combine DNS « public » et « privé », est appelée « DNS split horizon » ou « DNS split brain ». Dans cette configuration, un serveur récursif local interroge les serveurs locaux et privés faisant autorité pour les requêtes internes, et s’appuie sur le DNS standard pour les requêtes externes. Il existe généralement une liste de noms de domaine, une sorte de « liste blanche », qui indique au serveur quelles requêtes sont destinées aux serveurs internes, et lesquelles doivent être transmises à l’Internet public.

Le DNS géré est un service tiers qui permet aux entreprises d’externaliser l’hébergement, les opérations et la gestion de son infrastructure DNS. Avec le DNS géré, les enregistrements DNS faisant autorité pour les domaines de l’entreprise sont hébergés sur le réseau mondial de serveurs du fournisseur. Dans de nombreux cas, les fournisseurs de services DNS gérés proposent un plan de contrôle central, un tableau de bord ou des API qui permettent aux clients de gérer et d’automatiser leurs enregistrements DNS et d’autres paramètres.

Les services DNS gérés offrent souvent des fonctionnalités telles que le routage Anycast, l’équilibrage de charge, les accords de niveau de service (SLA) de disponibilité, la protection failover, le DNSSEC et des outils de surveillance et de dépannage qui permettent une résolution de domaine plus rapide, plus fiable et plus sécurisée que celle proposée par les configurations DNS autogérées traditionnelles.

Même les meilleurs systèmes DNS peuvent être vulnérables aux problèmes de cybersécurité. Les attaques liées au DNS comprennent :

L’usurpation DNS, également appelée empoisonnement du cache, se produit lorsqu’un pirate insère de fausses adresses dans le cache d’un résolveur DNS pour l’obliger à renvoyer une adresse IP incorrecte et à rediriger les utilisateurs vers des sites malveillants. L’usurpation peut compromettre les données sensibles et entraîner des attaques par hameçonnage et la diffusion de logiciels malveillants.

L’amplification DNS est un type d’attaque DDoS qui consiste à envoyer de petites requêtes à un serveur DNS dont l’adresse de retour usurpe à l’adresse IP de la victime. Ces attaques exploitent la nature sans état des protocoles DNS et tirent parti du fait qu’une petite requête peut générer une réponse de grande ampleur.

À la suite d’une attaque par amplification, le serveur DNS répond avec des réponses beaucoup plus volumineuses, ce qui amplifie la quantité de trafic dirigé vers l’utilisateur, submergeant ainsi ses ressources. Cela peut empêcher le DNS de fonctionner et entraîner l’arrêt de l’application.

Le DNS tunneling est une technique employée pour contourner les mesures de sécurité en encapsulant le trafic non DNS, comme HTTP, dans les requêtes et les réponses DNS. Les attaquants peuvent utiliser des tunnels DNS pour relayer des commandes de logiciels malveillants ou exfiltrer les informations DNS d’un réseau compromis, souvent en encodant la charge utile dans les requêtes et les réponses DNS pour éviter la détection.

Les entrées DNS négligées correspondant à des sous-domaines qui pointent vers des services mis hors service sont des cibles privilégiées pour les pirates. Si un service (comme un hôte cloud) a été mis hors service mais que l’entrée DNS subsiste, un pirate peut potentiellement revendiquer le sous-domaine et configurer un site ou un service malveillant à sa place.

Quels que soient les services DNS choisis par l’entreprise, il est important de mettre en œuvre des protocoles de sécurité pour minimiser les surfaces d’attaque DNS, anticiper les problèmes de sécurité et optimiser le DNS dans les processus réseau. Voici quelques pratiques utiles pour renforcer la sécurité du DNS :

• Déployer des extensions de sécurité DNS (DNSSEC). DNSSEC ajoute une couche de sécurité aux requêtes DNS en exigeant que les réponses DNS soient signées numériquement. DNSSEC protège contre les attaques d’usurpation de DNS en authentifiant l’origine des requêtes et en vérifiant l’intégrité des données DNS.

• Adopter des pratiques de limitation du débit. La limitation du débit sur les serveurs DNS peut atténuer les attaques DDoS en limitant le nombre de réponses (ou la fréquence à laquelle les serveurs envoient les réponses) à un seul demandeur au cours d’une période donnée.

• Exiger une authentification à deux étapes (2FA) pour les bureaux d’enregistrement de domaines. La mise en place de l’authentification 2FA pour les comptes de registre de domaines rend l’accès non autorisé aux serveurs plus difficile à obtenir pour les pirates et contribue à réduire le risque de détournement de domaine.

• Utiliser les redondances. Le déploiement du DNS dans une configuration redondante sur plusieurs serveurs géographiquement dispersés peut contribuer à garantir la disponibilité du réseau en cas d’attaque ou de panne. Si le serveur principal tombe en panne, les serveurs secondaires peuvent prendre en charge les services de résolution DNS.

• Vider le cache DNS. L’effacement du cache DNS permet de supprimer toutes les entrées du réseau local, ce qui peut être utile pour supprimer les enregistrements DNS non valides ou compromis, susceptibles de diriger les utilisateurs vers des sites malveillants. En général, il s’agit d’un service à la demande fourni par l’opérateur du résolveur. Sinon, les caches sont vidés lorsque leur durée de vie (TTL) expire.
  
  
• Se tenir informé des menaces ciblant le DNS. Les attaquants et les menaces évoluent à peu près de la même manière que les systèmes qu’ils compromettent. Se tenir au courant des dernières vulnérabilités et menaces DNS aide les équipes à garder une longueur d’avance sur les acteurs malveillants.

Avant le DNS, Internet était un réseau d’ordinateurs en expansion, principalement utilisé par les établissements universitaires et de recherche. Les développeurs établissaient manuellement la correspondance entre les noms d’hôtes et les adresses IP à l’aide de simples fichiers texte appelés HOSTS.TXT, qui étaient gérés par SRI International et distribués à chaque ordinateur sur Internet. Cependant, à mesure que le réseau se développait, cette approche devenait intenable.

Pour s’affranchir des limites des fichiers HOSTS.TXT et créer un système plus évolutif, Paul Mockapetris, chercheur en informatique de l’Université de Californie du Sud, inventa le système de noms de domaine en 1983. La cohorte de pionniers de l’Internet qui a contribué à la création du DNS est également à l’origine des premières requests for comments (RFC)(RFC), qui détaillaient les spécifications du nouveau système, RFC 882 et RFC 883. Les RFC 1034 et RFC 1035 remplacèrent ensuite les RFC initiales.

Enfin, le système DNS prenant de l’ampleur, sa gestion a été placée sous la responsabilité de l’Internet Assigned Numbers Authority (IANA), avant de passer sous le contrôle de l’organisation à but non lucratif Internet Corporation for Assigned Names and Numbers (ICANN) en 1998.