Publication : 1er mars 2024
Contributeurs : Chrystal R. China, Michael Goodwin
Un serveur DNS primaire est le serveur de noms faisant autorité d’un système de noms de domaine (DNS). Il s’agit du premier point de contact dans la résolution des requêtes et il sert de source fiable d’informations sur un domaine : c’est lui qui stocke les copies d’origine de tous les enregistrements DNS du domaine.
Si le serveur DNS primaire n’est pas disponible, le navigateur, l’application ou l’appareil qui a lancé la requête contacte un serveur DNS secondaire, qui contient une copie des mêmes enregistrements DNS.
Dans une infrastructure DNS, les noms de domaine dirigent le trafic vers les adresses IP qui contiennent les ressources nécessaires pour répondre aux demandes des utilisateurs. Lorsque les utilisateurs saisissent un nom de domaine, le serveur DNS primaire est le premier arrêt sur le parcours de résolution de la requête. Cependant, les noms d’hôtes, lisibles par les humains, et les adresses IP, lisibles par les ordinateurs, ont besoin d’un intermédiaire pour communiquer. C’est là que les serveurs DNS primaires entrent en jeu.
Les serveurs primaires traduisent les noms de domaine en adresses IP, puis les informations demandées sont renvoyées à l’utilisateur. De ce fait, le DNS primaire joue un rôle essentiel dans le routage du trafic internet.
Le Guide de l'entreprise pour l'IA et l'automatisation informatique offre un aperçu approfondi de l'automatisation informatique alimentée par l'IA, y compris pourquoi et comment l'utiliser, les problèmes qui bloquent vos efforts et comment commencer.
Abonnez-vous à la newsletter IBM
D’une manière générale, le DNS s’apparente à un annuaire téléphonique pour Internet. Il convertit les noms de domaine (tels que www.exemple.com) en adresses IP (comme 192.0.2.1) que les ordinateurs utilisent pour s’identifier les uns aux autres sur le réseau. Sans DNS, les utilisateurs devraient se souvenir d’adresses IP numériques complexes pour accéder aux sites web, une méthode peu commode, même compte tenu du volume de recherches et de demandes de données uniques que les utilisateurs effectuent en une seule journée.
Les cadres DNS ont une structure arborescente qui commence avec le domaine racine en haut, suivi des domaines de premier niveau (TLD), tels que .com, .org, .net, .uk et ainsi de suite. Sous les TLD se trouvent les domaines de second niveau, qui comprennent généralement la partie reconnaissable d’un nom de domaine (comme « ibm.com ») et toutes les zones secondaires disponibles. Chaque TLD possède son propre ensemble de serveurs de noms, mais le serveur de noms primaire entre en jeu au deuxième niveau.
Lorsqu’un domaine est enregistré, les enregistrements correspondants du serveur de noms (NS) sont créés et stockés sur un serveur DNS primaire, généralement fourni par une société d’hébergement ou un fournisseur de services DNS. Le serveur DNS primaire contient différents types d’enregistrements NS, notamment des enregistrements A, des enregistrements MX et des enregistrements CNAME (entre autres), qui renvoient les données et les informations appropriées à l’utilisateur.
Notez que les administrateurs de serveurs peuvent désigner les DNS comme serveurs primaires ou secondaires. En fait, un DNS peut être le serveur primaire d’une zone et un serveur secondaire dans une autre. Cependant, chaque zone DNS ne peut avoir qu’un serveur primaire.
Des modifications de domaine se produisent également dans le DNS primaire. Lorsqu’un administrateur souhaite ajuster les enregistrements DNS, il doit le faire dans les serveurs DNS primaires. Les modifications sont ensuite propagées aux serveurs restants dans la hiérarchie.
Les serveurs DNS peuvent être « primaires » et « secondaires » en fonction de leurs rôles dans la hiérarchie DNS. Alors que le serveur DNS primaire contient la version en lecture/écriture d’origine du fichier de zone, les serveurs DNS secondaires contiennent des réplicas en lecture seule du fichier de zone à des fins d’équilibrage de charge et de gestion de la redondance.
Les services DNS secondaires sont non essentiels : les systèmes DNS peuvent fonctionner si un seul serveur primaire est disponible. Mais il s’agit d’une pratique standard, et souvent exigée par les registres de domaine, d’avoir au moins un serveur secondaire pour faciliter le DNS round-robin (qui distribue le trafic de manière égale sur chaque serveur) et éviter les dénis de service.
L’architecture DNS primaire/secondaire conventionnelle est en passe de devenir obsolète chez les fournisseurs de DNS modernes gérés. Aujourd’hui, la plupart des fournisseurs proposent des adresses IP de serveurs de noms, et derrière chacune de ces adresses IP se trouve un pool de serveurs DNS qui acheminent les requêtes à l’aide de la technique Anycast (un protocole de transport un-à-plusieurs). Cette approche tend à offrir une meilleure redondance et une plus grande disponibilité que le modèle classique.
Cependant, même dans les déploiements DNS avancés, le DNS secondaire peut aider les entreprises dans les démarches suivantes :
- Effectuer une migration vers une nouvelle infrastructure DNS, avec des dépendances sur d’anciens serveurs DNS. Le DNS secondaire permet aux équipes d’accéder à des outils, du code et des systèmes existants pointant vers un ancien serveur DNS hébergé dans leur organisation. Lors de la migration de l’architecture, les serveurs secondaires permettent aux administrateurs de définir le fournisseur DNS secondaire sans rompre les dépendances. Cela maintient la synchronisation de tous les processus existants, mais permet au nouveau serveur DNS de répondre si les serveurs internes ralentissent ou tombent en panne.
- Éviter les points de défaillance uniques. Les sites à fort trafic et les applications web stratégiques ne peuvent tolérer les pannes. L’utilisation de serveurs de noms secondaires permet aux administrateurs d’éviter les points de défaillance uniques si les serveurs DNS primaires venaient à rencontrer des problèmes de latence.
- Mettre en place un DNS redondant avec un seul service géré. Avec un DNS géré intelligent, un déploiement de DNS dédié est possible : il fonctionne sur un réseau et sur des serveurs distincts de son service DNS géré habituel. Cela facilite la redondance entre deux serveurs DNS distincts, tout en permettant aux organisations de faire appel à un fournisseur unique. De plus, le déploiement dédié n’est pas partagé avec d’autres organisations : il est donc à l’abri des attaques ciblant d’autres clients du service.
Les serveurs primaires et secondaires garantissent l’efficacité et la fonctionnalité des systèmes DNS, mais des différences clés dictent leurs comportements et leurs interactions dans l’environnement informatique.
En plus de stocker le fichier de zone principal, le serveur DNS primaire répond aux demandes de mise à jour de l’administrateur de domaine et traite les mises à jour dynamiques. Les serveurs de zone secondaires sont des serveurs de secours qui traitent les requêtes pendant les temps d’arrêt du serveur primaire ou quand ce dernier est surchargé.
Le fichier de zone principal du DNS primaire contient tous les enregistrements A (enregistrements d’adresses IPv4), enregistrements AAAA (enregistrements d’adresses IPv6), enregistrements MX (qui dirigent vers les serveurs de messagerie), enregistrements CNAME (qui mappent les alias à leurs véritables noms de domaine, ou noms de domaine « canoniques »), enregistrements SOA (qui contiennent toutes les informations administratives d’un domaine) et enregistrements TXT (qui contiennent l’enregistrement du cadre des politiques de l’expéditeur pour l’authentification des e-mails) pour un domaine donné. L’administrateur gère directement ce fichier, et toute mise à jour ou modification des enregistrements DNS est effectuée ici en premier lieu.
Les serveurs DNS secondaires sont des copies exactes du fichier de zone. Ils sont transférés depuis le serveur primaire. Ils ne permettent pas la révision ou les modifications directes du fichier de zone. Ce qu’ils font, c’est qu’ils vérifient périodiquement les mises à jour auprès du serveur primaire lors du processus appelé transfert de zone.
La configuration d’un DNS primaire implique la mise en place du fichier de zone, des enregistrements de ressources et des contrôles d’accès, et peut inclure l’organisation de transferts de zones complets (AXFR) et incrémentiels (IXFR) vers des serveurs secondaires désignés. Les configurations DNS secondaires exigent toutefois que les administrateurs mettent en place des protocoles de communication entre les serveurs primaire et secondaire pour les transferts de données de zone, et qu’ils spécifient la fréquence des vérifications avec le serveur primaire pour les mises à jour.
Bien que le serveur DNS primaire soit essentiel, il représente également un point de défaillance unique. S’il tombe en panne et que les administrateurs n’ont pas désigné de serveurs secondaires pour prendre le relais, c’est l’ensemble du processus de résolution DNS qui en pâtit. Les serveurs secondaires ne peuvent pas exister sans serveur DNS primaire, mais en cas de panne du serveur, ils peuvent maintenir le DNS opérationnel jusqu’à la restauration du serveur primaire.
Pour mieux comprendre le DNS primaire, il est important de comprendre comment les requêtes des utilisateurs circulent dans le système jusqu’à leur résolution.
Un utilisateur saisit un nom de domaine dans un navigateur ou une application, 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 est déployé.
Le résolveur récursif vérifie son cache (c’est-à-dire le stockage temporaire dans un navigateur web ou un système d’exploitation) pour trouver l’adresse IP correspondante du domaine. Si les données de recherche DNS ne se trouvent pas dans le cache, le résolveur lance le processus de récupération auprès des serveurs DNS faisant autorité, en commençant par le serveur racine. Le résolveur récursif interroge les différents serveurs 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 responsable de tous les domaines « .com », par exemple).
Le résolveur interroge le serveur de noms TLD, qui répond avec l’adresse du serveur DNS primaire du domaine.
Le résolveur interroge le serveur primaire, qui recherche le fichier de zone DNS et répond avec l’enregistrement correct pour l’URL fournie.
Le résolveur récursif met en cache l’enregistrement DNS pendant une période spécifiée par la durée de vie (TTL) de l’enregistrement 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é.
Le DNS primaire se trouvant au cœur du routage des requêtes, la maintenance et l’optimisation des serveurs DNS primaires peuvent accélérer l’ensemble du système DNS. Les entreprises peuvent tirer le meilleur parti de leur DNS en intégrant les bonnes pratiques suivantes.
Sélectionnez un fournisseur DNS proposant des temps de fonctionnement élevés, des protocoles de redondance complets et un support client accessible. IBM NS1, par exemple, peut contribuer à garantir une réponse rapide et fiable aux requêtes DNS.
Les offres des principaux fournisseurs de DNS varient, des services DNS publics aux serveurs DNS gérés haut de gamme. Le choix du serveur DNS le mieux adapté à votre entreprise dépend de vos besoins organisationnels1, de vos budgets et de la complexité de votre environnement. Si, par exemple, l’utilisation du DNS public fournit aux clients un accès DNS ouvert et gratuit, une migration vers un DNS haut de gamme peut leur offrir un contrôle plus précis.
Assurez-vous que les équipes sont informées des dernières vulnérabilités et menaces DNS (logiciels malveillants, attaques DDoS distribuées et usurpation de cache) et utilisez des pare-feu, des extensions de sécurité du système des noms de domaine (protocole DNSSEC) et d’autres mesures de sécurité pour sécuriser les serveurs DNS2 et atténuer les risques.
Mettez à jour les enregistrements DNS pour qu’ils reflètent aussi rapidement et aussi souvent que possible les changements d’adresses IP, d’infrastructure et de services. Cela permet une résolution de domaine cohérente et précise.
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.
Améliorez la résilience et la disponibilité des applications grâce à un réseau mondial et à des capacités avancées de direction du trafic DNS.
IBM Cloud DNS Services propose des services DNS publics et privés faisant autorité grâce à un temps de réponse rapide, une redondance inégalée et une sécurité avancée, et dont la gestion s’effectue 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.
La propagation DNS désigne le temps nécessaire aux serveurs DNS pour propager les modifications apportées à un enregistrement DNS sur Internet.
Un enregistrement CNAME, ou enregistrement de nom canonique, sert d’alias au sein du système de noms de domaine (DNS), redirigeant un nom de domaine vers un autre.
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 « Should large enterprises self-host their authoritative DNS? », IBM.com, 1er février 2024
2 « Why DNS protection should be the first step in hybrid cloud security », (lien externe à ibm.com) TechRadar, 1er février 2024