--- id: "dns" kind: "glossary-term" title: "DNS" language: "fr" category: "DNS et bases techniques" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/fr/glossaire/dns/" translations: en: "https://tldlog.com/glossary/dns/" es: "https://tldlog.com/es/glosario/dns/" de: "https://tldlog.com/de/glossar/dns/" it: "https://tldlog.com/it/glossario/dns/" pt-BR: "https://tldlog.com/pt/glossario/dns/" ru: "https://tldlog.com/ru/glossariy/dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns/" --- # DNS système de noms de domaine Annuaire mondial qui convertit des noms lisibles par les humains, comme example.com, en adresses numériques utilisées par les ordinateurs. Il est organisé comme un arbre. La zone racine se trouve au sommet, puis viennent les domaines de premier niveau, puis les noms placés sous eux. Sans lui, les noms de domaine ne fonctionneraient pas. Le DNS (Domain Name System, système de noms de domaine) est l'annuaire d'internet. Les appareils sont joints par des adresses IP numériques (IPv4 ou IPv6), attribuées indépendamment des noms de domaine, alors que les gens utilisent des noms comme example.com. Le DNS relie les deux, pour qu'un nom tapé dans un navigateur ou utilisé dans une adresse électronique mène au bon ordinateur. Aucune organisation ne détient à elle seule l'annuaire entier : il est réparti sur de nombreux serveurs exploités par de nombreux opérateurs, qui conservent localement les réponses pendant un certain temps pour accélérer les choses. ## Ce qu'est le DNS et pourquoi internet en a besoin Le DNS a la forme d'un arbre. La zone racine se trouve au sommet. En dessous viennent les domaines de premier niveau (TLD), comme .com ou .es, et en dessous encore les noms que l'on enregistre. Un nom peut contenir plusieurs sortes d'enregistrements : des adresses (enregistrements A pour IPv4, AAAA pour IPv6), mais aussi les noms des serveurs qui en sont responsables (enregistrements NS) et des données de sécurité pour DNSSEC. ## Ce qui se passe quand on tape un nom de domaine : une recherche pas à pas Supposons qu'une application ait besoin de l'adresse de `www.example.com`. 1. L'application interroge le résolveur minimal (stub resolver), un petit logiciel DNS présent sur l'appareil. Celui-ci transmet la question à un résolveur récursif, généralement exploité par le fournisseur d'accès à internet ou par un service DNS public. 2. Le résolveur récursif consulte d'abord son cache. S'il détient déjà la réponse et que son TTL (time to live, durée de vie) n'a pas expiré, il répond immédiatement. 3. Sinon, il part du sommet. Il connaît les adresses des serveurs racine grâce à une liste intégrée, les root hints. 4. Un serveur racine ne connaît pas l'adresse de `www.example.com`. Il répond par un renvoi (referral) : où trouver les serveurs du .com. 5. Un serveur du .com ne connaît pas non plus la réponse finale. Il répond par un renvoi vers les serveurs de noms choisis par le titulaire de example.com. 6. L'un de ces serveurs de noms fait autorité pour example.com. Il renvoie l'adresse dans un enregistrement A ou AAAA. Le résolveur conserve la réponse aussi longtemps que son TTL le permet et la transmet à l'appareil. ## Résolveurs et serveurs faisant autorité : qui pose les questions et qui répond Les résolveurs posent les questions pour le compte des utilisateurs. Les serveurs faisant autorité y répondent à partir des données des zones qu'ils hébergent, sans interroger aucun autre serveur. Ce sont les serveurs de noms d'un domaine, indiqués dans ses enregistrements NS. Certains résolveurs récursifs sont des résolveurs DNS publics : des services destinés à être utilisés par n'importe qui sur internet, à la place de celui que fournit le fournisseur d'accès. Le terme technique « résolveur ouvert » (open resolver) désigne en général autre chose : un résolveur mal configuré qui répond à tout le monde par erreur. Comme chaque recherche passe par un résolveur, c'est aussi un endroit où des noms peuvent être filtrés. Les normes du DNS prévoient des codes d'erreur pour un nom bloqué par la politique propre de l'opérateur, bloqué à la demande d'un tiers, ou filtré à la demande de l'utilisateur. ## La délégation : comment le travail se répartit de la racine jusqu'à votre domaine L'arbre du DNS est découpé en zones. Une coupure se fait là où une organisation veut contrôler une partie de l'arbre, en modifier les données de façon autonome et en déléguer à son tour certaines parties plus bas. Une zone parente délègue une zone enfant en publiant des enregistrements NS qui pointent vers les serveurs de noms de la zone enfant. Pour un domaine comme example.com, la chaîne se présente ainsi : - L'IANA gère la zone racine et enregistre quels serveurs sont responsables de chaque TLD. PTI, une filiale de l'ICANN, assure les fonctions IANA, et l'IANA ne facture rien pour ces services. - Verisign, en tant que mainteneur de la zone racine (Root Zone Maintainer) en vertu d'un contrat avec l'ICANN, compile le fichier de la zone racine selon les instructions de l'IANA, le signe avec DNSSEC et l'envoie aux opérateurs des serveurs racine. - Les serveurs racine répondent par des renvois vers les serveurs de noms de chaque TLD. - Le registre du TLD publie dans sa propre zone les enregistrements NS de chaque nom enregistré, ainsi que des enregistrements glue et DS si nécessaire. - Les serveurs de noms choisis par le titulaire du domaine répondent pour le domaine lui-même. Cette délégation au sein du DNS se distingue de la délégation d'un TLD, qui consiste à ajouter un nouveau domaine de premier niveau à la zone racine. ## Les erreurs courantes comme NXDOMAIN et SERVFAIL, et ce qu'elles signifient Toute réponse DNS comporte un code de réponse. Deux codes d'erreur reviennent souvent. ### NXDOMAIN NXDOMAIN (code 3, « name error ») signifie que le nom n'existe pas, et qu'aucun nom situé en dessous n'existe non plus. Les causes habituelles sont une faute de frappe, un domaine non enregistré ou un domaine dont la délégation a été retirée de la zone de son TLD. ### SERVFAIL SERVFAIL (code 2, « server failure ») signifie que la recherche n'a pas pu aboutir. Ce code ne dit pas que le nom est absent, seulement qu'aucune réponse fiable n'a été obtenue. Les causes fréquentes sont : - des serveurs de noms déclarés pour une zone mais non configurés pour la servir ; - des serveurs de noms qui ne répondent pas, ou des pannes de réseau sur le trajet ; - des signatures DNSSEC qui échouent à la validation, auquel cas un résolveur qui valide doit renvoyer SERVFAIL. Un résolveur peut conserver une réponse SERVFAIL cinq minutes au plus. Les Extended DNS Errors (erreurs DNS étendues) permettent à un serveur d'en préciser la raison, par exemple « DNSSEC Bogus ». ### Un exemple concret Supposons que le titulaire de example.com fasse passer le domaine sur de nouveaux serveurs de noms sans les avoir encore configurés pour servir la zone. Les résolveurs qui suivent la nouvelle délégation peuvent renvoyer SERVFAIL tant que les nouveaux serveurs ne sont pas configurés. ## Qui exploite le DNS et qui le paie Aucune organisation n'exploite le DNS à elle seule. Chaque niveau a ses propres opérateurs et son propre mode de financement. - **Serveurs racine.** En octobre 2026, 13 identités nommées de serveurs racine sont exploitées par 12 organisations indépendantes, parmi lesquelles des universités, des entreprises et l'ICANN elle-même, à partir de plus de 2 000 instances dans le monde. Les opérateurs ne sont pas rémunérés pour ce service et le financent eux-mêmes. - **TLD.** Chaque registre de gTLD doit exploiter le DNS de son TLD selon des niveaux de service fixés dans son contrat avec l'ICANN. En octobre 2026, selon le contrat de registre de base approuvé le 12 mars 2026, le service DNS doit être disponible 100 % du temps, ce qui exige qu'au moins deux des serveurs de noms délégués du TLD répondent correctement. Un total de 4 heures d'indisponibilité du DNS sur une semaine constitue un seuil de transition d'urgence du registre. - **Domaines.** Le titulaire choisit les serveurs de noms faisant autorité du domaine, soit en payant un fournisseur, soit en utilisant des serveurs inclus gratuitement dans un autre service. Depuis 1987, les règles en demandent plus d'un : le RFC 1034 attend de quiconque prend en charge une zone qu'il démontre une prise en charge redondante par des serveurs de noms. - **Résolveurs.** Les fournisseurs d'accès à internet et les services DNS publics exploitent les résolveurs sur lesquels s'appuient les utilisateurs. ## Sources - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 1034: Domain Names - Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034.txt) - [RFC 8914: Extended DNS Errors](https://www.rfc-editor.org/rfc/rfc8914.txt) - [Root Name Servers (IANA)](https://www.iana.org/domains/root/servers) - [Root Zone Management (IANA)](https://www.iana.org/domains/root) - [Base Registry Agreement (ICANN), approved 12 March 2026](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-12-03-2026-en.pdf) ## termes associés - [zone racine](https://tldlog.com/fr/glossaire/zone-racine/) - [résolveur](https://tldlog.com/fr/glossaire/resolveur/) - [serveur de noms](https://tldlog.com/fr/glossaire/serveur-noms/) - [TLD](https://tldlog.com/fr/glossaire/tld/) - [nom de domaine](https://tldlog.com/fr/glossaire/nom-domaine/)