Enregistrements NS (Name Server) et santé de vos serveurs de noms

1. NS records from your NameServers

Ce test liste les enregistrements NS renvoyés directement par vos serveurs de noms autoritaires pour votre domaine. Il montre comment vos propres serveurs décrivent la délégation.

Pourquoi c’est important

L’ensemble d’enregistrements NS publié par vos serveurs de noms doit être complet et cohérent. Si un serveur manque, est mal orthographié ou annonce une liste NS différente des autres, les résolveurs peuvent échouer de façon aléatoire ou conserver des données obsolètes en cache.

Comment DNSprobe teste ce point

DNSprobe envoie des requêtes NS directement à chacun de vos serveurs de noms autoritaires et collecte les enregistrements NS qu’ils renvoient. Il normalise les noms d’hôtes, compare les ensembles et signale toute divergence.

Problèmes fréquents

• Un serveur de noms renvoie une liste NS différente de celle des autres.
• Certains noms d’hôtes NS sont mal orthographiés ou utilisent un autre domaine.
• L’ensemble NS est incomplet par rapport à ce qui est enregistré dans la zone parente.

Bonnes pratiques

• S’assurer que tous les serveurs autoritaires renvoient exactement le même ensemble NS.
• Utiliser des noms d’hôtes stables et explicites pour les serveurs de noms et éviter les fautes de frappe.
• Vérifier soigneusement les changements d’NS et surveiller les dérives entre serveurs.

2. Public Resolver

Cette section simule la façon dont les grands résolveurs publics voient vos enregistrements NS. Elle interroge des services comme Cloudflare DNS, Google Public DNS, Quad9 et d’autres résolveurs majeurs.

Pourquoi c’est important

Les utilisateurs finaux ne parlent presque jamais directement à vos serveurs de noms autoritaires. Ils s’appuient sur des résolveurs récursifs opérés par les FAI, des fournisseurs DNS publics ou des réseaux d’entreprise. Si ces résolveurs mettent en cache des données incohérentes, votre domaine peut se comporter différemment selon les utilisateurs.

Comment DNSprobe teste ce point

DNSprobe envoie des requêtes NS à plusieurs résolveurs publics répartis dans le monde et compare leurs réponses à vos données autoritaires. Il met en évidence les différences d’ensembles NS, les enregistrements manquants ou les résolveurs lents.

Problèmes fréquents

• Certains résolveurs voient encore d’anciens enregistrements NS après une migration.
• Un résolveur ne peut pas joindre l’un de vos serveurs de noms et se rabat sur les autres.
• Des résolveurs différents rapportent des TTL différents ou des ensembles NS partiellement divergents.

Bonnes pratiques

• Planifier les changements d’NS avec un délai suffisant et des TTL réduits avant la bascule.
• Surveiller les résolveurs publics après les migrations pour confirmer une propagation cohérente.
• Utiliser au moins deux fournisseurs ou clusters DNS indépendants lorsque c’est possible.

3. Recursive Queries

Ce test vérifie si vos serveurs de noms autoritaires acceptent les requêtes récursives depuis Internet.

Pourquoi c’est important

Les serveurs autoritaires ne devraient normalement pas effectuer de récursivité pour des clients arbitraires. La récursivité ouverte peut être exploitée pour des attaques par réflexion/amplification et peut divulguer des modèles de requêtes internes.

Comment DNSprobe teste ce point

DNSprobe envoie à vos serveurs de noms des requêtes pour des domaines sans lien avec le vôtre et observe s’ils tentent de les résoudre de manière récursive. Le comportement est ensuite classé entre récursivité autorisée ou correctement désactivée.

Problèmes fréquents

• Les serveurs de noms autoritaires sont configurés comme résolveurs ouverts pour n’importe quelle adresse IP sur Internet.
• La récursivité est par erreur autorisée depuis certains réseaux à cause d’ACL mal configurées.
• Des environnements split-brain laissent fuiter la récursivité interne vers l’interface publique.

Bonnes pratiques

