Serveur DNS primaire : qui détient vraiment la zone

Le serveur DNS primaire est le serveur faisant autorité qui charge la zone depuis une source locale : un fichier, une base ou une API. Les secondaires en recopient le contenu par transfert AXFR ou IXFR, puis répondent aux résolveurs exactement comme lui.

Sommaire

Le primaire est celui qui détient le fichier de zone

Prenez une zone `exemple.fr`. Le serveur qui charge son contenu depuis une source locale, fichier texte sur disque, base SQL ou API de votre hébergeur, c'est le primaire. Les autres serveurs faisant autorité pour cette zone, les secondaires, n'inventent rien : ils recopient ce qu'il publie et le rediffusent.

La distinction tient à ça, et à rien d'autre : l'origine des données.

Une fois la zone chargée, primaire et secondaire répondent aux résolveurs de façon rigoureusement identique, bit AA compris. Un client ne peut pas deviner lequel il interroge et n'a aucune raison de préférer l'un à l'autre. Le champ MNAME du SOA nomme bien le primaire, mais c'est une déclaration à usage interne : elle sert aux mises à jour dynamiques (RFC 2136) et identifie l'émetteur légitime des paquets NOTIFY.

RFC 1034 et 1035 posent ce modèle depuis novembre 1987. Le vocabulaire, lui, a bougé : la RFC 8499 de janvier 2019 a acté primary/secondary à la place de master/slave. BIND accepte `type primary;` comme alias de `type master;` depuis la version 9.16, et les deux syntaxes cohabitent encore dans quantité de configurations en production.

Rien n'interdit à une même machine d'être primaire pour dix zones et secondaire pour cinquante autres. Chez un hébergeur, c'est même la situation normale.

Ne le confondez pas avec le « DNS primaire » de votre box

C'est la confusion la plus fréquente et elle n'a rien d'anodin. Quand votre box, Windows ou un tutoriel vous réclame un « DNS primaire » et un « DNS secondaire », il ne s'agit pas de serveurs d'autorité mais de résolveurs récursifs : 1.1.1.1, 9.9.9.9, ceux de votre opérateur. Ces machines ne détiennent aucune zone, elles parcourent l'arborescence pour vous et gardent les réponses en cache.

Le point commun entre les deux se limite au mot « primaire » et au port 53.

Second malentendu autour de ces deux champs : le secondaire n'est pas un serveur de secours qui prendrait le relais lors d'une panne franche. Avec le résolveur glibc, `/etc/resolv.conf` applique par défaut `timeout:5` et `attempts:2`, et ne lit que trois lignes `nameserver` au maximum. Si le premier cesse de répondre, chaque requête attend cinq secondes avant de basculer sur le suivant. La navigation devient poisseuse bien avant que quiconque prononce le mot panne.

	DNS primaire (résolveur)	Serveur primaire d'autorité
Où il se configure	Box, carte réseau, /etc/resolv.conf	Chez l'hébergeur DNS, dans named.conf
Ce qu'il détient	Un cache, rien de permanent	Le fichier de zone d'origine
Qui le choisit	Vous, pour vos propres requêtes	Le titulaire du domaine, pour tout Internet
Exemples	1.1.1.1, 8.8.8.8, 9.9.9.9	ns1.votre-hebergeur.net
Bit AA dans la réponse	absent	présent

Comment le primaire alimente ses secondaires

Vous éditez la zone, vous incrémentez le numéro de série, vous rechargez. Le primaire envoie alors un paquet NOTIFY (RFC 1996) à chaque serveur listé dans les NS de la zone. Le secondaire qui le reçoit ne croit personne sur parole : il interroge le SOA du primaire, compare les deux séries selon l'arithmétique circulaire de la RFC 1982, et ne déclenche un transfert que si le compteur a progressé.

Deux transferts coexistent. AXFR (RFC 5936) rapatrie la zone entière et impose TCP sur le port 53. IXFR (RFC 1995) ne demande que le delta depuis un série donné, ce qui change tout quand la zone pèse 200 000 enregistrements et qu'on y touche trois fois par heure.

Si le NOTIFY se perd en route, rien n'est cassé pour autant.

Les compteurs du SOA prennent le relais et rythment la réplication en mode dégradé :

Expire est le champ qu'on oublie et qui mord. Fixé à 1209600 secondes, soit quatorze jours, il veut dire que si le primaire reste injoignable deux semaines, les secondaires arrêtent délibérément de servir la zone. Ils sont debout, en pleine forme, et le domaine disparaît quand même de la résolution.

Champ SOA	Rôle	Fourchette conseillée (RFC 1912)
Refresh	Délai entre deux vérifications du série par le secondaire	1200 à 43200 s
Retry	Attente après un échec de contact du primaire	120 à 7200 s
Expire	Durée au bout de laquelle le secondaire cesse de servir la zone	1209600 à 2419200 s
Minimum	TTL des réponses négatives NXDOMAIN (RFC 2308)	3600 à 86400 s

