--- id: "name-server" kind: "glossary-term" title: "serveur de noms" language: "fr" category: "DNS et bases techniques" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/fr/glossaire/serveur-noms/" translations: en: "https://tldlog.com/glossary/name-server/" es: "https://tldlog.com/es/glosario/servidor-nombres/" de: "https://tldlog.com/de/glossar/nameserver/" it: "https://tldlog.com/it/glossario/name-server/" pt-BR: "https://tldlog.com/pt/glossario/servidor-nomes/" ru: "https://tldlog.com/ru/glossariy/dns-server/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-fuwuqi/" --- # serveur de noms Serveur qui stocke des enregistrements DNS et répond aux questions sur les noms de domaine. Pour qu'un domaine fonctionne, le bureau d'enregistrement indique au registre quels serveurs de noms contiennent ses enregistrements. Changer les serveurs de noms d'un domaine change l'endroit où se trouvent son site web et sa messagerie. Un serveur de noms est l'ordinateur qui répond lorsque quelqu'un demande où se trouvent le site web ou la messagerie d'un domaine. Chaque domaine doit en avoir au moins deux, et le bureau d'enregistrement les déclare auprès du registre. S'ils manquent, s'ils sont erronés ou s'ils sont éteints, le domaine cesse de fonctionner, même s'il reste enregistré. ## Ce que fait un serveur de noms pour votre domaine Les termes « serveur de noms » et « serveur DNS » recouvrent deux fonctions. Les serveurs faisant autorité détiennent les enregistrements DNS d'un domaine et répondent pour lui ; les résolveurs posent ces questions pour le compte des utilisateurs. Le RFC 9499 (mars 2024), le document de terminologie du DNS, relève que les deux sont souvent appelés serveurs de noms. Ici, le terme désigne les serveurs faisant autorité. La zone située au-dessus du domaine, tenue par le registre de son TLD, contient des enregistrements NS qui désignent les serveurs du domaine. Cette délégation indique aux résolveurs où s'adresser. Le bureau d'enregistrement transmet ces noms au registre par EPP. Un domaine sans serveur de noms a le statut inactive et ne se résout pas. Le RFC 1034 (novembre 1987) exige que chaque zone soit hébergée sur au moins deux serveurs, afin de survivre à la panne de l'un d'eux. Le rapport SAC125 du SSAC (9 mai 2024) relève que les registres exigent généralement au moins deux serveurs à l'enregistrement et à chaque mise à jour. ## Bureau d'enregistrement, fournisseur DNS et hébergeur : qui gère vos serveurs de noms Trois rôles interviennent, assurés par une seule entreprise ou par trois : - Le bureau d'enregistrement déclare au registre les serveurs de noms qu'utilise le domaine. - Le fournisseur DNS exploite ces serveurs et la zone qui contient les enregistrements du domaine. Il peut s'agir du bureau d'enregistrement, d'un hébergeur web ou d'un spécialiste. - Les hébergeurs web et de messagerie gèrent les services vers lesquels pointent les enregistrements. Changer de fournisseur DNS ne change pas de bureau d'enregistrement : seuls les serveurs de noms déclarés pour le domaine sont remplacés. ## Changer de serveurs de noms, étape par étape 1. Configurez d'abord la zone chez le nouveau fournisseur DNS, avec tous les enregistrements qu'utilise le domaine, y compris le site web et la messagerie, et des enregistrements NS correspondant aux nouveaux serveurs de noms. 2. Si le domaine est signé avec DNSSEC, un enregistrement DS qui pointe encore vers les anciennes clés peut le rendre inaccessible pour les résolveurs qui vérifient les signatures. Lorsque l'ancien opérateur ne coopère pas, le RFC 6781 décrit l'ordre suivant : demander la suppression de l'enregistrement DS, changer les serveurs de noms, attendre que le changement se soit diffusé dans le DNS, puis ajouter un enregistrement DS pour la zone nouvellement signée. Jusque-là, le domaine n'est pas protégé par DNSSEC. 3. Vérifiez que le domaine n'est pas verrouillé contre les mises à jour : tant que clientUpdateProhibited ou serverUpdateProhibited est activé, le registre refuse les modifications. Le bureau d'enregistrement lève clientUpdateProhibited ; serverUpdateProhibited (verrouillage de registre) ne peut être retiré que par le registre, par l'intermédiaire du bureau d'enregistrement. 4. Saisissez les nouveaux serveurs de noms chez le bureau d'enregistrement, qui les transmet au registre. Indiquez-en au moins deux, idéalement sur des réseaux distincts. 5. Laissez l'ancien service fonctionner quelque temps : les résolveurs conservent des copies des réponses, si bien que certains visiteurs atteignent les anciens serveurs pendant des heures, voire plus. Ne supprimez pas l'ancienne zone le jour même. Les règles, les verrous et les délais dépendent du registre et du bureau d'enregistrement : renseignez-vous auprès d'eux avant de modifier un domaine important. ## Enregistrements glue et serveurs de noms dans votre propre domaine Prenons example.com, avec les serveurs de noms ns1.example.com et ns2.example.com. Pour trouver ns1.example.com, un résolveur devrait d'abord interroger les serveurs de noms d'example.com, c'est-à-dire précisément les serveurs qu'il cherche. La solution est l'enregistrement glue : le registre publie les adresses IP de ces serveurs avec la délégation. Le RFC 9471 (septembre 2023) rend ce glue obligatoire dans les réponses de renvoi, et relevait alors que les adresses (enregistrements A et AAAA) étaient le seul type de glue défini. Au registre, chaque serveur de noms est un objet hôte. Comme ns1.example.com se trouve sous example.com, le domaine doit exister d'abord ; le bureau d'enregistrement crée ensuite l'objet hôte avec ses adresses IP et y relie le domaine. Les adresses ne sont exigées que lorsqu'un glue est nécessaire : si example.com utilisait ns1.example.net, le registre de .com n'aurait besoin d'aucun glue pour ce serveur. ## Serveurs primaire et secondaires, et l'importance de la redondance Le serveur primaire détient la copie de la zone où sont faites les modifications. Les serveurs secondaires la copient par transfert de zone : un transfert complet (AXFR) copie toute la zone, un transfert incrémental (IXFR) seulement ce qui a changé. Le protocole DNS UPDATE (RFC 2136), la partie normalisée du DNS dynamique, ajoute ou supprime des enregistrements sans modifier la zone à la main. Deux serveurs sont le minimum, pas la recommandation : le RFC 2182 (juillet 1997) avertit qu'une zone qui n'en a que deux ne fonctionne plus en réalité qu'avec un seul dès que l'un tombe en panne, et en recommande trois pour la plupart des organisations, dont au moins un bien éloigné des autres, et quatre ou cinq pour une fiabilité accrue. Les exigences techniques de l'IANA (révisées pour la dernière fois le 14 novembre 2024, en octobre 2026) ne s'appliquent qu'à la zone racine, à .INT et à .ARPA, mais constituent une liste de contrôle utile : au moins deux enregistrements NS sur des adresses IP différentes, des serveurs situés dans au moins deux réseaux topologiquement distincts, des réponses faisant autorité et aucun service récursif. ## Ce qui tourne mal : délégations défaillantes et serveurs oubliés L'expression « lame delegation » (délégation défaillante) désigne plusieurs anomalies : un serveur déclaré qui ne répond pas, est injoignable, ou répond par une erreur ou sans faire autorité. Le RFC 9499 recommande des termes plus précis. Dans tous les cas, les résolutions ralentissent ou échouent. Une cause fréquente est le serveur oublié : un titulaire quitte un fournisseur DNS sans changer les enregistrements NS, et le domaine reste délégué à des serveurs qui ne répondent plus pour lui, ce qui peut ouvrir la voie à une prise de contrôle. Un risque moins visible : selon le SAC125, la plupart des registres refusent de supprimer un domaine expiré tant que d'autres domaines en dépendent, et le RFC 5731 indique qu'il ne devrait pas être supprimé avant que ses objets hôtes aient été supprimés ou renommés. Certains bureaux d'enregistrement les ont renommés dans un autre domaine. Le SAC125 appelle ces serveurs des serveurs de noms sacrificiels, dangereux lorsque cet autre domaine peut être enregistré : quiconque l'enregistre contrôle la résolution de tous les domaines qui les utilisent encore. En septembre 2020, selon le rapport, cette pratique avait exposé plus de 500 000 domaines gTLD à un risque de détournement, et la résolution de plus de 163 000 d'entre eux était passée sous un contrôle non autorisé ; le SAC125 relève que l'ampleur du phénomène dans les ccTLD est inconnue. Il recommande un code de conduite pour les registres et les bureaux d'enregistrement ; en octobre 2026, aucun code adopté n'avait été confirmé. Renouveler les domaines qui hébergent vos serveurs de noms réduit ce risque. ## Sources - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 2182: Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [Technical requirements for authoritative name servers (IANA)](https://www.iana.org/help/nameserver-requirements) - [SAC125: SSAC Report on Registrar Nameserver Management](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf) ## termes associés - [serveur faisant autorité](https://tldlog.com/fr/glossaire/serveur-faisant-autorite/) - [enregistrement NS](https://tldlog.com/fr/glossaire/enregistrement-ns/) - [enregistrement glue](https://tldlog.com/fr/glossaire/enregistrement-glue/) - [DNS](https://tldlog.com/fr/glossaire/dns/)