Outils populaires

Thème

NS Lookup — Vérifier les serveurs de noms

Pour vérifier les serveurs de noms de n'importe quel domaine : les enregistrements NS que son registre fournit, avec glue et TTL, à côté de ce que chaque serveur de noms dit de lui-même. Les serveurs lames, les écarts et la glue périmée sont nommés, avec la correction.

Sources : les serveurs du registre, atteints depuis un serveur racine · les adresses IPv4 de chaque serveur de noms, interrogées directement · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

Interroge d'abord le registre, puis chaque serveur de noms qu'il indique. Une URL, une adresse e-mail ou un sous-domaine convient.

Essayez

Qu'est-ce qu'un enregistrement NS ?

Un enregistrement NS nomme un serveur qui détient une zone : l'endroit où vivent les enregistrements d'un domaine. Une zone liste un enregistrement NS par serveur : google.com en a donc quatre, ns1 à ns4.google.com (RFC 1035 §3.3.11).

Les mêmes enregistrements NS existent en double. La zone parente, ici .com, en garde une copie à la coupure pour pouvoir envoyer les résolveurs plus loin ; cette copie ne fait pas autorité. La zone garde sa propre copie à son sommet, et celle-là fait autorité (RFC 1034 §4.2.1, RFC 2181 §6.1). Les deux devraient être exactement identiques.

La valeur est toujours un nom d'hôte, jamais une adresse, et jamais un alias : le nom doit avoir ses propres enregistrements A ou AAAA (RFC 2181 §10.3).

Un enregistrement NS, champ par champgoogle.com · relevé le 2026-10-23
google.com.Propriétaire345600TTLINClasseNSTypens1.google.com.Valeur
PropriétaireLa zone à laquelle appartient l'enregistrement.
TTL · 4 joursCombien de temps un résolveur peut le garder. La copie de .com indique 2 jours.
NSType d'enregistrement 2 : un serveur de noms pour cette zone.
ValeurUn nom d'hôte avec ses propres enregistrements A ou AAAA.
La copie du parent · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10Ne fait pas autorité : un renvoi, avec glue
La copie propre à la zonegoogle.com. 345600 NS ns1.google.com.;; flags: qr aaFait autorité : ce que les résolveurs gardent
ns1.google.com.Un nom d'hôte avec ses propres adresses
216.239.32.10Une adresse n'est pas une valeur valide
ns.example.com. → CNAMEJamais un alias (RFC 2181 §10.3)
Les deux copies relevées en direct : le renvoi du registre .com depuis l'adresse l.gtld-servers.net et la réponse propre de ns1.google.com.

Comment vérifier les serveurs de noms d'un domaine

Saisissez le domaine ci-dessus et appuyez sur Vérifier les serveurs de noms : nous interrogeons le registre, puis chaque serveur qu'il indique et que notre serveur peut joindre. Depuis un terminal : dig NS example.com sur macOS et Linux, nslookup -type=ns example.com sur Windows, Resolve-DnsName -Name example.com -Type NS dans PowerShell.

Ces trois commandes interrogent votre propre résolveur : elles montrent donc une copie en cache. Pour voir la liste du registre, interrogez son serveur avec la récursivité désactivée : dig @a.gtld-servers.net example.com NS +norec. Pour tester un serveur de noms, demandez-lui le SOA avec +norec et cherchez aa dans les flags. whois montre aussi la liste du registre, pas celle de la zone.

dig NS example.com +short

La copie de votre résolveur, un serveur de noms par ligne. Ajoutez @a.gtld-servers.net et +norec pour la liste propre du registre .com.

Lire les deux réponses de diggoogle.com · relevé le 2026-10-23
dig · macOS, Linux
$ dig @l.gtld-servers.net google.com NS +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 91
;; AUTHORITY SECTION:
google.com.       172800  IN  NS  ns2.google.com.2
google.com.       172800  IN  NS  ns1.google.com.
…
;; ADDITIONAL SECTION:
ns1.google.com.   172800  IN  A   216.239.32.103
…