• Désactiver la récursivité sur tous les serveurs de noms autoritaires exposés au public.
• Limiter toute récursivité nécessaire à des résolveurs internes derrière des pare-feu.
• Retester régulièrement après les mises à jour logicielles ou changements de configuration.

4. Same Glue

Ce test compare les enregistrements de glue dans la zone parente avec les enregistrements A et AAAA renvoyés par vos propres serveurs de noms.

Pourquoi c’est important

Les enregistrements de glue fournissent les adresses IP des serveurs de noms in-bailiwick pour casser les dépendances circulaires. Si la glue diffère des adresses réelles, les résolveurs peuvent envoyer leurs requêtes au mauvais serveur ou ne pas réussir à vous joindre.

Comment DNSprobe teste ce point

DNSprobe récupère les données de glue depuis la zone parente puis résout directement les noms d’hôtes NS sur vos serveurs de noms autoritaires. Il compare les IP et signale les divergences ou la glue manquante.

Problèmes fréquents

• La glue parent pointe toujours vers d’anciennes IP après une migration.
• La glue IPv6 est absente alors que le serveur de noms publie des enregistrements AAAA.
• La glue existe pour certains serveurs mais pas pour d’autres dans le même domaine.

Bonnes pratiques

• Mettre à jour la glue immédiatement chaque fois qu’une IP de serveur de noms change.
• Maintenir la cohérence entre glue IPv4/IPv6 et enregistrements A/AAAA autoritaires.
• Éviter la glue inutile pour les serveurs de noms hors du domaine (out-of-bailiwick).

5. NS Self-IP Consistency

Ce test vérifie que les serveurs de noms annoncent bien les mêmes adresses IP que celles utilisées par la zone parente et les résolveurs publics.

Pourquoi c’est important

Si un serveur de noms renvoie un enregistrement A ou AAAA qui ne correspond pas à son adresse réellement joignable, les résolveurs peuvent mettre en cache de mauvaises données et envoyer leurs requêtes vers une adresse morte.

Comment DNSprobe teste ce point

DNSprobe interroge chaque serveur de noms pour son propre nom d’hôte et compare les IP renvoyées avec celles visibles au niveau parent et via des résolveurs externes. Les différences sont mises en évidence.

Problèmes fréquents

• Le serveur de noms renvoie une IP obsolète pour son propre nom d’hôte.
• Des adresses différentes sont renvoyées selon le serveur que l’on interroge.
• Des adresses internes fuitent dans les réponses DNS publiques.

Bonnes pratiques

• S’assurer que chaque serveur de noms publie un unique ensemble A/AAAA correct pour son nom d’hôte.
• Éviter de mélanger adresses internes et externes dans la même vue de zone.
• Vérifier la cohérence Self-IP après les changements réseau ou de load balancer.

6. Glue for NS records

Ce test se concentre spécifiquement sur la présence et la validité des enregistrements de glue nécessaires pour les serveurs de noms in-bailiwick.

Pourquoi c’est important

Sans glue correcte, les résolveurs peuvent avoir besoin de requêtes supplémentaires pour découvrir l’IP de vos serveurs de noms, ou dans certains cas échouer complètement lorsqu’il existe une dépendance circulaire.

Comment DNSprobe teste ce point

DNSprobe inspecte la zone parente à la recherche d’entrées de glue, vérifie leurs TTL et les compare aux données A/AAAA autoritaires publiées par vos serveurs de noms.

Problèmes fréquents

• Glue totalement absente pour des serveurs de noms in-bailiwick.
• Glue présente mais pointant vers une infrastructure obsolète.
• TTLs incohérents entraînant une convergence lente après les changements.

Bonnes pratiques

• Utiliser la glue uniquement lorsqu’elle est techniquement nécessaire (NS in-bailiwick).
• Documenter les procédures de mise à jour de glue chez le registraire et le fournisseur DNS.
• Vérifier la glue après tout changement côté registraire ou transfert de domaine.

7. Mismatched NS records

