Date de publication : 7 juin 2024
Contributeurs : Chrystal R. China, Michael Goodwin
Une zone DNS (Domain Name System) est une entité logique distincte au sein de l’espace de noms de domaine du système DNS. Son but est d’offrir un contrôle plus granulaire à un administrateur, à une organisation ou à une autre entité juridique chargée de la gérer.
Les zones DNS divisent l’autorité sur différents segments de l’espace de noms DNS, par exemple un domaine et un sous-domaine. Les administrateurs bénéficient ainsi d’un contrôle plus précis sur les enregistrements DNS, les serveurs de noms DNS et d’autres composants. Ce partitionnement permet de rationaliser la gestion et l’orchestration DNS et de répartir les workloads entre les serveurs de noms.
Par exemple, le domaine « exemple.com » peut exister dans la même zone que les sous-domaines « blog.exemple.com » et « communaute.exemple.com ». Si les administrateurs ont besoin d’un contrôle plus granulaire, peut-être en raison du nombre d’appareils connectés au site de la communauté et du volume d’enregistrements DNS associés, ils peuvent partitionner le sous-domaine « communaute.exemple.com » en une zone à part entière, avec son propre serveur de noms faisant autorité.
Une zone DNS spécifie qu’un domaine, ou une partie d’un domaine, est géré par un administrateur donné. Cependant, une zone peut englober plusieurs sous-domaines et plusieurs zones peuvent exister sur le même serveur DNS faisant autorité. Les zones DNS n’impliquent pas de séparation physique, mais sont utilisées pour contrôler différentes parties de l’espace de noms.
Les zones permettent d’alléger la charge administrative associée à un domaine, de répartir la charge des requêtes DNS et d’améliorer l’efficacité et l’évolutivité globales des services DNS. Une gestion efficace des zones qui utilise des fonctionnalités de sécurité telles que le protocole DNSSEC et les mises à jour dynamiques contribue à renforcer la sécurité DNS et à réduire les menaces de sécurité telles que l’usurpation de DNS et les attaques par détournement.
Il est important de connaître le DNS et son fonctionnement pour comprendre les zones DNS.
Le DNS est un composant hiérarchique et décentralisé du protocole Internet standard chargé de convertir les noms de domaine compréhensibles pour les utilisateurs en adresses IP (Internet Protocol), lesquelles permettent aux ordinateurs de s’identifier sur le réseau1.
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 téléphones enregistrent les numéros dans des listes de contacts consultables et éliminent la nécessité pour les utilisateurs de mémoriser les différents numéros de téléphone. De même, le DNS permet aux utilisateurs de se connecter à des sites Web en utilisant des noms de domaine au lieu d’adresses IP complexes.
Lorsqu’un utilisateur saisit un nom de domaine dans un navigateur, cela génère une requête (souvent appelée requête DNS ou recherche DNS). Un résolveur récursif, c’est-à-dire l’intermédiaire entre l’appareil client et les serveurs faisant autorité, interroge ensuite une série de serveurs afin de trouver les informations nécessaires pour connecter l’utilisateur au site Web souhaité. Chacun de ces serveurs est responsable d’un segment de l’espace de noms de domaine.
Le processus de requête commence avec les serveurs de noms racine. Ces serveurs se situent au sommet de la hiérarchie DNS et sont responsables de la gestion de la zone racine. Ils répondent aux requêtes concernant les enregistrements stockés dans la zone racine et les renvoient au bon serveur de noms de domaine de premier niveau (« top-level domain » ou « TLD »).
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 contenant l’adresse IP du nom de domaine complet, par exemple « ibm.com ». Ce fichier de zone peut également contenir des informations pour un sous-domaine (par exemple blog.ibm.com/fr-fr), ou ces informations peuvent être partitionnées en zones à part entière.
Chacun de ces serveurs stocke des enregistrements DNS contenant des informations sur le domaine dont le résolveur récursif a besoin pour poursuivre son travail et, en fin de compte, résoudre la requête.
Bénéficiez d’une démonstration en direct d’IBM NS1 Connect pour accéder à nos solutions premium de DNS et de pilotage du trafic.
Abonnez-vous à la Think Newsletter
Un fichier de zone DNS est un fichier texte brut stocké sur des serveurs DNS qui contient tous les enregistrements des domaines au sein de cette zone.
Chaque ligne spécifie un enregistrement de ressources (une information unique, généralement organisée par type de données). Les enregistrements de ressources garantissent que lorsqu’un utilisateur lance une requête, le DNS peut rapidement l’orienter vers le bon serveur.
Les fichiers de zone DNS commencent par deux enregistrements obligatoires : SOA (« start of authority »), qui spécifie le serveur de noms faisant autorité principal pour la zone DNS, et TTL (« time to live »), qui indique comment les enregistrements doivent être stockés dans le cache DNS local.
Un fichier de zone peut contenir plusieurs autres types d’enregistrements, notamment :
- Les enregistrements A, qui mappent les adresses IPv4, et les enregistrements AAAA, qui mappent les adresses IPv6.
- Les enregistrements MX (Mail eXchanger), qui spécifient un serveur de messagerie SMTP pour un domaine.
- Les enregistrements CNAME (noms canoniques), qui redirigent les noms d’hôtes d’un alias vers un autre domaine (le « domaine canonique »).
- Les enregistrements de serveur de noms (enregistrements NS), qui indiquent qu’un serveur DNS est rattaché à un serveur de noms spécifique faisant autorité.
- Les enregistrements de pointeur (enregistrements PTR), qui spécifient une recherche DNS inversée.
- Les enregistrements texte (enregistrements TXT), qui indiquent l’enregistrement du cadre de stratégie de l’expéditeur pour l’authentification des e-mails.
La zone DNS primaire stocke le fichier de zone primaire contenant tous les enregistrements DNS de cette zone. Il s’agit d’une copie en lecture/écriture, et les mises à jour de zone sont apportées à la zone primaire, puis copiées dans les zones secondaires. Il ne peut y avoir qu’une seule zone primaire à la fois sur un même serveur DNS.
Une zone secondaire est une copie en lecture seule de la zone primaire, utilisée pour créer une redondance et mettre en œuvre l’équilibrage de charge pour les requêtes DNS.
Les requêtes DNS sont généralement distribuées sur les serveurs primaires et secondaires. Si le serveur primaire est en panne, les serveurs secondaires peuvent assumer tout ou partie de la charge à l’aide des transferts de zone, c’est-à-dire une transaction qui permet aux serveurs primaires et secondaires d’échanger des zones. Les zones secondaires vérifient également auprès des serveurs primaires que les répliques sont à jour.
La zone de recherche directe traduit les noms de domaine en adresses IP. Lorsqu’un résolveur DNS reçoit une requête pour un nom de domaine lisible par l’humain, il consulte les enregistrements A ou AAAA dans la zone de recherche directe pour trouver l’adresse IP correspondante.
À l’opposé de la zone de recherche directe, la zone de recherche inversée renvoient les adresses IP aux noms de domaine à l’aide des enregistrements PTR.
Ce processus peut être utile pour déployer des services qui nécessitent une vérification du domaine ou à des fins de journalisation lorsque les équipes ont besoin de comprendre le domaine associé à une adresse IP (par exemple pour le dépannage et le filtrage des spams). Dans la zone de recherche DNS inversée, les requêtes utilisent les domaines in-addr.arpa ou ip6.arpa.
Les zones de stub contiennent uniquement les enregistrements dont le système a besoin pour identifier les serveurs de noms faisant autorité pour une zone donnée. Elles servent de pointeur, réduisant la dépendance aux serveurs récursifs pour interroger les zones de niveau supérieur et localiser le serveur faisant autorité. La proximité des zones de stub et des serveurs faisant autorité permet de réduire le trafic des requêtes DNS et de raccourcir les temps de résolution.
Les transferts de zone DNS permettent de maintenir une fonctionnalité optimale du système, en particulier dans les environnements où la redondance et la haute disponibilité sont des priorités.
Un transfert de zone complet copie l’intégralité du contenu d’un fichier de zone, du serveur DNS primaire vers les serveurs secondaires, afin de créer une réplique exacte de la zone. Les transferts de zone complets sont couramment utilisés lors de la configuration initiale des serveurs secondaires ou lorsque les serveurs secondaires doivent être resynchronisés après un long temps d’arrêt.
Les transferts de zone incrémentiels comprennent uniquement les modifications apportées à la zone depuis le dernier transfert. Parce qu’ils nécessitent moins de bande passante et de puissance de traitement pour maintenir les processus de synchronisation, ces transferts peuvent être utiles dans les zones dynamiques qui subissent des changements fréquents.
Les organisations peuvent utiliser différentes zones pour distribuer la charge administrative associée à un domaine et éviter qu’un administrateur ou serveur particulier ne soit submergé.
Les organisations peuvent utiliser les zones DNS pour obtenir un contrôle plus granulaire sur la gestion des enregistrements DNS et la distribution du trafic. Cette fonctionnalité leur permet de gérer les enregistrements DNS en fonction de leurs besoins, sans attendre que les modifications se propagent via un système central.
Les zones DNS facilitent la distribution du trafic internet sur différents serveurs en permettant aux administrateurs de zone de configurer des paramètres DNS personnalisés pour l’équilibrage de charge et le basculement.
La délégation d’autorité au sein des zones signifie que les résolveurs DNS peuvent réduire le nombre de sauts nécessaires pour résoudre un nom de domaine, accélérant ainsi les processus de routage et de récupération des données.
Le service IBM NS1 Connect Managed DNS fournit des connexions DNS résilientes, rapides et fiables pour éviter les pannes de réseau et permettre à votre entreprise de rester en ligne en permanence.
Optimisez l’expérience de l’utilisateur final et améliorez la résilience de votre réseau à moindre coût avec l’équilibrage global de charge des serveurs IBM NS1 Connect, une nouvelle approche optimisée par le DNS et les données de performance des appareils en temps réel.
IBM Cloud DNS Services propose des services DNS publics et privés qui font autorité grâce à un temps de réponse rapide, une redondance inégalée et une sécurité avancée, dont la gestion se fait via l’interface Web IBM Cloud ou par API.
Le DNS permet aux utilisateurs de se connecter à des sites web en utilisant des URL plutôt que des adresses IP (Internet Protocol) numériques.
Les serveurs DNS traduisent les noms de domaine des sites que les utilisateurs recherchent dans les navigateurs web en adresses IP numériques. Ce processus est connu sous le nom de résolution DNS.
Un enregistrement DNS (Domain Name System) est un ensemble d’instructions utilisées pour connecter les noms de domaine aux adresses IP (Internet Protocol) au sein des serveurs DNS.
Les cyberattaques désignent les tentatives de vol, d’exposition, d’altération, de désactivation ou de destruction des biens d’autrui via un accès non autorisé à des systèmes informatiques.
Découvrez pourquoi de grandes entreprises songent à créer et à héberger leur propre service DNS faisant autorité.
Découvrez le fonctionnement des réseaux informatiques, l’architecture utilisée pour concevoir les réseaux et la sécurisation des réseaux.
Notes de bas de page
1 « What is a DNS zone? », Chrystal China, IBM.com, 7 juin 2024