$ dig @216.239.32.10 google.com NS +norec
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 04
google.com.       345600  IN  NS  ns1.google.com.5
…
  1. Pas de aa : un renvoi. Le registre ne sert pas google.com ; il dit où aller.
  2. La liste du parent et son TTL : 2 jours, fixé par le registre .com.
  3. Glue : ns1.google.com est dans google.com : .com fournit donc son adresse.
  4. aa : la zone elle-même. Une réponse faisant autorité du serveur.
  5. Le TTL propre à la zone : 4 jours, fixé par Google, pas par le registre.
nslookup · interroge 8.8.8.8
$ nslookup -type=ns google.com 8.8.8.8
Server:   8.8.8.8
Address:  8.8.8.8#53

Non-authoritative answer:
google.com  nameserver = ns3.google.com.
google.com  nameserver = ns1.google.com.
…
PowerShell
# la copie de votre résolveur
PS> Resolve-DnsName -Name google.com -Type NS

# un serveur, récursivité désactivée
PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion
whois
$ whois google.com
Registrar: MarkMonitor Inc.
Name Server: NS1.GOOGLE.COM
…
DNSSEC: unsigned
Relevé le 2026-10-23. « Non-authoritative answer » désigne la copie en cache d'un résolveur, ici Google Public DNS, qui garde les enregistrements NS 6 heures au plus. whois affiche la liste du registre. Aucun des deux ne montre ce que dit chaque serveur.

Lire le résultat

Le verdict nomme l'hébergeur DNS et le registrar ; la vue Délégation met la liste du registre à côté de celle de la zone, serveur par serveur, avec la réponse de chacun et son temps en TCP (ouverture de la connexion comprise, soit environ deux allers-retours).

La colonne bleu marine est le chemin que suit un résolveur : la racine, le registre avec son TTL et son DS, puis chaque serveur de noms. Un serveur qui ne sert pas la zone est coupé du chemin.

NS Lookup de github.com : huit serveurs de noms chez NS1 et Route 53, la réponse de chacun et la délégation depuis .comNS Lookup de github.com : huit serveurs de noms chez NS1 et Route 53, la réponse de chacun et la délégation depuis .comLe verdictQui sert la zone, qui l'a enregistrée, et si le registre et la zone concordent.Le registre à côté de la zoneChaque nom de la liste du registre et de celle de la zone, avec la glue et la réponse.La réponse de chaque serveurAA et son temps en TCP, le code envoyé par un serveur qui refuse, ou via 1.1.1.1 là où notre serveur ne peut pas se connecter.La délégationLa racine, le registre, puis la réponse propre de chaque serveur, comme un résolveur la parcourt.
Un NS Lookup de github.com : le verdict, les huit serveurs de noms du registre à côté de la liste propre à la zone, la réponse de chaque serveur et la délégation depuis le registre .com. Sélectionnez un numéro pour voir ce que montre chaque partie.

Serveurs de noms du parent et de l'enfant : pourquoi ils diffèrent

Deux parties différentes tiennent les deux listes. Le registre publie la liste du parent quand votre registrar le lui demande ; votre hébergeur DNS sert la liste propre à la zone. Changez l'une sans l'autre et elles s'écartent.

Les résolveurs font plus confiance à la réponse propre de la zone qu'au renvoi (RFC 2181 §5.4.1) : une fois qu'ils ont interrogé la zone, ils gardent sa liste et son TTL. Le 2026-10-23, le résolveur de Cloudflare détenait l'ensemble NS de google.com avec 340 859 s restantes : plus que les 172 800 de .com, la copie venait donc du TTL de 4 jours de la zone.

Un nom présent seulement dans la liste du registre reçoit encore du trafic des résolveurs qui repartent de zéro. Un nom présent seulement dans la zone leur est invisible. Les deux méritent d'être corrigés ; aucun n'est une panne à lui seul.