Ce test détecte les différences entre l’ensemble NS annoncé par la zone parente et celui renvoyé par vos serveurs de noms autoritaires.

Pourquoi c’est important

La résolution d’un domaine commence toujours par la zone parente. Si la zone parente et la zone enfant ne sont pas d’accord sur les serveurs de noms autoritaires, certains résolveurs peuvent ne jamais contacter tous vos serveurs.

Comment DNSprobe teste ce point

DNSprobe collecte la liste NS depuis la zone parente et depuis vos serveurs de noms, puis compare les noms d’hôtes un par un, en mettant en évidence les entrées manquantes, supplémentaires ou divergentes.

Problèmes fréquents

• La zone parente liste des serveurs de noms qui n’apparaissent plus dans la zone enfant.
• La zone enfant annonce des NS supplémentaires que la zone parente ne connaît pas.
• Des fautes de frappe ou différences de casse aboutissent à des noms d’hôtes distincts.

Bonnes pratiques

• Maintenir des listes NS strictement alignées entre zone parente et enfant.
• Lors de l’ajout ou suppression d’un serveur de noms, mettre à jour à la fois le registraire et la zone.
• Relancer DNSprobe après les changements pour confirmer qu’il n’y a plus de divergence.

8. DNS servers responded

Ce test vérifie simplement que chaque serveur de noms configuré répond bien aux requêtes dans un délai raisonnable.

Pourquoi c’est important

Un serveur de noms qui ne répond pas mais qui figure toujours dans les enregistrements NS peut provoquer des timeouts aléatoires, car certains résolveurs vont d’abord le tenter avant de basculer vers les autres.

Comment DNSprobe teste ce point

DNSprobe envoie des requêtes à chaque serveur de noms, mesure la latence et les codes de réponse. Les serveurs qui ne répondent pas ou renvoient des erreurs sont signalés.

Problèmes fréquents

• Un serveur mis hors service figure toujours dans les enregistrements NS.
• Des pare-feu ou limitations de débit bloquent les requêtes depuis certains réseaux.
• Des erreurs d’Anycast ou de load balancing provoquent des défaillances intermittentes.

Bonnes pratiques

• Retirer rapidement des enregistrements NS tout serveur de noms hors service.
• Surveiller la disponibilité et la latence DNS depuis plusieurs régions.
• Utiliser des sondes de santé lorsque vous exploitez du DNS anycast ou réparti.

9. Name of nameservers are valid

Ce test vérifie que les noms d’hôtes des serveurs de noms respectent les règles DNS et pointent vers des adresses valides et routables.

Pourquoi c’est important

Des noms d’hôtes invalides ou des enregistrements pointant vers des IP privées ou réservées peuvent casser la résolution ou divulguer des informations sur votre réseau interne.

Comment DNSprobe teste ce point

DNSprobe vérifie la syntaxe des noms d’hôtes NS, puis les résout et s’assure que les IP sont publiques et correctement formatées.

Problèmes fréquents

• Des noms d’hôtes utilisant des caractères ou labels invalides.
• Des serveurs de noms pointant vers des adresses privées ou RFC1918.
• Des serveurs de noms hébergés sous des domaines qui n’existent plus.

Bonnes pratiques

• Utiliser des noms d’hôtes entièrement qualifiés et bien structurés sous des domaines stables.
• Éviter de publier des schémas d’adressage internes dans le DNS public.
• Revalider périodiquement les noms d’hôtes NS après des changements d’infrastructure.

10. Multiple Nameservers

Ce test compte le nombre de serveurs de noms distincts configurés pour votre domaine et évalue leur diversité.

Pourquoi c’est important

N’utiliser qu’un seul serveur de noms crée un point de défaillance unique. Disposer d’au moins deux serveurs, idéalement plus, améliore la résilience face aux pannes, à la maintenance et aux problèmes de routage.

Comment DNSprobe teste ce point

DNSprobe compte les noms d’hôtes NS et IP uniques, puis avertit si vous n’en avez qu’un seul ou si tous les serveurs sont en pratique la même machine.

