Enregistrement SOA (Start Of Authority) et état des minuteries de zone

1. Enregistrement SOA

Ce bloc affiche l’enregistrement SOA exact retourné par vos serveurs de noms : serveur principal (MNAME), adresse courriel du hostmaster, numéro de série et minuteries.

Pourquoi c’est important

Le SOA est l’« en-tête » autoritaire de votre zone. S’il pointe vers le mauvais serveur principal, utilise une adresse hostmaster invalide ou expose des minuteries aberrantes, cela révèle souvent une configuration DNS plus largement problématique.

Comment DNSprobe vérifie ce point

DNSprobe demande le SOA à chaque serveur autoritaire au niveau de l’apex de la zone et affiche la version qui paraît cohérente entre eux, en mettant en évidence les champs principaux pour faciliter la comparaison avec votre configuration.

Problèmes courants détectés

• SOA manquant ou enregistrements SOA différents selon le serveur interrogé.
• Serveur principal (MNAME) ou adresse hostmaster invalide ou pointant vers un hôte inexistant.
• Valeurs de minuteries manifestement incorrectes (par exemple EXPIRE très faible ou TTL négatif à zéro).

Bonnes pratiques

• Conserver un seul enregistrement SOA à l’apex de la zone et s’assurer que tous les serveurs autoritaires servent les mêmes données.
• Utiliser une adresse hostmaster valide et surveillée qui aboutit à une vraie boîte de courriel ou à un système de tickets.
• Relire le SOA à chaque changement DNS pour confirmer que le serveur principal et les minuteries correspondent toujours à vos politiques d’exploitation.

2. Les NS ont le même numéro de série SOA

Ce test vérifie que tous les serveurs de noms autoritaires retournent le même numéro de série SOA pour votre zone.

Pourquoi c’est important

Le numéro de série SOA indique aux serveurs secondaires qu’une mise à jour de la zone est disponible. Si les numéros de série diffèrent, vos données ne sont pas synchronisées et les clients peuvent obtenir des réponses différentes selon le serveur qu’ils consultent.

Comment DNSprobe vérifie ce point

DNSprobe interroge le SOA sur chaque serveur de noms et compare uniquement le champ de numéro de série. Si tous les numéros de série sont identiques, la zone semble synchronisée; sinon, le rapport affiche un avertissement avec les valeurs divergentes.

Problèmes courants détectés

• Certains serveurs de noms servent encore un ancien numéro de série après une mise à jour.
• Serveur principal caché ou paramètres de transfert mal configurés empêchant les secondaires de recevoir les nouvelles versions de zone.
• Modifications manuelles sur des serveurs secondaires qui cassent le flux normal de transfert de zone.

Bonnes pratiques

• Utiliser des transferts de zone automatiques (AXFR/IXFR ou API) à partir d’un seul primaire plutôt que d’éditer plusieurs serveurs à la main.
• Surveiller que les secondaires se rafraîchissent dans un délai raisonnable après l’augmentation du numéro de série sur le primaire.
• Éviter les serveurs secondaires peu utilisés ou obsolètes qui se mettent rarement à jour mais sont toujours publiés dans les enregistrements NS.

3. Champ MNAME du SOA

Le champ MNAME du SOA indique le serveur de noms principal de la zone, celui que les secondaires doivent contacter pour les transferts de zone.

Pourquoi c’est important

Si MNAME pointe vers un hôte non autoritaire, injoignable ou absent des NS publics, les serveurs secondaires peuvent ne pas se rafraîchir correctement et le diagnostic devient plus complexe.

Comment DNSprobe vérifie ce point

DNSprobe examine la valeur MNAME du SOA et vérifie si ce nom d’hôte apparaît également dans vos enregistrements NS et répond de manière autoritaire pour la zone.

Problèmes courants détectés

• MNAME défini sur un hôte qui n’apparaît pas dans les enregistrements NS publics.
• L’hôte MNAME ne répond pas de manière autoritaire pour la zone ou est injoignable.
• Valeurs historiques ou de test laissées dans MNAME après une migration vers un nouveau fournisseur DNS.

Bonnes pratiques

• Définir MNAME sur votre véritable serveur principal ou sur le fournisseur DNS qui gère le contenu de la zone.
• Garder MNAME cohérent avec vos enregistrements NS pour simplifier le dépannage.
• Mettre à jour MNAME lors de tout déplacement de la zone vers une nouvelle plateforme principale.

4. Numéro de série SOA

Ce test se concentre sur le numéro de série numérique de votre SOA, souvent au format basé sur la date, par exemple YYYYMMDDnn.