La liste du registre à côté de celle de la zonerelevé le 2026-10-23
xserver.ne.jp5 contre 3

Registre .jp1 j

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp
  • ns4.xserver.jpregistre seulement
  • ns5.xserver.jpregistre seulement

Zone1 h

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp

ns4.xserver.jp et ns5.xserver.jp ne sont qu'au registre. Les deux répondent en faisant autorité : rien ne casse, mais les listes diffèrent quand même.

github.comles mêmes 8

Registre .com2 j

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Zone15 min · 1 h

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Mêmes noms, horloges différentes : la copie du registre dure 2 jours, celle de Route 53 15 minutes, celle de NS1 1 heure.

Un domaine .net(nom non communiqué)aucun nom en commun

Registre .net2 j

  • ns1.domaindirect.comregistre seulement
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comregistre seulement

Zone15 min

  • ns1.hover.comzone seulement
  • ns2.hover.comzone seulement

Le registre liste encore les anciens noms. Deux d'entre eux partagent des adresses avec les serveurs de Hover et répondent ; le troisième refuse.

Les lignes relient les noms que les deux listes partagent ; une ligne en pointillés relie deux noms sur une même adresse. Le troisième cas est un enregistrement réel trouvé lors d'un balayage aléatoire ; son nom n'est pas communiqué.

Que sont les enregistrements glue ?

La glue est une adresse que le parent fournit avec son renvoi, pour qu'un résolveur puisse joindre un serveur de noms dont le nom se trouve dans la zone qu'il sert. Sans elle, trouver ns1.google.com reviendrait à interroger les serveurs de google.com, soit la question dont vous êtes parti (RFC 1034 §4.2.1).

La RFC 9471 en fait une règle : un renvoi DOIT porter la glue de chaque serveur du domaine (ns1.google.com pour google.com), et DEVRAIT la porter pour les serveurs voisins placés sous le même parent (ns-421.awsdns-52.com pour github.com). Un nom sans lien comme ns-520.awsdns-01.net est recherché séparément.

La glue se définit chez le registrar, sous forme d'enregistrements d'hôte, de serveurs de noms enfants ou de serveurs DNS personnels. Quand un serveur déménage, la glue doit suivre : une glue périmée envoie les résolveurs vers une adresse qui ne répond plus.

La glue, et quand elle est nécessairerelevé au .com, 2026-10-23

Dans le domaine · google.com

  1. .com : demandez ns1.google.com
  2. Son adresse vit dans google.com lui-même
  3. sans glue, la recherche boucle
  4. .com ajoute donc ns1.google.com A 216.239.32.10 · DOIT : obligatoire

Voisin et sans lien · github.com

  1. .com : demandez ns-421.awsdns-52.com, ns-520.awsdns-01.net, …
  2. awsdns-52.com est aussi sous .com : glue 205.251.193.165 · DEVRAIT : incluse
  3. awsdns-01.net est ailleurs : le résolveur le cherche dans .net · pas de glue
Glue périmée · en direct64.69.208.141glue de .com pour ns1.register.com · aucune réponse, interrogée deux fois162.214.41.25son enregistrement A aujourd'hui · répond en faisant autorité
L'objet d'hôte ns1.register.com au .com, lu via rdap.verisign.com le 2026-10-23 : le registre détient encore une adresse que le serveur a quittée, et la fournit comme glue.

Qu'est-ce qu'une délégation lame, et comment la corriger

Une délégation est lame quand le parent envoie les résolveurs vers un serveur qui ne sert pas la zone : il refuse, ne dit rien, ou répond sans faire autorité. Si tous les serveurs listés sont lames, le domaine cesse de se résoudre ; si un seul sur plusieurs l'est, les recherches ralentissent le temps que les résolveurs réessaient.

La RFC 9499 note que « délégation lame » en est venue à couvrir plusieurs défauts : l'outil nomme donc chacun d'eux : refuse la zone (REFUSED), aucune réponse (interrogé deux fois), répond sans faire autorité (pas de aa), erreur du serveur (SERVFAIL). Un silence en TCP seul n'est pas appelé lame tant que Google et Cloudflare résolvent le domaine : il s'appelle pas de réponse TCP, car ce serveur peut répondre en UDP.

