Une recherche SOA renvoie l'enregistrement Start of Authority d'un domaine : les délais qui régissent les transferts de zone, la synchronisation des serveurs secondaires et la durée de mise en cache négative.
Qu'est-ce qu'un enregistrement SOA ?
Chaque zone DNS possède exactement un enregistrement Start of Authority (SOA), défini par la RFC 1035. Il identifie le serveur de noms principal de la zone, un contact email pour l'administrateur, ainsi qu'un numéro de série et quatre délais que les serveurs secondaires utilisent pour rester synchronisés avec le serveur principal.
Contrairement à un enregistrement A ou MX, le SOA n'est pas quelque chose que les visiteurs consultent directement. Il fait partie de la mécanique interne du DNS : les secondaires le consultent pour savoir quand retransférer la zone, et les résolveurs utilisent son dernier champ pour déterminer la durée de mise en cache d'une réponse négative.
- Un seul enregistrement SOA par zone, toujours à l'apex
- Le numéro de série est un compteur de version, sans format imposé
- Quatre délais (refresh, retry, expire, minimum) pilotent la synchronisation et la mise en cache négative
Les sept champs du SOA
Un enregistrement SOA brut tient sur une seule ligne avec sept champs séparés par des espaces, dans cet ordre fixe : serveur de noms principal, email de l'administrateur (le @ remplacé par un point), serial, refresh, retry, expire et minimum. Un enregistrement typique ressemble à ceci :
ns1.example.com. hostmaster.example.com. 2026071401 7200 3600 1209600 3600
En décomposant cette ligne : ns1.example.com. est le serveur principal (master) de la zone ; hostmaster.example.com. se décode en hostmaster@example.com ; 2026071401 est le serial ; puis viennent, en secondes, refresh, retry, expire et minimum.
Les conventions de numéro de série
La RFC 1035 définit le serial uniquement comme un entier non signé de 32 bits comparé selon une arithmétique d'espace séquentiel - elle n'impose aucun format. En pratique, presque toutes les zones utilisent l'une de deux conventions.
La plus répandue est YYYYMMDDnn : une date suivie d'un compteur de révision à deux chiffres, par exemple 2026071401 pour la première modification du 14 juillet 2026. Ce format est apprécié car il permet de lire directement la date de dernière modification dans le serial. L'autre convention est un simple entier incrémenté de un à chaque modification, sans signification calendaire.
La seule règle stricte est que le serial doit augmenter (au sens de l'arithmétique de la RFC 1035) à chaque modification de la zone. Un secondaire compare le serial qu'il détient à celui du SOA du primaire à chaque intervalle de refresh ; si la nouvelle valeur n'est pas "supérieure", il considère la zone inchangée et n'effectue pas de transfert, même si les enregistrements ont réellement changé.
Refresh, retry, expire, minimum : le rôle de chaque délai
Les quatre champs numériques après le serial sont les délais utilisés par les secondaires pour rester à jour. Cet outil rapporte ce que le serveur primaire déclare actuellement ; les serveurs secondaires non interrogés directement n'apparaissent pas.
| Champ | Rôle | Plage habituelle |
|---|---|---|
| Refresh | Fréquence à laquelle un secondaire vérifie le serial du primaire pour détecter un besoin de transfert | 1 à 24 heures |
| Retry | Délai d'attente avant qu'un secondaire retente un refresh après un échec | 10 minutes à 1 heure |
| Expire | Durée pendant laquelle un secondaire continue de répondre avec les données de zone périmées s'il ne joint plus du tout le primaire | 1 à 4 semaines |
| Minimum | TTL de mise en cache négative - durée pendant laquelle un résolveur peut mémoriser une réponse NXDOMAIN ou l'absence de données (RFC 2308) | 5 minutes à 1 heure |
Le champ minimum et la mise en cache négative
Dans la RFC 1035 d'origine, le dernier champ du SOA était documenté comme le TTL par défaut des enregistrements de la zone. La RFC 2308 (1998) l'a redéfini spécifiquement comme le TTL de mise en cache négative : la durée maximale pendant laquelle un résolveur doit retenir le fait qu'un nom ou un type d'enregistrement donné n'existe pas.
Cela a des conséquences pratiques souvent sous-estimées. Si un domaine n'avait temporairement pas d'enregistrement AAAA et qu'un résolveur a mis cette absence en cache pendant toute la durée du minimum, l'ajout ultérieur d'un AAAA ne deviendra visible pour ce résolveur qu'une fois l'entrée négative expirée, quel que soit le TTL défini sur le nouvel enregistrement. Un champ minimum laissé à une ancienne valeur par défaut d'une journée entière signifie qu'un état "l'enregistrement n'existe pas encore" peut survivre à une correction faite le jour même - un piège classique après une migration d'hébergeur chez un client français passant, par exemple, d'OVH à un autre fournisseur.
Lire les résultats d'une recherche SOA
Cet outil interroge l'enregistrement SOA de la zone et l'affiche sur une seule ligne, dans le même ordre de champs que l'enregistrement brut : serveur principal, email administrateur, serial, refresh, retry, expire, minimum. Il n'y a rien à comparer : un domaine n'a qu'un seul SOA faisant autorité à un instant donné, tel que rapporté par son serveur de noms principal.
Si la requête ne renvoie aucun enregistrement SOA, soit le domaine n'existe pas comme zone, soit la requête a atteint un serveur qui ne fait pas autorité pour cette zone. Une zone déléguée et fonctionnelle a toujours un SOA à son apex.
Questions fréquentes
Pourquoi le numéro de série du SOA compte-t-il si je ne fais jamais de transferts de zone ?
Même sans transferts AXFR/IXFR classiques, la plupart des hébergeurs DNS gérés utilisent en interne la même logique de comparaison de serial pour propager les changements vers leurs propres serveurs périphériques. Un serial qui n'augmente pas après une modification - par exemple à cause d'une automatisation qui le réinitialise - peut empêcher une mise à jour de se propager silencieusement.
Que se passe-t-il si le numéro de série déborde ou boucle ?
La RFC 1982 définit précisément l'arithmétique des numéros de série pour ce cas : les comparaisons utilisent une arithmétique modulaire sur l'espace des 32 bits, si bien qu'une valeur ayant bouclé peut quand même être reconnue comme "plus récente" tant qu'elle reste dans la moitié de l'espace numérique. En pratique, cela ne devient pertinent que pour des zones modifiées très fréquemment sur plusieurs décennies.
Le serveur principal indiqué dans le SOA peut-il différer des enregistrements NS du domaine ?
Oui. Le SOA identifie le serveur principal (master) utilisé pour la maintenance de la zone, qui n'est pas toujours listé publiquement dans les enregistrements NS de la zone elle-même - certains hébergeurs font tourner un primaire caché et ne publient que des secondaires visibles publiquement.
Pourquoi mon nouvel enregistrement a-t-il mis du temps à apparaître comme absent, puis du temps à apparaître comme disponible ?
C'est l'effet du TTL de mise en cache négative défini par le champ minimum du SOA. Un résolveur ayant déjà mis en cache "cet enregistrement n'existe pas" continuera de répondre depuis son cache jusqu'à l'expiration de cette entrée, tirée du minimum, indépendamment du TTL fixé sur le nouvel enregistrement.
Les serveurs secondaires se resynchronisent-ils selon un calendrier fixe quel que soit le refresh du SOA ?
Non - refresh est l'intervalle qu'un secondaire est censé respecter selon la RFC 1035. Les secondaires bien configurés prennent aussi en charge NOTIFY (RFC 1996), qui permet au primaire d'envoyer un signal de resynchronisation immédiat après un changement plutôt que d'attendre tout l'intervalle de refresh.
Une valeur d'expire basse est-elle risquée ?
Cela peut l'être. Expire borne la durée pendant laquelle un secondaire continue de répondre avec les dernières données valides de la zone s'il perd totalement le contact avec le primaire. La fixer trop bas expose à voir un secondaire devenir non-autoritaire (refuser de répondre) pendant une panne du primaire qui serait sinon restée invisible pour les utilisateurs.
Outils liés
- Vérifier quels serveurs de noms sont réellement délégués pour la zone en complément du SOA
- Lancer un audit plus complet de la zone au-delà des seuls délais du SOA
- Vérifier si différents résolveurs s'accordent sur le serial et les enregistrements actuels
- Vérifier les enregistrements de routage mail présents dans la même zone que ce SOA