Mettre en place un DNS secondaire : intérêt, limites et bonnes pratiques
Ajouter un serveur DNS secondaire est souvent présenté comme la solution de disponibilité. C'est vrai pour la panne d'une machine, faux pour une erreur de contenu, et cela impose des choix de placement réseau et d'exploitation qui décident de l'efficacité réelle du dispositif.
Ce qu'un secondaire protège, et ce qu'il ne protège pas
Un serveur secondaire maintient une copie de la zone et répond aux résolveurs lorsque le primaire est indisponible : panne matérielle, maintenance, coupure réseau, saturation. La résolution continue, avec un contenu légèrement daté mais cohérent. C'est exactement le service attendu, et il justifie à lui seul la mise en place d'au moins un secondaire sur toute zone qui compte.
En revanche, un secondaire ne protège ni d'une erreur de saisie, ni d'une suppression accidentelle, ni d'une compromission du primaire : il réplique fidèlement ce qu'il reçoit, y compris la faute. Il ne protège pas non plus d'une panne de l'hébergeur commun aux deux machines, ni d'une erreur de délégation chez le parent. Confondre ces cas conduit à des dispositifs rassurants sur le papier et inopérants le jour de l'incident.
Les recommandations de la RFC 2182
Le document BCP 16, publié comme RFC 2182, traite de la sélection et de l'exploitation des serveurs secondaires. Il recommande plusieurs serveurs secondaires répartis sur des réseaux distincts, une source d'écriture unique, et met en garde contre les configurations où tous les serveurs dépendent d'une même infrastructure. Ces recommandations restent la référence opérationnelle, près de trois décennies après leur publication.
Le texte insiste aussi sur le fait qu'un serveur secondaire doit être exploité avec le même sérieux qu'un primaire : supervision, mises à jour de sécurité, contrôle de la fraîcheur de la copie. Un secondaire oublié, resté sur une version ancienne du logiciel et sans surveillance, devient une cible plus qu'une protection, tout en étant cité dans la délégation.
Placement réseau : la panne commune est la vraie menace
Deux machines dans la même salle, alimentées par la même source et reliées au même commutateur, ne constituent pas une redondance : elles tombent ensemble. Le placement doit viser la séparation des causes de panne, qu'il s'agisse de l'alimentation, du réseau, de l'opérateur ou du fournisseur d'hébergement. Un secondaire chez un autre hébergeur, dans une autre région, apporte davantage qu'un troisième serveur dans la même baie.
La diffusion anycast, qui consiste à annoncer la même adresse depuis plusieurs points du réseau, répond à un autre besoin : la répartition de charge et la résistance à certaines attaques volumétriques. Elle ne remplace pas la séparation des sources d'écriture, et elle complique le diagnostic, puisqu'une même adresse peut être servie par des machines différentes selon l'endroit d'où l'on interroge.
Ce que la réplication coûte
Chaque secondaire multiplie les transferts et la charge de lecture sur le primaire. Sur une zone modifiée rarement, le coût est négligeable ; sur une zone à jour fréquente, la multiplication des copies peut saturer le lien du primaire, surtout si les transferts retombent en mode complet. Le nombre de secondaires se décide donc avec le volume de la zone et la fréquence des changements en tête, pas seulement avec la volonté de rassurer.
La réplication impose aussi une discipline de série. Un primaire dont le numéro de série n'augmente pas laisse ses secondaires sur une version antérieure, sans message d'erreur : la seule trace est un écart de série, visible uniquement si on le mesure. C'est la raison pour laquelle le relevé du série sur chaque serveur fait partie des contrôles courants d'un hébergement de zone.
Points d'exploitation à surveiller
Quatre signaux suffisent à couvrir l'essentiel : le numéro de série identique partout, l'âge de la dernière copie restant sous la durée d'expiration, l'absence d'échec de transfert dans les journaux, et la disponibilité du primaire vue par chaque secondaire. Ces mesures se collectent sans outil sophistiqué, à partir des réponses du serveur lui-même.
Il faut y ajouter la cohérence des adresses de colle chez le parent. Lorsqu'un serveur change d'adresse, la zone enfant peut être parfaitement à jour alors que la zone parente pointe encore l'ancienne adresse : le serveur devient alors introuvable pour les résolveurs, alors qu'il fonctionne. Ce cas se produit à chaque migration mal terminée, et la vérification se fait chez le parent, pas sur la machine.
Un secondaire se justifie par un scénario écrit
Avant d'ajouter une machine, il vaut mieux écrire le scénario qu'elle couvre : quelle panne, pendant combien de temps, avec quel impact pour les utilisateurs, et comment le service est rétabli. Cette phrase, souvent absente des projets, distingue une redondance utile d'une accumulation de serveurs dont personne ne connaît l'état.
Lorsque la zone est critique, la question dépasse le nombre de copies : elle touche à la procédure de restauration, à la détention des accès, et à la personne capable de reprendre la main. Un secondaire bien placé ne remplace pas cette préparation, il la prolonge.
Sources
- https://www.rfc-editor.org/rfc/rfc2182.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
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.