La correction se trouve toujours d'un des deux côtés : ajouter la zone chez l'hébergeur DNS vers lequel le registre pointe, ou faire pointer le registre vers l'hébergeur qui a la zone. Les résolveurs peuvent se souvenir de l'échec jusqu'à 5 minutes après la correction (RFC 9520).

Trois serveurs lames, relevés2026-10-23 · domaines non communiqués

Refuse la zone

ns63 · ns64.domaincontrol.com

Les deux serveurs de GoDaddy nommés par .com répondent REFUSED : la zone n'y est pas configurée.

bash
$ dig @ns63.domaincontrol.com \
    example.com SOA +norec
;; … status: REFUSED
;; flags: qr; … ANSWER: 0

Un délai dépassé, puis REFUSED

ns1 · ns2.eftydns.com

Un serveur a dépassé le délai une fois, puis a répondu REFUSED quand on l'a interrogé de nouveau. Un seul délai dépassé n'est pas un verdict : l'outil interroge de nouveau avant de nommer un état.

bash
$ dig @ns1.eftydns.com \
    example.com SOA +norec
;; connection timed out
# interrogé de nouveau
;; … status: REFUSED

Un sur trois

ns1 · ns2 · ns3.domaindirect.com

Deux serveurs répondent en faisant autorité ; le troisième refuse. Le domaine fonctionne, plus lentement.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. Voir où pointe le registreLa vue Délégation liste les serveurs du registre et la réponse de chacun.
  2. Corriger un côtéAjoutez la zone chez cet hébergeur, ou changez les serveurs de noms chez le registrar.
  3. Vérifier de nouveauLes réponses reviennent aussitôt ; un échec en cache dure jusqu'à 5 minutes.

Ce que reçoivent les visiteurs quand tous les serveurs sont lames :Google SERVFAILCloudflare SERVFAIL

Relevé sur des enregistrements trouvés lors d'un balayage aléatoire ; leurs noms ne sont pas communiqués et apparaissent sous la forme example.com et example.net.

De combien de serveurs de noms avez-vous besoin ?

D'au moins deux : « The DNS specification and domain name registration rules require at least two servers for every zone » (RFC 2182 §5, BCP 16). La même section en recommande trois pour la plupart des organisations, dont un bien éloigné des autres, et quatre ou cinq là où la fiabilité compte davantage.

Comptez les réseaux, pas les noms. Les serveurs doivent se trouver là où une seule panne ne peut pas tous les atteindre (RFC 2182 §3.1) : six serveurs dans un même /22 partagent le même sort de routage. L'anycast répartit une adresse sur de nombreux sites et c'est la réponse habituelle, mais cela reste un seul opérateur ; un second fournisseur survit à la panne de ce dernier (RFC 8901).

Plus n'est pas un problème. La limite de sept de l'ancienne RFC 1912 venait des réponses UDP de 512 octets ; les grandes zones en font tourner huit aujourd'hui (github.com, bbc.co.uk).

Les serveurs, regroupés par réseaurelevé le 2026-10-23
DomaineServeurs par réseauNSRéseauxLecture
google.comGoogle · AS15169 · anycast41Anycast, un seul opérateur
github.comNS1 · AS62597Route 53 · AS16509 · anycast82Deux fournisseurs
bbc.co.ukNetActuate · AS63911NS1 · AS6259782Deux réseaux
xserver.ne.jpXserver · AS131965Amazon · AS1650952Deux réseaux
craigslist.orgcraigslist · AS2241461Un seul /22

« Il est recommandé de fournir trois serveurs pour la plupart des zones au niveau d'une organisation, dont au moins un doit être bien éloigné des autres. »