Problèmes fréquents

• Un seul serveur de noms autoritaire configuré.
• Plusieurs noms d’hôtes NS pointant vers le même serveur physique.
• Tous les serveurs de noms hébergés dans le même centre de données ou la même baie.

Bonnes pratiques

• Utiliser au moins deux serveurs de noms indépendants pour chaque domaine.
• Les répartir sur différents réseaux et emplacements géographiques.
• Envisager un fournisseur DNS secondaire pour une redondance supplémentaire.

11. Nameservers are lame

Ce test détecte les délégations bancales (lame), où un serveur de noms listé ne sert pas de données autoritaires pour votre domaine.

Pourquoi c’est important

Un serveur de noms lame augmente la latence et le taux d’échec, car les résolveurs vont l’interroger, ne rien obtenir d’utile, puis seulement ensuite essayer un autre serveur.

Comment DNSprobe teste ce point

DNSprobe interroge chaque serveur de noms pour les enregistrements SOA et NS de votre domaine et vérifie qu’il répond de manière autoritaire avec les bonnes données.

Problèmes fréquents

• Délégation laissée en place après le déplacement de la zone chez un nouveau fournisseur.
• Serveur secondaire mal configuré ou jamais correctement ajouté comme esclave.
• Listes de contrôle d’accès bloquant les réponses autoritaires pour certains clients.

Bonnes pratiques

• S’assurer que chaque NS listé héberge la zone et répond de façon autoritaire.
• Retirer les anciens fournisseurs de l’ensemble NS une fois la migration terminée.
• Surveiller les délégations bancales après les changements de registraire ou de fournisseur.

12. Missing nameservers reported by parent

Ce test met en évidence les serveurs de noms présents dans votre zone enfant mais non enregistrés dans la zone parente.

Pourquoi c’est important

Les résolveurs commencent toujours par la zone parente. Si certains serveurs de noms ne sont connus que de la zone enfant, beaucoup de résolveurs ne les utiliseront jamais, ce qui réduit la redondance.

Comment DNSprobe teste ce point

DNSprobe compare la liste NS de la zone parente avec celle renvoyée par vos serveurs de noms autoritaires et liste les serveurs présents uniquement dans la zone enfant.

Problèmes fréquents

• Nouveau serveur de noms ajouté dans la zone mais pas chez le registraire.
• Serveur d’essai temporaire laissé uniquement dans la zone enfant.
• Limites imposées par le registraire empêchant l’enregistrement de tous les NS.

Bonnes pratiques

• Maintenir en permanence des listes NS alignées entre zone parente et enfant.
• Mettre à jour le registraire chaque fois que vous ajoutez ou retirez un serveur de noms.
• Éviter d’utiliser des NS non enregistrés pour du trafic de production.

13. Missing nameservers reported by your nameservers

Ce test détecte les serveurs de noms listés dans la zone parente mais absents de la zone enfant.

Pourquoi c’est important

Si la zone parente référence des serveurs de noms qui ne se déclarent pas autoritaires dans la zone, les résolveurs peuvent voir des informations contradictoires et rencontrer des timeouts.

Comment DNSprobe teste ce point

DNSprobe compare la liste NS de la zone parente avec les enregistrements NS renvoyés par vos serveurs autoritaires et met en évidence les serveurs présents uniquement au niveau parent.

Problèmes fréquents

• Anciens fournisseurs encore listés chez le registraire après une migration.
• Faute de frappe dans la zone enfant entraînant des noms d’hôtes différents.
• Nettoyage incomplet laissant des NS fantômes au niveau parent.

Bonnes pratiques

• Retirer les serveurs de noms obsolètes à la fois de la zone parente et de la zone enfant.
• Vérifier les ensembles NS après toute opération côté registraire.
• Automatiser la configuration autant que possible pour réduire les erreurs manuelles.

14. Domain CNAMEs

Ce test signale si l’apex de la zone ou d’autres labels critiques sont configurés en CNAME, ce qui peut provoquer des problèmes d’interopérabilité.

