Publication : 19 avril 2024
Contributeurs : Chrystal R. China, Michael Goodwin
Le DNS (Domain Name System) est le composant du protocole Internet standard chargé de convertir les noms de domaine compréhensibles pour les utilisateurs en adresses IP (Internet Protocol) qui permettent aux ordinateurs de s’identifier sur le réseau.
Souvent appelé « annuaire téléphonique d’Internet », on peut dire aujourd’hui par analogie que le DNS gère les noms de domaine de la même manière que les smartphones gèrent les contacts. Les smartphones évitent aux utilisateurs de devoir se souvenir de 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 à des sites Web à l’aide de noms de domaine internet au lieu d’adresses IP. Plutôt que de devoir se souvenir de l’adresse du serveur Web, « 93.184.216.34 », par exemple, les utilisateurs peuvent simplement se rendre sur la page Web « www.example.com » pour obtenir les résultats escomptés.
Découvrez comment le DaaS (Desktop as a service) permet aux entreprises d'atteindre le même niveau de performance et de sécurité qu'en déployant les applications sur site.
Avant le DNS, Internet était un réseau d’ordinateurs en expansion principalement utilisé par les établissements universitaires et de recherche. Les développeurs effectuèrent le mappage des noms d’hôte aux adresses IP manuellement à l’aide d’un simple fichier texte nommé HOSTS.TXT. SRI International (anciennement Stanford Research Institute) conserva ces fichiers texte et les distribua à tous les ordinateurs sur Internet. Cependant, à mesure que le réseau se développait, cette approche n’était plus tenable.
Pour remédier aux limites des fichiers HOSTS.TXT et créer un système plus évolutif, Paul Mockapetris, informaticien de l’Université de Californie du Sud, inventa le système de noms de domaine en 1983. Une cohorte de pionniers d’Internet contribuèrent à la création du DNS et rédigèrent la première RFC (request for comment, ou demande de commentaires) détaillant les spécifications du nouveau système, RFC 882 et RFC 883. Les RFC 1034 et RFC 1035 remplacèrent ensuite les RFC d’origine.
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’Internet Corporation for Assigned Names and Numbers (ICANN) en 1998.
Obtenir le guide sur le cloud hybride
Dès le départ, les développeurs ont conçu le DNS 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 et suivre le rythme d’un réseau d’ordinateurs en pleine expansion. La hiérarchie commence par le niveau racine, indiqué par un point (.), et se divise en domaines de premier niveau (TLD), comme « .com », « .org », « .net » ou les TLD de codes pays (ccTLD ) comme « .uk » et « .jp », puis les domaines de deuxième niveau.
L’architecture DNS se compose de deux types de serveurs DNS, les serveurs récursifs et les serveurs faisant autorité. Les serveurs DNS récursifs sont ceux qui effectuent la « demande », recherchant les informations qui connectent un utilisateur à un site Web.
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), de grandes entreprises ou d’autres fournisseurs de services DNS tiers. Ces opérateurs agissent pour le compte de l’utilisateur final en convertissant le nom de domaine en adresse IP. Les résolveurs récursifs mettent également en cache les réponses à une requête pendant une certaine période (définie par la valeur de durée de vie ou TTL) afin d’améliorer l’efficacité du système pour les futures requêtes sur le même domaine.
Lorsqu’un utilisateur tape une adresse Web dans un navigateur de recherche, celui-ci 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. Dans le cas contraire, le résolveur récursif interroge une série de serveurs DNS faisant autorité pour trouver l’adresse IP et connecter l’utilisateur au site Web souhaité.
Les serveurs faisant autorité fournissent les « réponses ». Les serveurs de noms faisant autorité conservent les enregistrements définitifs d’un domaine et répondent aux requêtes de 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 types de serveurs de noms faisant autorité, chacun remplissant une fonction spécifique au sein de la hiérarchie DNS.
Les serveurs de noms DNS faisant autorité sont les suivants :
Les serveurs de noms racine se situent au sommet de la hiérarchie DNS et sont responsables de la gestion de la zone racine (la base de données centrale du DNS). Ils répondent aux requêtes concernant les enregistrements stockés dans la zone racine et les renvoient au serveur de noms TLD approprié.
Il existe 13 adresses IP utilisées pour interroger 13 réseaux de serveurs racine différents (identifiés par les lettres A à M) qui traitent les demandes de TLD et les dirigent vers les serveurs de noms de TLD appropriés. L’Internet Corporation for Assigned Names and Numbers (ICANN) exploite ces réseaux de serveurs racine.
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 spécifiques au sein de leur TLD. Ainsi, le serveur de noms TLD pour « .com » dirige les domaines se terminant par « .com », le serveur de noms TLD pour « .gov » dirige les domaines se terminant par « .gov », et ainsi de suite.
Le serveur de noms de domaine (parfois appelé serveur de noms de domaine de deuxième niveau) contient le fichier de zone avec l’adresse IP du nom de domaine complet, par exemple « ibm.com ».
Chaque requête dans le DNS (parfois appelée requête DNS) suit la même logique pour résoudre les adresses IP. Lorsqu’un utilisateur saisit une URL, son ordinateur interroge successivement les serveurs DNS pour localiser les informations et les enregistrements de ressources appropriés et répondre à la requête de l’utilisateur. Ce processus se poursuit jusqu’à ce que le DNS trouve la bonne réponse du serveur DNS faisant autorité associé à ce domaine.
Plus précisément, la résolution des requêtes dans le DNS implique plusieurs processus et composants clés.
Un utilisateur saisit un nom de domaine dans un navigateur ou une application, par exemple « ibm.com », et 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 fournisseur d’accès à Internet (FAI), qui déterminent quel résolveur récursif un client interroge.
Le résolveur récursif vérifie son cache – le stockage temporaire dans un navigateur Web ou un système d’exploitation (macOS, Windows ou Linux) qui contient les recherches DNS précédentes – pour trouver l’adresse IP correspondante du domaine. Si le résolveur récursif ne possède pas les données de recherche DNS dans son cache, il lance le processus de récupération des données auprès des serveurs DNS faisant autorité, en commençant par le serveur racine. Le résolveur récursif interroge la hiérarchie DNS jusqu’à ce qu’il trouve l’adresse IP finale.
Le résolveur récursif interroge un serveur de noms racine, qui répond avec une référence au serveur TLD approprié pour le domaine en question (le serveur de noms TLD responsable de « .com » dans ce cas).
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 ». Ce serveur est parfois appelé serveur de noms de domaine de deuxième niveau.
Le résolveur interroge le serveur de noms du domaine, lequel recherche le fichier de zone DNS et répond avec l’enregistrement correct pour le nom de domaine fourni.
Le résolveur récursif met en cache l’enregistrement DNS pendant une période spécifiée par la durée de vie de l’enregistrement (TTL) et 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 pour accéder au site Web ou au service demandé.
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 associés à un domaine au sein d’une zone DNS.
Chaque ligne d’un fichier de zone spécifie un enregistrement de ressources DNS (une seule information sur la nature d’un type ou d’une donnée particulière). Les enregistrements de ressources garantissent que, lorsqu’un utilisateur soumet une requête, le DNS peut rapidement convertir les noms de domaine en informations exploitables qui dirigent les utilisateurs vers le bon serveur.
Les fichiers de zone DNS commencent par deux enregistrements obligatoires : la durée de vie globale (TTL) qui indique comment les enregistrements doivent être stockés dans le cache DNS local, et le début de l’autorité (enregistrement SOA) 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, notamment :
Les enregistrements A sont mappés aux adresses IPv4 et les enregistrements AAAA sont mappés aux adresses IPv6.
Les enregistrements MX spécifient un serveur de messagerie SMTP pour un domaine.
Les enregistrements CNAME redirigent les noms d’hôte d’un alias vers un autre domaine (le « domaine canonique »).
Les enregistrements NS indiquent le serveur de noms faisant autorité pour un domaine.
Les enregistrements PTR spécifient une recherche DNS inversée, en mappant les adresses IP aux noms de domaine.
Les enregistrements TXT indiquent l’enregistrement du cadre de stratégie de l’expéditeur pour l’authentification des e-mails.
Les recherches DNS impliquent généralement trois types de requêtes. Les requêtes récursives, qui connectent le serveur récursif et le client DNS, résolvent complètement le nom de domaine ou renvoient un message d’erreur à l’utilisateur, l’informant qu’il n’est pas possible de localiser le domaine.
Les requêtes itératives, qui connectent des résolveurs récursifs (un serveur DNS local) et des serveurs DNS non locaux (comme les serveurs racine, TLD ou de noms de domaine), ne nécessitent pas de résolution de domaine. À la place, les serveurs peuvent répondre par une référence, où le serveur racine renvoie le résolveur récursif au TLD, lequel renvoie le résolveur à un serveur faisant autorité qui fournit la réponse (si la réponse est disponible). Par conséquent, les requêtes itératives sont résolues soit par une réponse, soit par une référence.
Dans le cas de requêtes non récursives, le résolveur récursif sait déjà où localiser la réponse à la requête, de sorte que ces requêtes sont toujours résolues avec une réponse. Le résolveur gagne du temps en trouvant la réponse mise en cache sur le serveur récursif ou en sautant la racine DNS et les serveurs de noms TLD pour accéder directement au serveur faisant autorité correspondant. Si, par exemple, le résolveur récursif fournit une adresse IP mise en cache lors d’une session précédente, la requête est considérée comme non récursive.
Les organisations disposent de plusieurs options lorsqu’elles utilisent le DNS, notamment le DNS public et privé, ou une combinaison des deux. Les DNS public et privé sont deux choses complètement différentes. Pour comprendre comment utiliser au mieux le DNS pour répondre aux besoins organisationnels, il est important de comprendre comment chaque type fonctionne.
Le DNS public fait généralement référence au côté résolveur du DNS et aux serveurs récursifs utilisés pour interroger les serveurs de noms faisant autorité et connecter les utilisateurs à des sites Web.
Ces serveurs sont accessibles à tout utilisateur de l’Internet, et des sociétés comme Cloudflare (1.1.1.1), Quad9 et OpenDNS les fournissent généralement gratuitement. Les serveurs du DNS public sont gérés par les organisations qui les exécutent. Les utilisateurs et les clients n’ont aucun contrôle sur leur fonctionnement, leur stratégie ou leur configuration.
Le DNS privé fait généralement référence à la partie faisant autorité du DNS. Les organisations configurent des serveurs DNS privés au sein d’un réseau privé, et ces serveurs agissent comme des serveurs DNS faisant autorité, fournissant une recherche DNS pour les ressources internes. Les serveurs DNS privés résident derrière un pare-feu et ne conservent que les enregistrements des sites internes. L’accès est donc limité aux utilisateurs, appareils et réseaux autorisés.
Contrairement aux configurations du DNS public, le DNS privé offre aux organisations le contrôle de leurs serveurs DNS, leur permettant de personnaliser les enregistrements DNS, d’appliquer des schémas de dénomination internes et d’exécuter des stratégies de sécurité spécifiques. Cela signifie également que les organisations sont responsables de la maintenance de l’infrastructure, qu’elle soit hébergée dans des centres de données sur site ou via des services cloud.
Les solutions DNS gérées externalisent essentiellement le processus de gestion et d’orchestration des serveurs. Dans un système géré, le fournisseur DNS gère l’ensemble des protocoles de configuration, de maintenance et de sécurité des serveurs DNS d’une organisation, et le client utilise l’infrastructure du fournisseur pour gérer les noms de domaine. Dans ce cas, lorsqu’un utilisateur saisit l’URL d’une entreprise, il est redirigé depuis le serveur de nom de domaine de l’entreprise vers les serveurs du fournisseur, qui récupèrent toutes les ressources et répondent à l’utilisateur.
Le DNS géré peut également offrir des services et des avantages tels qu’un DNS dédié, un équilibrage de charge global des serveurs, des garanties de temps de fonctionnement, une architecture API-first, la prise en charge DNSSEC, des réseaux anycast mondiaux, des temps de propagation accélérés, des outils de surveillance et de diagnostic de l’intégrité, une protection contre les attaques DDoS, etc.
La plupart des serveurs DNS modernes sont relativement bien sécurisés, même dans le cas du DNS public. Cependant, les meilleurs systèmes DNS peuvent encore être vulnérables aux problèmes de cybersécurité. Certains types d’attaques ciblent le côté faisant autorité du DNS tandis que d’autres ciblent le côté récursif. Ces attaques comprennent :
L’usurpation d’identité 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, ce qui oblige celui-ci à renvoyer une adresse IP incorrecte et à rediriger les utilisateurs vers des sites malveillants. L’usurpation d’identité 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 par déni de service distribué (DDoS) dans lequel un pirate envoie de petites requêtes à un serveur DNS avec l’adresse de retour usurpée à 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.
La tunnellisation DNS est une technique employée pour contourner les mesures de sécurité en encapsulant le trafic non DNS, comme HTTP, dans les requêtes DNS et les réponses. Les pirates peuvent utiliser des tunnels DNS pour relayer des commandes de logiciels malveillants ou exfiltrer des données d’un réseau compromis, en encodant souvent la charge utile dans les requêtes et les réponses DNS pour éviter d’être détectés.
Le détournement de domaine se produit lorsqu’un pirate obtient un accès non autorisé à un compte de registre de domaine et modifie les détails d’enregistrement d’un domaine. Le détournement permet aux pirates de rediriger le trafic vers des serveurs malveillants, d’intercepter les e-mails et de prendre le contrôle de l’identité en ligne de l’utilisateur.
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 une organisation, il est prudent d’implémenter des protocoles de sécurité pour minimiser les surfaces d’attaque DNS, d’atténuer les problèmes de sécurité potentiels et d’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) et de réseaux privés virtuels (VPN) : le DNSSEC ajoute une couche de sécurité aux recherches DNS en exigeant que les réponses DNS soient signées numériquement. Plus précisément, le DNSSEC peut protéger 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.
Les VPN préservent la confidentialité à l’aide du chiffrement pour masquer les adresses IP afin que les données de localisation et d’historique de navigation (entre autres) restent introuvables.
- 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 vitesse à laquelle les serveurs envoient des réponses) à un seul demandeur au cours d’une période donnée.
- Exiger une authentification à deux facteurs (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 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.
- Implémenter le vidage du cache DNS : l’effacement régulier du cache DNS supprime toutes les entrées du système local, ce qui peut être utile pour supprimer les enregistrements DNS non valides ou compromis qui pourraient diriger les utilisateurs vers des sites malveillants.
- Se tenir informé des menaces DNS. Les pirates informatiques et les menaces de sécurité évoluent sensiblement 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.
IBM NS1 Connect fournit des connexions rapides et sécurisées aux utilisateurs du monde entier grâce à un DNS de premier ordre et à une gestion avancée et personnalisable du trafic. L’architecture API-first permet à vos équipes informatiques de surveiller les réseaux, de déployer des modifications et d’effectuer une maintenance de routine de manière plus efficace.
Identifiez rapidement les erreurs de configuration et les problèmes de sécurité grâce à des rapports personnalisés en temps réel basés sur les données d’observabilité DNS Insights d’IBM NS1 Connect.
IBM Cloud DNS Services propose des services DNS public et DNS privé faisant autorité offrant un temps de réponse rapide, une redondance inégalée et une sécurité avancée, gérés via l’interface Web IBM Cloud ou par API.