C'est quoi un enregistrement SOA en DNS ?

Si vous avez déjà exploré les enregistrements DNS d'un domaine avec dig ou un outil en ligne, vous avez probablement croisé un enregistrement SOA sans trop savoir à quoi il servait. C'est pourtant l'un des enregistrements les plus importants d'une zone DNS : il définit qui fait autorité sur cette zone, comment les serveurs DNS secondaires doivent se synchroniser, et combien de temps les données restent valides en cas de panne.

Ce que contient un enregistrement SOA

SOA signifie Start of Authority. Chaque zone DNS doit obligatoirement contenir exactement un enregistrement SOA. Il se trouve toujours au sommet de la zone et contient sept champs distincts. Voici à quoi ressemble un enregistrement SOA typique :

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Décomposons chaque champ :

MNAME (ns1.example.com.) : le serveur DNS primaire de la zone, celui qui fait autorité en premier. C'est le serveur que les DNS secondaires contactent pour obtenir les mises à jour
RNAME (admin.example.com.) : l'adresse email de l'administrateur de la zone, mais avec un point à la place du @. Ici, ça correspond à [email protected]. Si l'adresse contient un point avant le @, il faut l'échapper avec un antislash (prenom\.nom.example.com.)
Serial (2025052901) : un numéro de version de la zone. Chaque modification doit incrémenter ce numéro, sinon les serveurs secondaires ne détecteront pas le changement. Le format courant est YYYYMMDDNN (date + compteur du jour)
Refresh (7200) : l'intervalle en secondes entre deux vérifications par les serveurs secondaires. Ici, toutes les 2 heures
Retry (3600) : le délai avant un nouvel essai si la vérification Refresh échoue. Ici, 1 heure
Expire (1209600) : le temps au bout duquel un serveur secondaire cesse de répondre pour cette zone s'il n'arrive plus à joindre le primaire. Ici, 14 jours. Passé ce délai, le secondaire considère ses données comme périmées et arrête de servir la zone
Minimum TTL (86400) : depuis la RFC 2308, ce champ définit la durée de cache des réponses négatives (NXDOMAIN). Ici, 24 heures. Si quelqu'un demande un sous-domaine qui n'existe pas, le résolveur mettra cette réponse "n'existe pas" en cache pendant 24 heures

Pourquoi le numéro de série compte autant

Le serial est probablement le champ qui cause le plus de problèmes en pratique. Quand un serveur secondaire contacte le primaire lors d'un cycle de Refresh, il compare le numéro de série de sa copie avec celui du primaire. Si le serial du primaire est plus élevé, le secondaire lance un transfert de zone (AXFR ou IXFR) pour se mettre à jour. Si le serial n'a pas changé, il ne fait rien.

L'erreur classique : modifier un enregistrement DNS sur le primaire sans incrémenter le serial. Résultat, le primaire a la bonne version mais les secondaires gardent l'ancienne pendant des heures, voire des jours. Les utilisateurs voient des réponses différentes selon le serveur qu'ils interrogent, et le problème est difficile à diagnostiquer si on ne pense pas à vérifier le SOA.

Le format YYYYMMDDNN est une convention, pas une obligation. Le serial est un entier sur 32 bits, donc toute valeur entre 0 et 4 294 967 295 fonctionne. Mais le format date est recommandé car il rend les erreurs visibles : un serial à 2025052901 est clairement la première modification du 29 mai 2025.

Comment les valeurs Refresh, Retry et Expire interagissent

Ces trois valeurs forment un système de résilience pour les zones DNS. Le Refresh définit le rythme normal de synchronisation. Le Retry prend le relais en cas d'échec. L'Expire est le garde-fou ultime : au-delà de cette durée sans contact avec le primaire, le secondaire préfère ne plus répondre du tout plutôt que servir des données potentiellement obsolètes.

Pour un domaine standard, les valeurs recommandées par la RFC 1912 sont :

Refresh : 3600 à 86400 secondes (1 heure à 24 heures)
Retry : 600 à 3600 secondes (10 minutes à 1 heure)
Expire : 1209600 à 2419200 secondes (2 à 4 semaines)
Minimum TTL : 3600 à 86400 secondes (1 heure à 24 heures)

Si votre zone change fréquemment (par exemple un CDN ou une infrastructure avec du load balancing dynamique), réduisez le Refresh à 300 ou 600 secondes. Si elle est stable, 86400 convient parfaitement et réduit la charge sur le serveur primaire.

Comment consulter l'enregistrement SOA d'un domaine

Sur Linux et macOS, la commande dig est la plus pratique :

dig SOA example.com

Sur Windows, utilisez nslookup :

nslookup -type=SOA example.com

La réponse affiche les sept champs du SOA. Vérifiez en particulier le serial : s'il semble ancien ou figé, c'est souvent le signe que les modifications DNS ne se propagent pas correctement.

Erreurs fréquentes sur le SOA

Quelques problèmes qu'on rencontre régulièrement en pratique :

Le RNAME utilise un @ au lieu d'un point, ce qui casse la syntaxe. [email protected] doit s'écrire admin.example.com. dans le SOA
Le serial est décrémenté par erreur après une restauration de sauvegarde. Les secondaires refuseront de se synchroniser tant que le serial du primaire ne repassera pas au-dessus de leur valeur locale
L'Expire est trop court (quelques heures). Si le primaire tombe pendant un week-end, les secondaires cessent de répondre avant que quelqu'un ait pu intervenir
Le Minimum TTL est à 0, ce qui signifie que les résolveurs ne cachent pas les réponses négatives. Chaque requête vers un sous-domaine inexistant génère un aller-retour complet, ce qui peut surcharger vos serveurs DNS sous un scan ou une attaque

L'enregistrement SOA est rarement celui qu'on modifie en premier quand on configure un domaine, mais c'est souvent celui qui explique pourquoi "les DNS ne se propagent pas". Avant de chercher des causes complexes, vérifiez que le serial a bien été incrémenté et que les valeurs Refresh et Expire sont adaptées à votre usage.