RFC 2182 §5 · BCP 16, juillet 1997 · deux requis, trois recommandés
Une case est un réseau (AS) ; une case teintée est un fournisseur anycast : de nombreux sites, un seul opérateur. Le second réseau de xserver.ne.jp est ns2.xserver.jp, chez Amazon ; les six serveurs de craigslist.org partagent un seul /22.

Comment changer les serveurs de noms, et combien de temps cela prend

Changez-les là où le domaine est enregistré, pas chez l'hébergeur DNS : le registrar envoie la nouvelle liste au registre, et le registre la publie. Ajoutez d'abord la zone chez le nouvel hébergeur, avec tous ses enregistrements, pour que les nouveaux serveurs répondent dès qu'ils sont nommés.

Deux horloges tournent ensuite. Les résolveurs qui ont mis en cache le renvoi du registre gardent l'ancienne liste jusqu'au TTL du parent : 2 jours pour .com, 1 jour pour .de et .jp, 1 heure pour .org. Les résolveurs qui ont déjà interrogé la zone gardent l'ancien ensemble NS propre à la zone pendant son TTL, qui peut être plus long : celui de google.com est de 4 jours. Google Public DNS garde les NS 6 heures au plus.

Ce n'est donc jamais un « 24 à 48 heures » fixe. Laissez l'ancien hébergeur DNS répondre les mêmes enregistrements jusqu'à la fin de la plus longue horloge, et sur un domaine signé, retirez le DS avant le déménagement (RFC 6781).

Où les changer, et les horlogesTTL mesurés le 2026-10-23

Chez le registrar : le guide de chacun

Combien de temps dure la copie du registre (TTL NS du parent)

  • .ru4 jours345 600 s
  • .com2 jours172 800 s
  • .uk2 jours172 800 s
  • .de1 jour86 400 s
  • .jp1 jour86 400 s
  • .tr12 heures43 200 s
  • .dev3 heures10 800 s
  • .org1 heure3 600 s
  • .io1 heure3 600 s
  • .fr1 heure3 600 s
  • .in15 minutes900 s

Les horloges après un changement

  • Ancien renvoi dans les cachesle TTL du parent.com : jusqu'à 2 jours
  • Ancien ensemble NS de la zone dans les cachesle TTL de l'ancienne zonegoogle.com : jusqu'à 4 jours
  • Google Public DNSson plafond pour les NS6 heures au plus
TTL des parents relevés sur les serveurs propres de chaque registre (dig +norec) ; .io a répondu 3 600 s, pas les 300 s souvent cités. Les registrars annoncent encore des durées fixes : GoDaddy « up to 48 hours », Namecheap « up to 24 hours ».

Enregistrements NS, SOA et glue

Trois enregistrements se rencontrent à une délégation. NS nomme les serveurs : la copie du parent indique le chemin, celle de la zone fait autorité. La glue est un enregistrement A ou AAAA que le parent ne garde que pour les serveurs nommés dans la zone. Le SOA existe une fois par zone, à son sommet : le serveur primaire, une adresse de contact, le numéro de série et les minuteurs.

Un serveur qui répond au SOA avec le flag aa détient la zone, et c'est pourquoi l'outil le demande à chaque serveur. Le numéro de série indique si les serveurs ont la même version ; Route 53 commence à 1 et ne le change jamais de lui-même, et une zone chez deux fournisseurs porte deux numéros de série, ce qui est normal dans les deux cas.

Deux zones, une coupuregoogle.com · relevé le 2026-10-23

La zone .comgérée par Verisign

  • NSgoogle.com. 172800 NS ns1.google.com.Délégation : où aller ensuite · ne fait pas autorité
  • Ans1.google.com. 172800 A 216.239.32.10Glue : l'adresse du serveur, pour qu'on puisse le joindre
  • DSpas de DS : google.com n'est pas signéDS : pointe vers la clé de signature de l'enfant ; zones signées seulement (cloudflare.com DS 2371 13 2)

coupure de zone · google.com

