Vérifications DNS Parent : ce que voit réellement le registre TLD

1. Domain NS records (liste autoritaire des serveurs de noms)

Cette sous-section compare les enregistrements NS publiés dans votre zone (les NS autoritaires à l’intérieur de votre domaine) avec la liste de serveurs de noms que la zone parente possède pour votre domaine. Dans une configuration idéale, les deux listes devraient correspondre exactement, ou ne différer que pour des raisons contrôlées d’Anycast ou d’équilibrage de charge.

Pourquoi les Domain NS records sont importants

Votre domaine repose sur ses serveurs de noms pour publier tous les autres enregistrements DNS : A, AAAA, MX, TXT, CNAME, SRV, etc. Si la zone parente délègue votre domaine vers de mauvais serveurs de noms, les résolveurs interrogeront les mauvais serveurs pour vos données. Même si votre fichier de zone est parfait chez votre vrai fournisseur DNS, les utilisateurs verront des résultats incohérents ou complètement erronés, car ils questionnent d’autres serveurs.

Comment DNSprobe vérifie les Domain NS records

DNSprobe commence par interroger directement votre domaine sur vos serveurs de noms pour récupérer les enregistrements NS, puis interroge séparément le registre TLD pour obtenir les enregistrements NS de délégation stockés au niveau parent. L’outil compare ensuite les deux listes, normalise les noms d’hôtes et met en évidence les écarts, comme des NS manquants, des NS présents uniquement d’un côté ou des différences de TTL pouvant indiquer des problèmes de propagation.

Erreurs courantes liées aux Domain NS records

• La zone parente pointe encore vers un ancien fournisseur DNS alors que le propriétaire a déjà migré la zone vers un nouveau fournisseur sans mettre à jour la configuration chez le registraire.
• Le fichier de zone contient des NS supplémentaires pour des tests ou une migration, mais la zone parente n’a pas été mise à jour, créant un décalage où certains résolveurs reçoivent des données partielles ou obsolètes.
• Des fautes de frappe dans les noms d’hôtes des serveurs de noms (par exemple ns11.exemple.com au lieu de ns1) qui passent inaperçues localement mais provoquent des échecs de délégation silencieux sur Internet.

Bonnes pratiques pour les Domain NS records

• Gardez toujours synchronisées la liste de NS chez votre registraire et la liste de NS dans votre fichier de zone. Toute modification d’un côté doit être répliquée de l’autre le plus rapidement possible.
• Utilisez au minimum deux serveurs de noms indépendants, idéalement hébergés sur des réseaux ou des emplacements distincts, et évitez de mélanger des NS de test ou temporaires avec les enregistrements de production.
• Après tout changement de fournisseur de serveurs de noms, exécutez systématiquement une analyse DNS complète avec DNSprobe pour confirmer que la zone parente et votre zone autoritaire sont d’accord sur les enregistrements NS.

2. TLD Parent Check

Le TLD Parent Check vérifie ce que votre registre de domaine de premier niveau publie réellement pour votre domaine au niveau parent. Cela inclut la liste des serveurs de noms délégués et, le cas échéant, les glue records associés. C’est la vue "officielle" de votre domaine dans la hiérarchie DNS globale.

Pourquoi le TLD Parent Check est important

Les résolveurs commencent généralement au niveau du TLD lorsqu’ils recherchent votre domaine. Si le registre TLD possède des données périmées — par exemple d’anciens serveurs de noms, des glue records manquants ou des entrées partiellement supprimées — votre domaine peut fonctionner dans certaines régions et échouer dans d’autres. C’est très fréquent après des migrations ou des changements de registraire mal finalisés.

Comment DNSprobe réalise le TLD Parent Check

DNSprobe envoie des requêtes NS directes aux serveurs de noms officiels de votre TLD. Ces requêtes sont sans récursion et ne demandent que des informations autoritaires. La réponse est analysée pour extraire les serveurs de noms délégués et les éventuels glue records, puis le tout est comparé à ce que votre propre zone publie. Cela permet de voir immédiatement si le registre a un retard ou une vision différente de votre configuration réelle.

Problèmes typiques détectés par le TLD Parent Check

• Des changements de registraire démarrés mais jamais terminés, laissant le registre TLD pointer vers un mélange d’anciens et de nouveaux serveurs de noms.
• Des domaines transférés entre registraires où le nouveau registraire a importé la zone, mais n’a pas mis à jour correctement la délégation au niveau du registre.
• Des modifications manuelles dans le panneau du registraire qui suppriment un serveur de noms mais laissent d’autres références, créant une délégation incohérente entre les serveurs du TLD.

Bonnes pratiques au niveau TLD Parent