Pourquoi c’est important

Utiliser un CNAME à l’apex de la zone entre en conflit avec d’autres types d’enregistrements comme NS, SOA ou MX et peut casser DNSSEC, la livraison de courriels ou certains résolveurs DNS.

Comment DNSprobe teste ce point

DNSprobe inspecte la zone à la recherche d’enregistrements CNAME à l’apex et sur d’autres labels sensibles, puis signale toute configuration susceptible de contrevenir aux standards.

Problèmes fréquents

• Apex de zone configuré en CNAME au lieu de A/AAAA.
• CNAME utilisé en même temps que d’autres types d’enregistrements sur le même label.
• Chaînes de CNAME qui augmentent la latence et le risque de panne.

Bonnes pratiques

• Éviter les CNAME à l’apex de la zone; utiliser ALIAS/ANAME là où c’est pris en charge.
• Ne pas mélanger CNAME et autres types d’enregistrements sur le même nom.
• Garder les chaînes de CNAME courtes et bien surveillées.

15. NSs CNAME check

Ce test vérifie que les noms d’hôtes des serveurs de noms ne sont pas eux-mêmes des enregistrements CNAME.

Pourquoi c’est important

Les RFC recommandent que les noms d’hôtes NS pointent directement vers des enregistrements A/AAAA. Utiliser des CNAME pour les NS peut perturber les résolveurs, augmenter la latence et casser certaines implémentations DNS.

Comment DNSprobe teste ce point

DNSprobe interroge chaque nom d’hôte NS et vérifie qu’il se résout directement en enregistrements A/AAAA sans passer par des redirections CNAME.

Problèmes fréquents

• Enregistrements NS pointant vers des noms d’hôtes qui sont des CNAME.
• Chaînes de CNAME complexes devant les serveurs de noms.
• Utilisation de CNAME de type CDN comme noms d’hôtes NS.

Bonnes pratiques

• Faire pointer les noms d’hôtes NS directement vers des enregistrements A/AAAA.
• Garder l’adressage derrière les serveurs de noms stable et prévisible.
• Éviter de masquer vos NS derrière plusieurs niveaux de CNAME.

16. Different subnets

Ce test analyse si vos serveurs de noms sont répartis sur différents préfixes réseau.

Pourquoi c’est important

Si tous les serveurs de noms se trouvent dans le même sous-réseau, un simple incident de routage, une attaque DDoS ou une opération de maintenance sur ce segment peut les faire tomber tous en même temps.

Comment DNSprobe teste ce point

DNSprobe regroupe les IP des serveurs de noms par sous-réseau et signale les cas où tout est concentré dans un seul préfixe.

Problèmes fréquents

• Tous les serveurs de noms utilisant le même réseau /24 ou /64.
• Serveur secondaire configuré mais hébergé dans le même rack ou VLAN.
• Anycast annoncé depuis un seul site physique.

Bonnes pratiques

• Répartir les serveurs de noms sur différents sous-réseaux et segments réseau.
• Envisager un hébergement multi-sites ou multi-fournisseurs pour le DNS.
• N’utiliser l’Anycast que si vous pouvez l’appuyer sur plusieurs emplacements réels.

17. IPs of nameservers are public

Ce test confirme que les adresses IP des serveurs de noms sont publiquement joignables et ne font pas partie de plages privées ou réservées.

Pourquoi c’est important

Publier des IP privées ou non routables dans les enregistrements NS rendra votre domaine inaccessible depuis Internet et peut exposer des schémas d’adressage internes.

Comment DNSprobe teste ce point

DNSprobe compare chaque IP aux plages privées, réservées et d’usage spécial connues et avertit lorsqu’une adresse de serveur de noms n’est pas globalement routable.

Problèmes fréquents

• Enregistrements NS pointant vers des IP RFC1918 ou des adresses link-local.
• Publication accidentelle d’adresses internes de supervision ou de gestion.
• NAT mal configuré rendant les IP externes injoignables.

