Propagation & diagnostics

Comparez plusieurs résolveurs et analysez les réponses servies.

Recherche enregistrement NS

En mode trace itérative, le résolveur est ignoré.
Interroge plusieurs résolveurs publics pour comparer les réponses.

Comment bien utiliser les différentes options du moteur de recherche DNS ?

Qu'est-ce que la trace itérative ?

La trace exécute la résolution pas à pas. Le résolveur interroge d'abord les serveurs de la racine, puis ceux du TLD (.com, .fr, .eu), puis les serveurs autoritaires de la zone cible. À chaque étape, la page affiche le serveur interrogé, la réponse, le RCODE et la latence.

  1. 1. Racine

    Découverte des serveurs du TLD pour le nom demandé.

  2. 2. TLD

    Référence vers les NS de la zone (délégation).

  3. 3. Autoritaires

    Réponse finale (ou erreur) avec TTL et latence.

À quoi ça sert ?

  • Comparer les réponses selon les résolveurs et les régions
  • Détecter un cache chaud, un TTL trop long ou une délégation incomplète
  • Expliquer une différence de latence ou un RCODE inattendu

Astuce : gardez la trace désactivée pour les vérifications rapides ; activez-la quand vous enquêtez ou préparez un ticket/post-mortem.

Qu'est-ce que la trace classique ?

La trace classique interroge uniquement le résolveur sélectionné (UDP ou DoH) et restitue la réponse telle qu'elle est perçue depuis ce point du réseau. Vous obtenez le RCODE, les sections de réponse et la latence du trajet client → résolveur.

  1. 1. Résolveur choisi

    Utilise le preset ou la configuration personnalisée pour lancer la requête exactement comme votre service.

  2. 2. Protocole conservé

    Respecte le transport sélectionné (UDP, TCP ou DoH) afin de reproduire le comportement réel.

  3. 3. Réponse détaillée

    Affiche les sections question, answer, authority/additional quand elles existent, avec TTL et métadonnées utiles.

Pourquoi l'utiliser ?

  • Vérifier la vision d'un résolveur spécifique avant de suspecter la délégation
  • Confirmer les valeurs en cache et l'impact d'un TTL ou d'un flush
  • Documenter une résolution telle qu'un client ou un microservice la voit

Astuce : laissez l'option de trace itérative désactivée quand vous auditez un résolveur donné ; activez-la ensuite pour comparer avec le parcours root → TLD → autoritaire.

Comment fonctionne le test de propagation ?

Le test interroge en parallèle un ensemble de résolveurs publics (Google, Cloudflare, Quad9, OpenDNS, FAI…) et groupe les réponses par contenu et RCODE. Vous visualisez instantanément qui a déjà pris en compte la mise à jour.

  1. 1. Résolveurs multipoints

    Active les presets de propagation pour interroger plusieurs acteurs répartis dans le monde.

  2. 2. Comparaison automatique

    Regroupe les réponses identiques et signale les divergences ou les erreurs propres à un résolveur.

  3. 3. Synthèse exploitable

    Fournit un résumé clair, la liste des résolveurs, leurs latences et l'état de chaque groupe.

Quand l'utiliser ?

  • Suivre la diffusion d'un changement DNS à l'échelle mondiale
  • Identifier les caches encore anciens et décider d'un flush ciblé
  • Partager un état de propagation dans un ticket ou un post-mortem

Astuce : pendant le test de propagation, la sélection de résolveur est figée. Désactivez le mode pour revenir au diagnostic unitaire.

Informations complémentaires sur les enregistrements DNS de type NS

Un NS record indique quels serveurs sont autoritaires pour une zone DNS. Il liste les noms des serveurs qui détiennent la zone. Les résolveurs interrogent ces serveurs pour obtenir les autres enregistrements.
Un NS record contient un nom un type une cible NS et un TTL. Le TTL indique combien de temps la réponse reste en cache dans le résolveur local.

Exemple enregistrement DNS de type NS

NomTypeServeur NSTTL en secondes
@NSns1.exemple.net.3600

Dans cet exemple le nom @ vise l apex de la zone. La cible est un nom d hôte. Ce nom doit publier des enregistrements A ou AAAA et être joignable.

Exemple avec plusieurs serveurs

Une zone doit publier plusieurs NS records. Cela apporte de la redondance et une meilleure disponibilité.

NomTypeServeur NSTTL en secondes
@NSns1.exemple.net.3600
@NSns2.exemple.net.3600

Prévoir deux serveurs ou plus. Ils doivent répondre de manière cohérente.

Délégation d'un sous domaine