• Après un changement de fournisseur DNS ou un transfert de domaine entre registraires, vérifiez toujours les données parentes avec un outil comme DNSprobe au lieu de vous fier uniquement à l’interface du registraire.
• Évitez les changements fréquents et inutiles de noms de serveurs. Plus vous modifiez la délégation, plus le risque d’erreur de saisie ou de mise à jour partielle au registre augmente.
• Si votre activité est sensible aux interruptions, planifiez les migrations DNS pendant les périodes de faible trafic et contrôlez le TLD Parent Check avant, pendant et après la modification.

3. Your nameservers are listed

Cette sous-section vérifie que tous les serveurs de noms qui doivent répondre pour votre domaine sont correctement listés au niveau parent, et qu’il n’existe pas de référence vers des serveurs qui n’hébergent plus votre zone.

Pourquoi il est essentiel que vos serveurs de noms soient correctement listés

Si l’un de vos serveurs de noms n’est pas listé au niveau parent, certains résolveurs ne l’interrogeront jamais, même s’il contient la version la plus à jour de votre zone. À l’inverse, si la zone parente référence encore un serveur que vous avez désactivé, les résolveurs qui tombent dessus recevront des réponses SERVFAIL ou des données complètement erronées.

Comment DNSprobe vérifie que vos serveurs de noms sont listés

DNSprobe recoupe les enregistrements NS déclarés dans votre zone avec les enregistrements NS présents au niveau parent. Tout serveur de noms qui n’existe que dans un seul de ces deux endroits est signalé. L’outil recherche également les doublons, alias et noms d’hôtes incohérents pouvant indiquer une infrastructure partiellement supprimée.

Erreurs fréquentes liées aux serveurs de noms listés

• Laisser un serveur de noms historique listé chez le registraire après une migration, ce qui fait qu’une partie du trafic continue de viser une ancienne zone ou un serveur vide.
• Ajouter un serveur de noms temporaire pour du dépannage et oublier de le retirer ensuite de la zone parente.
• Mélanger des serveurs de noms internes et externes (par exemple une IP privée 10.x ou un nom de laboratoire ajoutés par erreur dans la délégation publique).

Bonnes pratiques pour les serveurs de noms listés

• Tenez un inventaire clair des serveurs de noms autoritaires pour chaque domaine et mettez à jour la zone et le registraire de manière synchronisée.
• Décommissionnez les serveurs de noms de manière contrôlée : retirez-les d’abord de la zone parente, attendez l’expiration des TTL, surveillez le trafic, puis éteignez-les.
• Révisez régulièrement votre délégation avec DNSprobe pour garder une liste de serveurs de noms propre, minimale et alignée sur votre infrastructure actuelle.

4. DNS Parent sent Glue (glue records pour les serveurs de noms in-bailiwick)

Les glue records sont des enregistrements A ou AAAA stockés au niveau parent pour casser les dépendances circulaires lorsque vos serveurs de noms sont situés dans le même domaine qu’ils desservent (in-bailiwick). Par exemple, si exemple.com utilise ns1.exemple.com comme serveur de noms, le registre doit aussi publier l’IP de ns1.exemple.com comme glue.

Pourquoi les glue records sont critiques

Sans glue records corrects, les résolveurs ne peuvent pas rejoindre vos serveurs de noms de manière fiable. Ils devraient d’abord résoudre ns1.exemple.com, qui lui-même dépend de la résolution de exemple.com. Les glue records éliminent ce problème de "poule et œuf" en fournissant aux résolveurs une IP fonctionnelle pour vos serveurs de noms au niveau parent, avant même que votre zone ne soit chargée.

Comment DNSprobe vérifie les glue records

DNSprobe interroge le registre TLD pour votre délégation et inspecte la section additionnelle de la réponse DNS pour y trouver les glue records. Nous comparons ensuite les adresses IP publiées en glue avec les enregistrements A/AAAA présents dans votre zone autoritaire. Toute différence est signalée, car cela signifie que certains résolveurs peuvent utiliser des IP obsolètes ou incorrectes pour vos serveurs de noms.

Problèmes typiques liés aux glue records

• Changer l’IP d’un serveur de noms uniquement dans le fichier de zone, sans mettre à jour le glue correspondant chez le registraire, ce qui laisse les résolveurs pointer vers l’ancienne adresse.
• Ne publier que du glue en IPv4 alors que votre zone et vos résolveurs attendent aussi de l’IPv6, ou l’inverse, créant une joignabilité asymétrique.
• Retirer un serveur de noms de la zone sans supprimer son glue record au niveau parent, ce qui génère du trafic inutile ou trompeur.

Bonnes pratiques pour la gestion des glue records