La zone google.comgérée par Google

  • NSgoogle.com. 345600 NS ns1.google.com.La liste propre à la zone · fait autorité
  • SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60Un par zone : primaire, contact, numéro de série, minuteurs
  • Ans1.google.com. 345600 A 216.239.32.10L'adresse propre du serveur : la glue devrait y correspondre
La glue et l'enregistrement A propre au serveur sont deux copies d'un même fait ; quand elles divergent, la glue est périmée.

NS Lookup et la commande nslookup

On cherche « ns lookup » pour deux raisons : les serveurs de noms d'un domaine, et la commande nslookup livrée avec Windows, macOS et Linux. nslookup interroge votre résolveur et affiche ce qu'il a en cache ; avec -type=ns, il liste l'ensemble NS de la zone tel que votre résolveur le détient.

Cette copie peut avoir plusieurs heures, et elle ne montre jamais la liste du registre, la glue, ni si chaque serveur détient la zone. Cette page interroge directement chacun de ceux qu'elle peut joindre.

Trois façons de rechercher des serveurs de noms
Ce NS Lookupdnsrobot.netnslookup-type=nsdigNS · +norec
Interrogele registre, puis chaque serveurvotre résolveurn'importe quel serveur que vous nommez
Registre et zoneles deux, nom par nomla copie en cacheune liste par commande
Le aa de chaque serveurchaque adresse IPv4 (A et glue)Nonun serveur par commande
Glue et TTLles deux TTLavec -debugdans la sortie
Diagnosticnommé, avec la correctionNonNon
Fonctionne surn'importe quel navigateurWindowsmacOSLinuxmacOSLinux

NS Lookup : questions fréquentes

Qu'est-ce qu'un NS Lookup ?

Un NS Lookup demande au DNS quels serveurs de noms détiennent la zone d'un domaine. Cet outil interroge d'abord le registre, pour la liste du parent avec sa glue et son TTL, puis les adresses IPv4 de chaque serveur de noms directement en TCP pour le SOA de la zone et son propre ensemble NS, et compare les deux. Vous voyez qui héberge le DNS, quels serveurs font autorité, et ce qui ferait échouer les résolveurs.

Comment savoir qui est mon fournisseur DNS ?

Regardez les noms des serveurs de noms : ns1.google.com est Google, *.ns.cloudflare.com est Cloudflare, ns-*.awsdns-* est Amazon Route 53, 01.dnsv.jp est Onamae.com. Cette recherche nomme l'hébergeur DNS d'après le modèle de noms documenté de chaque fournisseur et montre séparément le réseau derrière chaque adresse, car certains hébergeurs tournent sur le réseau d'une autre société : Porkbun et Hostinger sur celui de Cloudflare, Vercel sur celui de NS1.

Pourquoi le registre et la zone listent-ils des serveurs de noms différents ?

La liste du registre, définie chez votre registrar, et les enregistrements NS propres à la zone, définis chez votre hébergeur DNS, sont deux copies distinctes, et la RFC 1034 dit qu'elles devraient être exactement identiques. Elles s'écartent quand quelqu'un change l'une sans l'autre, souvent après un changement d'hébergeur DNS. Les résolveurs qui partent du registre utilisent sa liste, ceux qui ont interrogé la zone gardent la sienne.

Qu'est-ce qu'une délégation lame ?

Une délégation lame est un serveur de noms que le registre liste mais qui ne sert pas la zone : il répond REFUSED ou SERVFAIL, répond sans faire autorité, ou ne répond pas du tout. Si tous les serveurs listés sont lames, le domaine cesse de se résoudre et Google et Cloudflare répondent SERVFAIL. Corrigez-la en ajoutant la zone chez cet hébergeur DNS, ou en changeant les serveurs de noms chez le registrar.

Combien de temps la propagation d'un changement de serveurs de noms prend-elle ?

