Aller au contenu principal

Recherche enregistrement SOA (Start of Authority)

Analysez les métadonnées et la synchronisation de votre zone DNS

Problème de synchronisation DNS ? Vérifiez l'enregistrement SOA pour comprendre les paramètres de votre zone et diagnostiquer les problèmes de réplication.

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

Métadonnées de zone

Consultez le serveur primaire, le contact administratif et le numéro de série qui identifie la version de votre zone.

Multi-résolveur

Comparez les réponses de Google, Cloudflare et Quad9 pour détecter les problèmes de propagation du serial.

Paramètres de synchro

Analysez les valeurs refresh, retry et expire qui contrôlent la synchronisation entre serveurs primaire et secondaires.

TTL et cache négatif

Vérifiez le minimum TTL qui définit la durée de cache des réponses négatives (NXDOMAIN).

Gratuit et illimité

Testez autant de domaines que nécessaire. Aucune inscription requise.

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.

Qu'est-ce qu'un enregistrement SOA ?

Un enregistrement SOA (Start of Authority) définit l'autorité d'une zone DNS. Il contient les informations essentielles sur la zone : serveur primaire, contact administratif, numéro de série et paramètres de synchronisation.

Structure d'un enregistrement SOA :

ChampDescriptionExemple
MNAMEServeur DNS primairens1.provider.com.
RNAMEContact administratif (email)hostmaster.captaindns.com.
SerialNuméro de version de la zone2025012801
RefreshIntervalle de vérification (sec)7200
RetryDélai après échec (sec)900
ExpireAbandon de zone (sec)1209600
MinimumCache négatif (sec)3600

Exemple d'enregistrement SOA

captaindns.com.  3600  IN  SOA  ns1.provider.com. hostmaster.captaindns.com. (
    2025012801  ; Serial
    7200        ; Refresh (2 heures)
    900         ; Retry (15 minutes)
    1209600     ; Expire (14 jours)
    3600        ; Minimum TTL (1 heure)
)

Explication du contact RNAME

Le contact s'écrit comme un nom DNS : hostmaster.captaindns.com. correspond à l'email hostmaster@captaindns.com. Le premier point remplace l'arobase.


Valeurs recommandées

ParamètreValeur recommandéeExplication
Refresh3600-7200Vérification toutes les 1-2 heures
Retry600-900Réessai après 10-15 minutes
Expire604800-1209600Abandon après 1-2 semaines
Minimum300-3600Cache négatif de 5 min à 1 heure

Format du serial

Le format AAAAMMJJNN est recommandé :

  • 2025012801 = 28 janvier 2025, modification n°1
  • 2025012802 = 28 janvier 2025, modification n°2

Règles importantes

Unicité du SOA

RègleExplication
Un seul SOAToujours à l'apex de la zone
Avec les NSSOA et NS coexistent à l'apex
Pas de CNAMEL'apex ne peut pas être un CNAME

Bonnes pratiques

PratiquePourquoi
Incrémenter le serialObligatoire à chaque modification
Contact validePour recevoir les notifications
Expire suffisantÉvite la perte de zone chez les secondaires

Problèmes courants

Serial non incrémenté

Les secondaires ne se mettent pas à jour car le serial n'a pas changé.

  1. Incrémentez le serial dans la zone
  2. Rechargez la zone sur le primaire
  3. Vérifiez la propagation

Synchronisation échouée

Un serveur secondaire affiche un serial ancien.

  1. Vérifiez l'accès réseau entre primaire et secondaire
  2. Contrôlez les autorisations de transfert de zone
  3. Attendez un cycle de refresh

Zone abandonnée par un secondaire

Le secondaire a dépassé le délai d'expiration.

  1. Vérifiez que le primaire est accessible
  2. Augmentez la valeur expire si nécessaire
  3. Forcez un transfert de zone

Vérification en ligne de commande

Linux/Mac

dig SOA captaindns.com

Comparer les serials sur différents serveurs :

dig SOA captaindns.com @ns1.provider.com +short
dig SOA captaindns.com @ns2.provider.com +short

Windows

nslookup -type=soa captaindns.com

Outils complémentaires

OutilUtilité
Recherche NSVérifier les serveurs autoritaires
Recherche AVérifier l'IP du serveur primaire
Propagation DNSVérifier la propagation mondiale

Ressources utiles