• Chaque fois que vous modifiez l’adresse IP d’un serveur de noms in-bailiwick, mettez à jour les glue records chez votre registraire en même temps que les enregistrements A/AAAA dans votre zone.
• Hébergez vos serveurs de noms sur une infrastructure stable, avec des IP pérennes, pour éviter les mises à jour de glue fréquentes et les fenêtres de propagation.
• Utilisez régulièrement DNSprobe pour vous assurer que le test "DNS Parent sent Glue" est entièrement vert et que les glue records parent correspondent toujours aux IP réelles de vos serveurs de noms.

5. Nameservers A records (adresses IP de vos NS)

Cette sous-section se concentre sur les enregistrements A et AAAA des serveurs de noms eux-mêmes. Même si la délégation et les glue records sont corrects, des adresses IP erronées ou instables sur les noms de serveurs provoquent des délais d’attente, une latence élevée ou des échecs de résolution intermittents.

Pourquoi les Nameservers A records sont importants

Les serveurs de noms sont la fondation de votre DNS. Si leurs adresses IP changent sans coordination, s’ils se trouvent derrière du matériel surchargé ou s’ils pointent vers des serveurs de test, chaque requête DNS pour votre domaine en subira les conséquences. Surveiller les enregistrements A/AAAA de vos noms de serveurs permet de détecter des erreurs de configuration invisibles au niveau du fichier de zone.

Comment DNSprobe analyse les Nameservers A records

DNSprobe résout chaque nom de serveur de noms listé pour votre domaine et recueille tous les enregistrements A et AAAA associés. L’outil détecte les adresses internes ou privées, les configurations instables (comme des NS pointant vers des IP d’hébergement web qui changent fréquemment) et les incohérences entre ce que la zone parente et votre zone autoritaire annoncent.

Problèmes fréquents avec les Nameservers A records

• Des noms de serveurs pointant vers des adresses privées ou RFC1918, ce qui les rend injoignables depuis Internet.
• Des enregistrements A qui suivent des changements d’hébergement web au lieu d’être liés à une infrastructure DNS dédiée, provoquant des coupures DNS non planifiées lors des migrations de sites.
• Des adresses IP temporaires utilisées pour des tests et jamais remplacées par des IP finales de production.

Bonnes pratiques pour les Nameservers A records

• Hébergez vos serveurs de noms sur une infrastructure stable et supervisée, avec des IP bien définies qui changent rarement et ne sont pas réutilisées pour des services sans lien.
• Évitez de faire pointer vos noms de serveurs vers des frontaux équilibrés ou des IP de CDN, sauf si vous contrôlez entièrement le comportement DNS de ces points d’entrée.
• Documentez les adresses IP attendues pour chaque serveur de noms et auditez-les régulièrement avec DNSprobe pour détecter les changements inattendus.

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

La section Parent de DNSprobe compare ce que le registre (zone parente, par exemple .com ou .ca) publie pour vos serveurs de noms avec ce que votre propre zone renvoie, y compris les enregistrements de glue et les adresses IP. Vous pouvez reproduire ces vérifications depuis un terminal en interrogeant vos enregistrements NS via votre résolveur et directement auprès des 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 affichent d’abord les enregistrements NS vus par votre résolveur récursif, suivent ensuite toute la chaîne de délégation depuis la racine, puis interrogent un serveur de TLD spécifique pour voir la délégation parente et les enregistrements de glue :

                dig example.com NS +noall +answer
    
                # Interroger les enregistrements NS de example.com tels que vus par votre résolveur récursif actuel    
                dig example.com NS +trace
    
                # Suivre la chaîne de délégation depuis la racine jusqu’à example.com pour voir chaque étape    
                dig example.com NS @g.gtld-servers.net +norecurse +noall +authority +additional
        

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 comparer la réponse de votre résolveur, visualiser la trace de délégation et voir ce qu’un serveur de TLD publie pour votre domaine :

                dig example.com NS +noall +answer
    
                # Interroger les enregistrements NS de example.com tels que vus par votre résolveur récursif actuel    
                dig example.com NS +trace
    
                # Suivre la chaîne de délégation depuis la racine jusqu’à example.com pour voir chaque étape    
                dig example.com NS @g.gtld-servers.net +norecurse +noall +authority +additional
        

Windows : utiliser nslookup

Sous Windows, l’outil historique nslookup permet d’interroger les enregistrements NS, aussi bien via votre résolveur habituel qu’en ciblant un serveur de noms précis. Exécutez les commandes suivantes depuis l’Invite de commandes ou PowerShell pour voir vos enregistrements NS, puis demander à un serveur de TLD spécifique ce qu’il publie pour votre domaine :

                nslookup -type=NS example.com
    
                REM Deuxième commande : interroger explicitement le serveur de TLD g.gtld-servers.net pour connaître la délégation NS de example.com    
                nslookup -type=NS example.com g.gtld-servers.net
        

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.