Jusqu'à la plus longue de deux horloges : le TTL NS du registre (2 jours pour .com et .net, 4 jours pour .ru, 1 jour pour .de et .jp, 1 heure pour .org et .io, 15 minutes pour .in) et le TTL NS propre à l'ancienne zone, que gardent les résolveurs qui ont déjà interrogé l'ancien hébergeur. Google Public DNS le plafonne à environ 6 heures. Un « 24 à 48 heures » fixe est faux dans les deux sens.

Combien de serveurs de noms un domaine doit-il avoir ?

Au moins deux : la RFC 2182 en exige deux, en recommande trois pour la plupart des organisations dont un bien éloigné des autres, et quatre ou cinq pour une fiabilité accrue. Plus que le nombre, ce qui compte est qu'une seule panne ne puisse pas tous les atteindre : des réseaux ou des fournisseurs différents. Les serveurs anycast gérés par un seul opérateur, comme Cloudflare ou Route 53, sont de nombreux sites, mais toujours un seul opérateur.

Que sont les enregistrements glue, et quand en ai-je besoin ?

La glue est l'adresse que le registre fournit avec son renvoi pour un serveur de noms nommé dans la zone, comme ns1.example.com pour example.com : sans elle, un résolveur aurait besoin de l'adresse du serveur pour trouver le serveur. La RFC 9471 rend la glue obligatoire pour de tels noms du domaine. Définissez-la chez votre registrar, où elle s'appelle enregistrements d'hôte, serveurs de noms enfants ou serveurs DNS personnels.

Pourquoi des outils différents montrent-ils des serveurs de noms différents ?

La plupart des vérificateurs de serveurs de noms interrogent un résolveur, qui montre une copie en cache pouvant avoir plusieurs jours après un changement, alors que le registre et la zone répondent pour eux-mêmes. Certains outils ne montrent que la liste propre à la zone. Cette recherche montre la liste du registre, la réponse propre de chaque serveur, et les copies en cache de Google et de Cloudflare côte à côte, avec le temps qu'il reste à chaque copie.

Que signifie « non sondé directement » ?

Notre serveur tourne sur le réseau de Cloudflare, et un Cloudflare Worker ne peut pas ouvrir de connexion vers une adresse de ce réseau. Les serveurs de noms qui s'y trouvent, ceux de Cloudflare et ceux des hébergeurs qui tournent dessus comme Porkbun, Hostinger et DigitalOcean, sont lus à la place via le résolveur 1.1.1.1 de Cloudflare : l'ensemble NS et son TTL, mais ni le bit AA, ni le numéro de série, ni le temps de chaque serveur.

Un NS Lookup est-il la même chose que nslookup ?

Non. nslookup est un outil en ligne de commande sur Windows, macOS et Linux qui demande à un résolveur n'importe quel type d'enregistrement, NS compris (nslookup -type=ns example.com). Un NS Lookup est la question elle-même : quels serveurs de noms servent un domaine. Comme dig NS, nslookup montre la copie en cache de votre résolveur ; interroger le registre et chaque serveur directement, comme le fait cet outil, montre s'ils concordent.

Pourquoi mon changement de serveurs de noms n'apparaît-il pas encore ?

Vérifiez trois endroits : si le registre liste les nouveaux serveurs (sinon, le changement n'a pas encore quitté votre registrar), si la nouvelle zone répond en faisant autorité, et combien de temps durent les anciennes copies dans les résolveurs. Le mode « J'ai changé mes serveurs de noms » prend vos nouveaux serveurs, compare chaque copie avec eux et décompte jusqu'au moment où tous les résolveurs les ont.

Dois-je retirer DNSSEC avant de changer de serveurs de noms ?

Oui, sauf si l'ancien et le nouvel hébergeur DNS coopèrent. Si le registre garde un enregistrement DS que les clés du nouvel hébergeur ne vérifient pas, les résolveurs qui valident, comme Google et Cloudflare, répondent SERVFAIL et le domaine devient injoignable pour leurs utilisateurs. Retirez le DS chez le registrar, attendez son TTL, changez les serveurs de noms, puis publiez le DS du nouvel hébergeur.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Outils DNS associés