Vérifier et diagnostiquer en ligne de commande

Cinq commandes couvrent la quasi-totalité des cas :

La panne classique n'a rien de spectaculaire. Vous modifiez un enregistrement A, vous rechargez le primaire avec `rndc reload`, tout semble propre de votre côté. Sauf que le numéro de série est resté à 2026081501. Les secondaires comparent, ne voient aucune progression, ne transfèrent rien. La moitié des résolveurs de la planète sert alors l'ancienne IP et l'autre la nouvelle, selon le serveur d'autorité qu'ils ont interrogé. La boucle ci-dessus met ce désaccord en évidence en deux secondes.

Écrivez le série au format AAAAMMJJnn comme le recommande la RFC 1912 section 2.2, et l'oubli se repère à l'œil nu.

`dig +short SOA exemple.fr` : renvoie le MNAME déclaré et le numéro de série courant.
`dig @ns2.exemple.fr exemple.fr SOA +norec` : interroge un secondaire précis, sans passer par un cache.
`for ns in $(dig +short NS exemple.fr); do dig +short SOA exemple.fr @$ns; done` : compare les séries de tous les serveurs de la zone en une passe.
`named-checkzone exemple.fr /var/named/exemple.fr.zone` : valide la syntaxe avant de recharger, pas après.
`dig @ns1.exemple.fr exemple.fr AXFR` : doit échouer sur une infrastructure correctement fermée.

Primaire caché et verrouillage des transferts

Une pratique répandue consiste à ne publier aucun enregistrement NS pointant vers le primaire. On parle alors de primaire caché : la machine signe la zone, encaisse les mises à jour dynamiques et pousse ses NOTIFY vers les secondaires, mais aucun résolveur ne connaît son adresse. La surface publique se limite aux IP des secondaires, souvent en anycast, et les clés DNSSEC restent sur un serveur qui ne voit passer aucun trafic venu d'Internet.

Le transfert de zone, lui, se protège avec TSIG (RFC 8945, qui remplace la RFC 2845 depuis novembre 2020) : une clé secrète partagée, un HMAC dans chaque requête, et le primaire ne répond qu'aux secondaires légitimes.

Vérifiez ce point sur vos propres domaines, il est plus souvent ouvert qu'on ne le croit.

Tant qu'aucune directive `allow-transfer` n'est posée dans BIND, la zone se laisse rapatrier par n'importe qui. Un AXFR réussi livre d'un seul coup l'inventaire complet : noms des machines internes, préproduction, concentrateur VPN, serveur de sauvegarde, adresses de management. Le test tient en une ligne et il vaut mieux le passer avant quelqu'un d'autre.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Dans l'enregistrement SOA, quel champ nomme le serveur primaire ?

Questions fréquentes

Combien de serveurs primaires une zone peut-elle avoir ?

Un seul dans le modèle standard : le champ MNAME du SOA n'accepte qu'un nom. Certaines implémentations comme PowerDNS contournent la contrainte en répliquant la base sous-jacente entre plusieurs serveurs, tous capables d'écrire ; le DNS ne voit alors qu'une seule source déclarée. En revanche, la plupart des registres exigent au minimum deux serveurs de noms déclarés pour le domaine, primaire et secondaires confondus.

Comment identifier le serveur primaire d’un domaine ?

`dig +short SOA exemple.fr` renvoie le MNAME en premier champ. Deux réserves : ce champ est purement déclaratif et rien ne garantit qu'il corresponde à la machine qui charge réellement la zone ; un primaire caché n'y figure d'ailleurs pas toujours, et beaucoup d'hébergeurs y placent un nom générique partagé par des milliers de zones.

Le serveur primaire répond-il plus vite ou mieux que le secondaire ?

Non. Une fois la zone transférée, les deux servent des données identiques avec le même bit AA. Le seul écart possible est temporel : quelques secondes entre le rechargement du primaire et l'arrivée du transfert chez le secondaire, ou bien plusieurs heures si les NOTIFY sont bloqués et que la synchronisation attend l'expiration du Refresh.

Que se passe-t-il si le serveur primaire tombe ?

Rien de visible dans un premier temps : les secondaires continuent à répondre avec la copie qu'ils détiennent, et cela jusqu'au délai fixé par Expire, souvent quatorze jours. Vous perdez seulement la capacité à modifier la zone et les mises à jour dynamiques échouent. Au-delà d'Expire, en revanche, les secondaires renvoient SERVFAIL et le domaine cesse de résoudre.

Primaire et master, secondaire et slave : y a-t-il une différence ?

Aucune, c'est le même rôle sous deux vocabulaires. La RFC 8499 (janvier 2019) a retenu primary et secondary comme termes de référence. Les anciens mots restent valides dans les fichiers de configuration et vous les croiserez longtemps encore dans la documentation et les scripts existants.