Bonnes pratiques

• Utiliser uniquement des adresses IP globalement routables pour les serveurs de noms publics.
• Séparer les interfaces de gestion des points d’entrée DNS publics.
• Revoir les IP NS après une refonte réseau ou un changement de fournisseur.

18. DNS servers allow TCP connection

Ce test vérifie si vos serveurs de noms acceptent le DNS sur TCP en plus de l’UDP.

Pourquoi c’est important

Le DNS sur TCP est nécessaire pour les réponses volumineuses, les transferts de zone et une validation DNSSEC fiable. Bloquer le TCP peut provoquer des pannes intermittentes ou des erreurs de validation.

Comment DNSprobe teste ce point

DNSprobe tente d’ouvrir des connexions TCP vers chaque serveur de noms sur le port 53 et d’y envoyer des requêtes de test, en enregistrant si la connexion et les réponses aboutissent.

Problèmes fréquents

• Pare-feu bloquant TCP/53 tout en autorisant UDP/53.
• Équipements intermédiaires ou protections DDoS bloquant le trafic DNS sur TCP.
• Logiciel de serveur de noms mal configuré pour n’écouter que sur l’UDP.

Bonnes pratiques

• S’assurer que tous les serveurs autoritaires écoutent à la fois en UDP et en TCP pour le DNS.
• Tester la connectivité TCP depuis l’extérieur de votre propre réseau.
• Lors de l’activation de DNSSEC, vérifier que le TCP fonctionne de manière fiable depuis plusieurs FAI.

19. Different autonomous systems

Ce test vérifie si vos serveurs de noms sont hébergés dans différents systèmes autonomes (AS), et pas seulement sur des IP distinctes.

Pourquoi c’est important

Héberger tous les serveurs DNS dans un seul AS les rend vulnérables aux incidents de routage ou aux problèmes de peering affectant ce fournisseur. Les répartir sur plusieurs AS augmente la résilience.

Comment DNSprobe teste ce point

DNSprobe recherche l’ASN de chaque IP de serveur de noms et les regroupe. Il avertit lorsque tous les serveurs se trouvent dans le même AS ou dans des réseaux étroitement liés.

Problèmes fréquents

• Tous les serveurs de noms hébergés par un seul FAI dans un même AS.
• Serveurs redondants en apparence, mais derrière le même fournisseur de transit.
• Anycast déployé uniquement à l’intérieur de l’infrastructure d’un fournisseur.

Bonnes pratiques

• Héberger les serveurs de noms dans au moins deux systèmes autonomes distincts.
• Combiner du DNS sur site (on-premise) avec un fournisseur DNS secondaire ou cloud.
• Prendre en compte les exigences de continuité d’activité lors du choix d’hébergement DNS.

20. Stealth NS records sent

Ce test analyse les serveurs de noms dits « stealth », qui servent la zone sans être listés dans la zone parente.

Pourquoi c’est important

Les serveurs de noms stealth peuvent être utiles comme maîtres cachés ou pour la supervision interne, mais mal utilisés ils créent de la confusion et une visibilité partielle de votre infrastructure DNS.

Comment DNSprobe teste ce point

DNSprobe compare la liste des serveurs répondant réellement de façon autoritaire pour votre zone avec l’ensemble NS visible au niveau parent et signale tout serveur caché supplémentaire.

Problèmes fréquents

• Trafic de production arrivant involontairement sur des serveurs stealth via des résolveurs personnalisés.
• Maîtres cachés exposés à Internet sans durcissement suffisant.
• Exploitants oubliant que les serveurs stealth doivent eux aussi être maintenus et synchronisés.

Bonnes pratiques

• Utiliser les serveurs stealth de manière volontaire, pour des raisons opérationnelles claires.
• Durcir et surveiller les maîtres cachés aussi soigneusement que les serveurs NS publics.
• Documenter le rôle des serveurs stealth pour éviter les surprises en cas d’incident.

21. Tester la délégation des NS manuellement depuis votre propre terminal