Pourquoi c’est important

Chaque fois que vous modifiez la zone, le numéro de série doit augmenter. S’il ne change pas, les serveurs secondaires et les caches peuvent ne jamais remarquer la mise à jour et continuer à servir des données périmées.

Comment DNSprobe vérifie ce point

DNSprobe lit le numéro de série SOA et, lorsque c’est pertinent, indique s’il ressemble à une valeur basée sur la date et s’il se situe dans une plage réaliste.

Problèmes courants détectés

• Numéro de série qui n’augmente pas après des modifications de zone, empêchant les secondaires de se rafraîchir.
• Numéro de série réinitialisé à une valeur inférieure, ce qui perturbe les serveurs secondaires et peut bloquer les transferts.
• Formats de numéro de série non standard qui rendent difficile l’identification de la dernière modification.

Bonnes pratiques

• Utiliser un numéro de série strictement croissant; un schéma basé sur la date (YYYYMMDDnn) est facile à suivre.
• S’assurer que vos outils DNS incrémentent automatiquement le numéro de série lors de chaque changement de zone.
• Éviter les modifications manuelles susceptibles de diminuer le numéro de série par erreur.

5. SOA REFRESH

REFRESH définit la fréquence à laquelle les serveurs secondaires doivent vérifier auprès du primaire si le numéro de série de la zone a changé.

Pourquoi c’est important

Si REFRESH est trop élevé, les changements effectués sur le primaire peuvent prendre beaucoup de temps à atteindre les secondaires. S’il est trop faible, les secondaires interrogent trop souvent le primaire et génèrent un trafic inutile.

Comment DNSprobe vérifie ce point

DNSprobe lit la valeur REFRESH (en secondes) et la compare à des plages opérationnelles courantes, en ajoutant un commentaire dans le rapport.

Problèmes courants détectés

• REFRESH très élevé entraînant des retards de plusieurs heures ou jours avant que les secondaires ne détectent une mise à jour.
• REFRESH extrêmement faible générant un volume élevé de requêtes SOA de la part des secondaires.
• Valeurs incohérentes avec votre fréquence réelle de mise à jour de la zone (par exemple, zone très dynamique avec REFRESH très lent).

Bonnes pratiques

• Choisir un REFRESH adapté au rythme de modification de la zone (souvent entre quelques minutes et quelques heures).
• Pour les zones très stables, un REFRESH plus long réduit la charge sans problème particulier.
• Pour les zones fréquemment mises à jour, conserver un REFRESH suffisamment court pour que les secondaires suivent les changements.

6. SOA RETRY

RETRY définit le délai avant qu’un serveur secondaire ne réessaie un rafraîchissement lorsque le primaire était injoignable.

Pourquoi c’est important

Si RETRY est trop long, les secondaires peuvent attendre longtemps avant de retenter un rafraîchissement, ce qui ralentit la reprise après incident. S’il est trop court, ils risquent de surcharger un primaire déjà en panne.

Comment DNSprobe vérifie ce point

DNSprobe lit la valeur RETRY et vérifie qu’elle est inférieure à REFRESH et qu’elle reste dans une plage raisonnable pour des opérations DNS normales.

Problèmes courants détectés

• RETRY supérieur ou égal à REFRESH, ce qui rend la logique de rafraîchissement moins efficace.
• RETRY très long retardant la reprise après des problèmes réseau temporaires.
• RETRY extrêmement court provoquant des rafales répétées de tentatives de rafraîchissement échouées.

Bonnes pratiques

• Configurer RETRY nettement plus bas que REFRESH pour que les secondaires réessaient rapidement après une erreur.
• Utiliser une valeur modérée – souvent quelques minutes – pour équilibrer rapidité de récupération et charge.
• Revoir RETRY en même temps que REFRESH et EXPIRE afin que toutes les minuteries soient cohérentes entre elles.

7. SOA EXPIRE

EXPIRE définit la durée maximale pendant laquelle un serveur secondaire peut continuer à servir la zone s’il ne réussit jamais à contacter le primaire.

Pourquoi c’est important

Si EXPIRE est trop faible, une longue panne du primaire peut amener les secondaires à arrêter complètement de servir la zone. S’il est trop élevé, des données obsolètes peuvent persister longtemps après un changement critique.

Comment DNSprobe vérifie ce point

DNSprobe lit la valeur EXPIRE et vérifie qu’elle est bien plus élevée que REFRESH et RETRY, et qu’elle se situe dans une fenêtre réaliste (souvent plusieurs jours).

Problèmes courants détectés

