Hébergement de zone DNS : primaire, secondaire et transferts
Un serveur unique qui héberge une zone est un point de panne unique pour tout un domaine. La réplication entre serveurs primaire et secondaires repose sur des mécanismes normalisés, AXFR, IXFR et NOTIFY, dont le comportement réel explique la plupart des incohérences observées en exploitation.
Primaire et secondaire : deux rôles, un même contenu
Le serveur primaire est celui sur lequel la zone est écrite ; les serveurs secondaires en détiennent une copie obtenue par transfert. La terminologie officielle de la RFC 8499 a remplacé les termes maître et esclave, mais le principe n'a pas changé : une seule source d'écriture, plusieurs serveurs qui répondent aux résolveurs avec le même contenu. Un secondaire n'est pas un serveur au rabais : du point de vue d'un résolveur, il fait pleinement autorité.
Cette architecture a une conséquence pratique souvent négligée : toute modification appliquée au primaire finit par atteindre les secondaires, y compris une erreur. La réplication protège de la panne d'une machine, pas d'une faute de saisie. C'est pourquoi les contrôles se font sur le primaire avant publication, et non sur les copies après coup.
Le transfert complet, AXFR
Le transfert de zone complet, décrit dans la RFC 5936, s'effectue sur TCP : un secondaire ouvre une connexion, demande la totalité de la zone, et reçoit les enregistrements en flux, encadrés par l'enregistrement SOA au début et à la fin. Le protocole impose TCP parce que la réponse dépasse presque toujours la taille d'un datagramme, et parce que la perte d'un paquet ne doit pas laisser une copie partielle.
AXFR transporte l'intégralité de la zone à chaque fois. Sur une zone de quelques dizaines d'enregistrements, l'opération est indolore ; sur une zone volumineuse répliquée souvent, elle devient coûteuse en bande passante et en temps processeur. C'est cette limite qui a motivé le transfert incrémental, sans faire disparaître AXFR, qui reste le recours quand aucun historique n'est disponible.
Le transfert incrémental, IXFR
Décrit dans la RFC 1995, IXFR permet à un secondaire de demander seulement les différences depuis le numéro de série qu'il détient. Le primaire consulte son journal des modifications et renvoie les suppressions et ajouts successifs. Le gain est réel sur les zones modifiées souvent et peu à la fois, ce qui correspond au fonctionnement courant d'un hébergement de zone.
Le mécanisme a une condition : le primaire doit conserver un historique couvrant le série du secondaire. Si le secondaire est resté trop longtemps arrêté, ou si le journal a été purgé, le primaire répond par un transfert complet. Un secondaire qui retombe régulièrement en AXFR signale un journal trop court ou une indisponibilité prolongée, et mérite un examen plutôt qu'un réglage à l'aveugle.
NOTIFY : prévenir au lieu d'attendre
Sans notification, un secondaire découvre un changement en interrogeant périodiquement le SOA du primaire, à l'intervalle de rafraîchissement. Ce délai est prévu par la norme et peut se compter en heures. La RFC 1996 définit un message de notification, envoyé par le primaire aux secondaires dès qu'il recharge la zone, qui déclenche immédiatement la vérification du série et le transfert si nécessaire.
NOTIFY ne remplace pas le rafraîchissement périodique : il l'accélère. Une notification perdue est sans conséquence, la rotation normale reprenant la main. En revanche, un primaire configuré sans destinataires de notification donne l'illusion d'une zone répliquée instantanément, alors que les secondaires suivent à leur rythme : c'est un écart perceptible lors des changements urgents.
Autoriser et authentifier les transferts
Un transfert de zone expose l'intégralité du contenu, noms internes compris. Les logiciels de serveur de noms permettent de restreindre les adresses autorisées à demander un AXFR, et cette restriction doit être posée explicitement : un transfert ouvert est une fuite d'inventaire, pas une fonctionnalité. Par défaut, les distributions récentes refusent d'ailleurs les transferts, ce qui produit des secondaires vides si l'on oublie la règle.
L'authentification par clé partagée, décrite dans la RFC 8945, apporte une garantie supplémentaire : le transfert n'est accepté que si la requête porte une signature valide. Elle protège aussi les notifications et les mises à jour dynamiques, et se révèle utile dès que les serveurs communiquent par un réseau non maîtrisé. La clé se distribue par un canal séparé, jamais dans le fichier de zone.
Contrôler la réplication au lieu de la supposer
Le contrôle de base tient en une question posée à chaque serveur : quel est le numéro de série du SOA de la zone. Tous doivent renvoyer la même valeur. Un secondaire en retard affiche un série inférieur ; un secondaire sans zone répond par une erreur ou par une délégation, selon la configuration du parent. Ce simple relevé, répété après chaque changement, détecte la majorité des incidents de réplication.
Le second contrôle porte sur la fraîcheur. Un secondaire cesse de répondre pour la zone lorsque la durée d'expiration du SOA est dépassée sans contact avec le primaire : la zone disparaît alors du serveur, et les résolveurs basculent sur les autres. Surveiller le série et l'âge de la dernière copie évite de découvrir cette bascule au moment où elle se produit, c'est-à-dire pendant une panne.
Sources
- https://www.rfc-editor.org/rfc/rfc1995.html
- https://www.rfc-editor.org/rfc/rfc1996.html
- https://www.rfc-editor.org/rfc/rfc5936.html
- https://www.rfc-editor.org/rfc/rfc8499.html
- https://www.rfc-editor.org/rfc/rfc8945.html
- https://bind9.readthedocs.io/en/latest/
Pour vérifier un nom de domaine en direct — racine, TLD, serveurs de noms — utilisez l'outil de test DNS. Demarcq.net assure l'exploitation de serveurs DNS : les prestations d'exploitation.