La section NS de DNSprobe compare ce que vos propres serveurs de noms publient avec ce que voient la zone parente et les résolveurs publics, y compris les IP de glue, la cohérence des ensembles de NS et la joignabilité de base. Vous pouvez reproduire la plupart de ces vérifications depuis un terminal en interrogeant les enregistrements NS via votre résolveur, les résolveurs publics et les serveurs du TLD.

Linux : utiliser dig (outils BIND)

Sur la plupart des distributions Linux, la commande dig est fournie par le paquet d’outils BIND. Les exemples ci-dessous montrent comment voir les enregistrements NS renvoyés par votre résolveur actuel, les comparer avec les principaux résolveurs publics, puis interroger un serveur de TLD et enfin vérifier les enregistrements A (glue) de chaque serveur de noms :

                dig example.com NS +noall +answer
    
                # Enregistrements NS pour example.com tels que vus par votre résolveur récursif actuel    
                dig example.com NS @8.8.8.8 +noall +answer
                dig example.com NS @1.1.1.1 +noall +answer
    
                # Comparer avec les principaux résolveurs publics (Google DNS, Cloudflare, etc.) pour détecter des problèmes de cache ou de visibilité    
                dig example.com NS @g.gtld-servers.net +norecurse +noall +authority +additional
    
                # Interroger directement un serveur de TLD pour voir la délégation parente et la glue, puis résoudre chaque nom de NS vers son adresse IP    
                dig ns1.example.com A +noall +answer
                dig ns2.example.com A +noall +answer
        

macOS : utiliser dig avec les outils intégrés

macOS inclut dig dans ses outils en ligne de commande. Ouvrez Terminal et exécutez les mêmes commandes que sous Linux pour vérifier quels enregistrements NS sont visibles pour votre résolveur, pour les résolveurs publics et pour les serveurs de TLD, puis résoudre chaque serveur de noms vers son adresse IP :

                dig example.com NS +noall +answer
    
                # Enregistrements NS pour example.com tels que vus par votre résolveur récursif actuel    
                dig example.com NS @8.8.8.8 +noall +answer
                dig example.com NS @1.1.1.1 +noall +answer
    
                # Comparer avec les principaux résolveurs publics (Google DNS, Cloudflare, etc.) pour détecter des problèmes de cache ou de visibilité    
                dig example.com NS @g.gtld-servers.net +norecurse +noall +authority +additional
    
                # Interroger directement un serveur de TLD pour voir la délégation parente et la glue, puis résoudre chaque nom de NS vers son adresse IP    
                dig ns1.example.com A +noall +answer
                dig ns2.example.com A +noall +answer
        

Windows : utiliser nslookup

Sous Windows, l’outil historique nslookup permet d’interroger les enregistrements NS et A via différents résolveurs. Depuis une fenêtre Invite de commandes ou PowerShell, vous pouvez d’abord voir la réponse de votre résolveur par défaut, puis interroger des résolveurs publics et un serveur de TLD, et enfin résoudre chaque nom de serveur de noms pour confirmer son adresse IP :

                nslookup -type=NS example.com
    
                REM Enregistrements NS pour example.com tels que vus par votre résolveur par défaut    
                nslookup -type=NS example.com 8.8.8.8
                nslookup -type=NS example.com 1.1.1.1
    
                REM Comparer avec les principaux résolveurs publics (Google DNS, Cloudflare, etc.) en spécifiant l’IP du résolveur    
                nslookup -type=NS example.com g.gtld-servers.net
    
                REM Interroger directement un serveur de TLD pour la délégation NS, puis résoudre chaque nom de NS afin de vérifier son enregistrement A de glue    
                nslookup -type=A ns1.example.com
                nslookup -type=A ns2.example.com
        

Important : n’interrogez que les enregistrements DNS de domaines que vous possédez ou que vous êtes autorisé à analyser. Des requêtes automatisées répétées vers des domaines tiers ou des serveurs de TLD sans autorisation peuvent être considérées comme du trafic abusif par certains fournisseurs.