Résumé

  • Publié comme BCP 16 en juillet 1997, le RFC 2182 traite le placement des serveurs DNS comme un problème de fiabilité opérationnelle.
  • Sa recommandation de trois serveurs pour la plupart des zones d’organisation exige qu’au moins l’un d’eux soit nettement éloigné des autres.
  • Cette recommandation ne prouve pas que les serveurs publiés partagent des chemins, alimentations ou opérateurs indépendants.

Une zone pouvait publier trois serveurs de noms et n’offrir qu’un seul chemin pratique vers une réponse. Si les trois dépendaient de la même liaison, du même bâtiment ou de la même alimentation, une seule panne pouvait les rendre injoignables. Le compte indiquait une redondance ; les dépendances, elles, restaient communes.

C’est le problème d’exploitation auquel Robert Elz, Randy Bush, Scott Bradner et Michael Patton ont consacré le RFC 2182, « Selection and Operation of Secondary DNS Servers ». L’IETF l’a publié en juillet 1997 comme Best Current Practice 16. Il ne créait pas un nouveau protocole DNS. Il cherchait à faire fonctionner la redondance déjà prévue par le système dans les conditions réelles du réseau.

Le DNS exigeait déjà plusieurs serveurs faisant autorité pour une zone déléguée. Le RFC distinguait deux rôles souvent confondus. Le primaire détient les données de zone configurées localement ; le secondaire les obtient du primaire par transfert. Mais un résolveur et la zone parente ne classent pas les réponses selon cette distinction. Pour le reste du DNS, il s’agit simplement de plusieurs serveurs faisant autorité publiés. Un secondaire n’aide que si les clients peuvent l’atteindre lorsque les autres serveurs — ou leur infrastructure commune — ne répondent plus.

Les auteurs partaient de problèmes qu’ils disaient déjà constater : de mauvais choix de serveurs secondaires. La répartition géographique et la diversité des connexions réseau pouvaient améliorer fiabilité et performances. Installer tous les serveurs sur le même site était explicitement déconseillé. Une panne de liaison, de site, de bâtiment, de salle ou d’alimentation pouvait les couper ensemble. Le but n’était pas de supposer qu’un serveur éloigné est forcément sûr, mais d’identifier les pannes susceptibles d’en emporter plusieurs à la fois.

Le RFC 2182 recommandait trois serveurs pour la plupart des zones d’organisation, dont au moins un nettement éloigné des autres. Quatre ou cinq pouvaient se justifier pour une fiabilité supérieure. Ajouter toujours plus de serveurs n’était pas nécessairement mieux : les ensembles NS plus grands augmentaient la taille des paquets DNS et les occasions de laisser passer une erreur de configuration. Le nombre servait de repère dans un raisonnement de placement, pas de seuil universel de conformité.

Cette recommandation posait une question pratique : qui hébergerait la copie distante ? Le RFC décrivait des organisations de taille comparable qui se fournissaient mutuellement un service secondaire. Les données de zone échangées étant déjà accessibles au public, cette coopération ne révélait pas de données confidentielles. Elle répartissait la redondance entre opérateurs, mais imposait de maintenir les transferts, les numéros de série et l’accessibilité.

Le BCP ne mesurait ni le respect de ses recommandations ni la survie d’un déploiement particulier à une panne. Une liste NS ne prouve pas que deux hébergeurs ont des transitaires différents, que leurs salles ne partagent pas d’alimentation, ni que leurs routes resteront indépendantes sous contrainte. « Trois serveurs » est donc une preuve de nombre, pas un audit des chemins de défaillance.

Le document de 1997 contient aussi une phrase sur les réponses DNS négatives qui a vieilli. Il affirmait que les résultats négatifs n’étaient généralement pas mis en cache. RFC 2308 a normalisé la mise en cache négative l’année suivante et l’erratum 4631 du RFC Editor a ensuite signalé l’inexactitude de cette généralisation. Même une bonne pratique opérationnelle a une date et une histoire de maintenance.

L’idée durable du RFC 2182 est plus précise qu’un chiffre magique : la redondance dépend des dépendances. Un troisième serveur compte lorsqu’il change les éléments capables de tomber ensemble.

Sources