• EXPIRE trop faible, risquant une coupure complète de la zone pendant une maintenance ou un incident prolongé.
• EXPIRE défini à une valeur qui n’est pas significativement supérieure à REFRESH.
• EXPIRE extrêmement élevé maintenant des données obsolètes bien au-delà de ce qui est acceptable.

Bonnes pratiques

• Choisir un EXPIRE aligné sur votre tolérance au risque – souvent 1 à 2 semaines ou plus pour les zones critiques.
• Veiller à ce qu’EXPIRE soit un multiple important de REFRESH et RETRY, afin qu’il ne s’active que dans des cas exceptionnels.
• Revoir EXPIRE lors de toute modification de votre stratégie de redondance ou de reprise après sinistre.

8. SOA MINIMUM TTL

Le champ MINIMUM servait historiquement de TTL par défaut, mais il est aujourd’hui surtout utilisé comme TTL de cache négatif (durée pendant laquelle les résolveurs peuvent mémoriser une réponse « n’existe pas »).

Pourquoi c’est important

Si le TTL négatif est trop élevé, de nouveaux enregistrements peuvent sembler « inexistants » longtemps après leur création, car les résolveurs ont mis en cache d’anciennes réponses NXDOMAIN. S’il est trop faible, les résolveurs vont interroger très souvent pour des noms inexistants.

Comment DNSprobe vérifie ce point

DNSprobe lit la valeur MINIMUM et commente si elle paraît adaptée à la mise en cache négative d’une zone publique typique.

Problèmes courants détectés

• MINIMUM très élevé entraînant de longs délais avant que de nouveaux enregistrements apparaissent après d’anciens NXDOMAIN.
• MINIMUM très faible générant un trafic supplémentaire pour des noms inexistants.
• Valeurs en contradiction avec votre politique de TTL par enregistrement.

Bonnes pratiques

• Utiliser un TTL négatif modéré – assez long pour réduire la charge, mais pas au point de bloquer l’apparition de nouveaux enregistrements.
• Aligner MINIMUM sur la fréquence à laquelle vous ajoutez de nouveaux noms d’hôtes à la zone.
• Garder en tête que de nombreuses plateformes DNS modernes utilisent des TTL par enregistrement et traitent MINIMUM surtout comme une indication pour le cache négatif.

9. Tester les enregistrements SOA manuellement depuis votre propre terminal

DNSprobe lit l’enregistrement SOA (Start of Authority) de votre zone et vérifie que tous les serveurs de noms utilisent le même numéro de série ainsi que les mêmes valeurs de temporisation (refresh, retry, expire, TTL minimum). Vous pouvez consulter l’enregistrement SOA brut depuis un terminal et comparer le numéro de série sur chaque serveur faisant autorité.

Linux : utiliser dig (outils BIND)

Sur la plupart des distributions Linux, la commande dig est fournie par le paquet d’outils BIND. Les commandes suivantes affichent l’enregistrement SOA de votre domaine, puis interrogent chaque serveur de noms afin que vous puissiez confirmer que le numéro de série est identique partout :

                dig example.com SOA
                dig example.com SOA +noall +answer
    
                # Optionnel : interroger directement chaque serveur de noms faisant autorité et comparer les numéros de série SOA    
                dig @ns1.example.com example.com SOA
                dig @ns2.example.com example.com SOA
        

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 voir l’enregistrement SOA et vérifier que tous les serveurs de noms exposent le même numéro de série :

                dig example.com SOA
                dig example.com SOA +noall +answer
    
                # Optionnel : interroger directement chaque serveur de noms faisant autorité et comparer les numéros de série SOA    
                dig @ns1.example.com example.com SOA
                dig @ns2.example.com example.com SOA
        

Windows : utiliser nslookup

Sous Windows, l’outil historique nslookup permet d’interroger l’enregistrement SOA de votre domaine. Exécutez les commandes suivantes dans une fenêtre Invite de commandes ou PowerShell. Vous pouvez d’abord demander l’enregistrement SOA générique, puis interroger explicitement chaque serveur de noms pour vérifier qu’ils renvoient tous le même numéro de série :

                nslookup -type=SOA example.com
    
                REM Optionnel : préciser chaque serveur de noms faisant autorité pour comparer les numéros de série SOA    
                nslookup -type=SOA example.com ns1.example.com
                nslookup -type=SOA example.com ns2.example.com
        

Important : n’interrogez que les enregistrements DNS de domaines que vous possédez ou que vous êtes autorisé à analyser. Certains fournisseurs peuvent considérer des requêtes répétées et automatisées sur des domaines tiers comme du trafic abusif.