Pour déléguer sous.exemple.com ajouter des NS sur ce nom dans la zone parente. Chaque cible doit résoudre en A ou AAAA. Si le nom du serveur est à l'intérieur du sous domaine la zone parente peut publier des adresses d'assistance que l'on appelle glue. L'objectif reste simple. Permettre aux résolveurs d'atteindre rapidement les serveurs du sous domaine.

TTL expliqué en clair

Un TTL court rend un changement de serveurs plus visible. Utile en phase de bascule.
Un TTL moyen ou long réduit les requêtes vers les serveurs autoritaires. Adapté à une zone stable.
Réduire le TTL quelques heures avant un changement puis le remonter après validation.

Bon à savoir
NS et SOA se publient à l'apex d'une zone. Un CNAME ne doit pas apparaître sur un nom qui porte des NS. Une cible NS est toujours un nom pas une adresse.

Où utiliser un NS record

À l'apex de la zone pour désigner les serveurs autoritaires de cette zone.
Sur un sous domaine quand on délègue ce sous domaine vers des serveurs dédiés.
Les zones filles possèdent leur propre SOA et leurs propres NS.

À éviter
Pointer un enregistrement NS vers une adresse directe.
Publier un seul NS sur une zone.
Laisser une cible NS sans A ni AAAA.
Avoir des ensembles de NS différents entre la zone parente et la zone fille sans raison.

Vérifier en ligne

Un DNS lookup en ligne permet d'entrer un nom de domaine. Le résultat affiche la liste des serveurs NS et le TTL visible depuis Internet. C'est un premier contrôle utile. Faire ensuite un test local depuis sa machine.

Vérifier sous Windows

Windows fournit nslookup. On peut l'utiliser en mode interactif.

Résolveur local
nslookup
set q=ns
exemple.com
Résolveur précis
nslookup
set q=ns
server 1.1.1.1
exemple.com

La première partie interroge selon la configuration réseau de la machine. La seconde force l'usage d'un résolveur tiers ici celui de Cloudflare.

Vérifier sous Linux et sous Mac

Sur ces systèmes la commande dig est pratique et facile à utiliser.

Résolveur local
dig NS exemple.com
Résolveur précis
dig NS exemple.com @1.1.1.1

Lecture rapide des réponses

Plusieurs lignes NS indiquent plusieurs serveurs. Chercher des noms variés et des réseaux différents pour une meilleure résilience.
Un TTL restant élevé peut expliquer un décalage après un changement.
Un écart entre les NS vus depuis la zone parente et ceux vus dans la zone elle-même révèle un manque de synchronisation.

Procédure de migration simple

  1. Préparer les nouveaux serveurs et leurs enregistrements A ou AAAA.
  2. Réduire le TTL des NS à 300 voire 60 secondes quelques heures avant la bascule.
  3. Mettre à jour la zone avec la nouvelle liste NS.
  4. Mettre à jour la délégation côté registre si nécessaire.
  5. Vérifier depuis plusieurs réseaux puis remonter le TTL quand tout est stable.

Astuce pratique
Conserver une fiche avec la liste des NS publiés côté zone et côté registre. Noter la date le TTL et la raison du changement. Cette trace évite les écarts lors des mises à jour.

Cas fréquents

Changement de prestataire DNS

Publier les nouveaux NS dans la zone. Mettre à jour la délégation chez le bureau d'enregistrement. Vérifier la cohérence.

Délégation d'un sous domaine à une équipe

Ajouter des NS sur le sous domaine dans la zone parente. L'équipe gère ensuite sa zone fille avec son propre SOA.

Ajout d'un serveur supplémentaire

Ajouter un NS de plus. Vérifier qu il résout en A ou AAAA et qu il sert la zone à jour.

Dépannage rapide

  1. Si la zone répond parfois avec d anciens enregistrements vérifier la cohérence des NS publiés.
  2. Si un serveur NS ne répond pas retirer temporairement son entrée le temps de la réparation.
  3. Si la délégation ne fonctionne pas vérifier la présence d adresses glue quand elles sont nécessaires.
  4. Si la réponse reste ancienne malgré la mise à jour attendre l expiration du TTL et purger le cache du résolveur local si possible.

En résumé, un enregistrement NS désigne les serveurs autoritaires d'une zone. Il doit pointer vers des noms joignables et cohérents. Une zone publie plusieurs NS pour la disponibilité. Le TTL bien réglé facilite les transitions. La vérification passe par un outil en ligne puis par nslookup et par dig.
Avec ces repères la gestion reste claire. Les changements se déroulent sans stress. Les résolveurs trouvent la zone sans incident.