Un SOA record décrit l'autorité d'une zone DNS. Il indique le serveur primaire autoritaire et l'adresse de contact. Il fournit un numéro de série ainsi que des temporisations pour la synchronisation des serveurs secondaires.
Un SOA record contient un nom un type un serveur primaire un contact un numéro de série et cinq durées. Le TTL indique combien de temps la réponse reste en cache dans le résolveur local.
| Nom | Type | Serveur primaire MNAME | Contact RNAME | Serial | Refresh | Retry | Expire | Minimum TTL | TTL en secondes |
|---|
| @ | SOA | ns1.exemple.net. | hostmaster.exemple.com. | 2025090301 | 7200 | 900 | 1209600 | 3600 | 3600 |
Dans cet exemple le nom @ vise l'apex de la zone. Le serveur primaire doit résoudre en A ou AAAA. Le contact s'écrit comme une adresse courriel avec un point à la place de l'arobase. Par exemple hostmaster.exemple.com correspond à hostmaster@exemple.com. Le serial progresse à chaque modification de la zone. Les valeurs refresh retry expire et minimum TTL sont en secondes.
Le serveur primaire MNAME désigne l'hôte de référence pour la zone.
Le contact RNAME reçoit les messages liés à la zone.
Le serial permet aux secondaires de savoir si une version plus récente existe.
Refresh indique quand un secondaire vérifie le primaire.
Retry indique l'attente entre deux tentatives après un échec.
Expire indique après combien de temps un secondaire abandonne une zone devenue impossible à mettre à jour.
Minimum TTL sert au cache négatif. Il fixe la durée pendant laquelle une absence de réponse reste en cache. Le TTL par défaut des enregistrements se règle ailleurs dans la zone.
Bon à savoir
Il n'existe qu'un seul SOA par zone. Il se publie à l'apex aux côtés des enregistrements NS. Le champ minimum TTL ne définit pas le TTL par défaut des autres enregistrements. Il sert au cache négatif.
Le TTL du SOA contrôle la durée de cache de la réponse SOA côté résolveur. Un TTL trop long peut retarder la prise en compte d'un changement de serial. Un TTL raisonnable améliore la réactivité sans surcharger les serveurs autoritaires.
À l'apex de la zone. Toujours. Les sous domaines délégués possèdent leur propre SOA dans leur zone dédiée. Un CNAME ne doit pas apparaître à l'apex car la zone doit déjà publier SOA et NS.
À éviter
Oublier d'augmenter le serial après une modification de la zone.
Mettre un serveur primaire qui ne résout pas en A ou AAAA.
Inverser refresh et retry.
Utiliser un expire trop court qui fait tomber la zone chez les secondaires.
Un DNS lookup en ligne permet de saisir un nom de domaine. Le résultat affiche le SOA tel qu'il est vu depuis Internet. On lit le serveur primaire le contact le serial et les temporisations. Ensuite réaliser un test local depuis sa machine.
Windows fournit nslookup. On peut l'utiliser en mode interactif.
nslookup
set q=soa
exemple.com
nslookup
set q=soa
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.
Sur ces systèmes la commande dig est pratique et facile à utiliser.
dig SOA exemple.com
dig SOA exemple.com @1.1.1.1
Un serial plus ancien sur un serveur secondaire indique un retard de transfert.
Un refresh très long retarde la propagation des changements.
Un expire trop court peut provoquer l'abandon de la zone par un secondaire.
Un contact mal formé empêche la réception de messages utiles.
- Préparer la mise à jour de la zone.
- Augmenter le serial.
- Recharger la zone sur le serveur primaire.
- Laisser les secondaires se mettre à jour ou déclencher un transfert si l'outil le permet.
- Vérifier le nouveau serial depuis plusieurs réseaux puis valider.
Astuce pratique
Adopter un format de serial prévisible. Un format date suivi d'un compteur facilite le suivi. Par exemple 2025090301 pour la première modification du jour.
Mettre en place la zone sur le nouveau service. Vérifier SOA et NS. Basculer la délégation quand tout est prêt.
Autoriser le transfert de zone sur le primaire. Vérifier que le secondaire récupère bien la zone et affiche le bon serial.
Mettre à jour RNAME. Tester que les messages arrivent au bon destinataire.
- Si le SOA diffère selon les serveurs autoritaires patienter un cycle de refresh puis vérifier de nouveau.
- Si un secondaire reste bloqué sur un ancien serial vérifier l'accès réseau et les droits de transfert de zone.
- Si la zone disparaît chez un secondaire augmenter expire et vérifier la santé du primaire.
- 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 SOA définit l'autorité d'une zone. Il indique le serveur primaire le contact le serial et les temporisations qui régulent la synchronisation. Un seul SOA à l'apex. Des valeurs cohérentes assurent une propagation fiable. 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 services DNS répondent comme prévu.