Résumé

  • La recommandation de trois serveurs listés n’avait de sens que si au moins l’un d’eux était éloigné des autres sur les plans géographique et topologique.
  • Une adresse publiée mais inaccessible oblige les résolveurs à sonder, attendre et réessayer ; elle peut donc dégrader le service qu’elle était censée renforcer.
  • Un nom NS, une réponse faisant autorité, un numéro de série SOA ou un transfert achevé sont des preuves de portée différente, jamais une garantie globale de fraîcheur et de disponibilité.

La diversité visible et la dépendance cachée

RFC 2182, devenu BCP 16 en juillet 1997, part d’une finalité concrète : les données d’une zone doivent rester accessibles quand un serveur ne l’est plus. Le texte ne confond donc pas réplication et résilience. Trois processus peuvent être actifs et pourtant disparaître lors de la même coupure.

La séparation géographique protège contre la panne d’un local, d’un bâtiment ou de son alimentation. La séparation topologique protège contre la perte d’un lien, d’un segment de routage ou d’un opérateur. L’une ne remplace pas l’autre. Deux salles lointaines peuvent dépendre du même chemin ; deux réseaux commerciaux peuvent aboutir dans la même installation.

Le chiffre trois était une recommandation pratique, pas un seuil magique. Deux serveurs bien placés suffisent parfois, mais l’indisponibilité prolongée de l’un laisse une zone sans marge. Pour la plupart des zones d’organisation, le document conseille trois serveurs listés, dont au moins un nettement séparé. Quatre ou cinq peuvent être justifiés par une exigence supérieure. Au-delà, les coûts et les erreurs possibles augmentent plus vite que le bénéfice.

Une mauvaise adresse distribue l’attente

Un serveur n’apporte rien s’il n’est joignable que depuis le réseau de son administrateur. Le nom publié dans un enregistrement NS doit mener à des adresses accessibles depuis la région où l’information est fournie, y compris par les résolveurs auxquels cette information peut ensuite être transmise.

Pour constater l’échec, chaque résolveur doit essayer. L’absence de réponse peut être une panne durable ou une perte de paquet ; il faut attendre le délai, parfois recommencer, puis refaire l’expérience plus tard. Pendant ce temps, le logiciel appelant peut abandonner. L’adresse inutilisable transforme ainsi une infrastructure partiellement disponible en panne apparente.

Le texte de 1997 affirmait trop largement qu’une absence de résultat n’était pas mise en cache. L’erratum éditorial 4631, conservé pour une future mise à jour, tient compte de RFC 2308 : les réponses négatives peuvent être mémorisées selon le serveur et sa configuration. Cette correction historique ne sauve pas une adresse injoignable. Les sondes, délais et nouvelles tentatives restent un coût imposé à l’extérieur.

La cohérence des RRsets empêchait également un bricolage commode. Toutes les adresses d’un serveur devaient être renvoyées ensemble ; on ne pouvait pas masquer sélectivement l’adresse défectueuse ni lui attribuer un TTL spécial. Lorsque les mondes interne et externe n’avaient pas la même joignabilité, la réponse était une conception DNS distincte pour chaque vue, pas une liste universelle trompeuse.

Le coût de la copie supplémentaire

Multiplier les serveurs agrandit les paquets et rapproche les réponses des limites de taille. Surtout, chaque copie ajoute une configuration, une relation de transfert, une version logicielle et un responsable susceptibles de dériver. Une panne non détectée devient plus probable à mesure que l’inventaire s’étend.

RFC 2182 distingue utilement les serveurs listés des serveurs furtifs. Des copies locales non publiées peuvent répondre aux utilisateurs du site lorsque la liaison extérieure tombe. Les annoncer toutes au monde entier contraindrait les résolveurs externes à interroger chaque machine derrière une même coupure. Une capacité locale n’est pas forcément une promesse publique.

La redondance vieillit avec la zone

Le numéro de série SOA donne au secondaire la raison de rafraîchir sa copie. Il doit progresser à chaque modification. S’il a été porté accidentellement trop haut, le ramener brutalement à une valeur plus petite ne constitue pas une correction : les secondaires ayant vu la grande valeur peuvent ignorer la nouvelle.

La procédure décrite avance par étapes compatibles avec l’arithmétique de RFC 1982. Après chaque valeur, l’opérateur attend que tous les secondaires concernés l’aient adoptée, puis seulement poursuit jusqu’au passage par le bouclage. Le mot important est « vérifier ». La correction n’est pas atomique ; elle réussit parce que chaque état intermédiaire est observé.

Cette séquence interdit de confondre les preuves. L’enregistrement NS atteste une annonce. Une réponse atteste qu’un processus a répondu. Le SOA montre le numéro observé depuis un point. Un transfert atteste une session achevée. Aucun de ces faits ne démontre seul que tous les enregistrements sont identiques, que tous les processus servent la nouvelle copie, que les infrastructures sont indépendantes ou que l’application finale fonctionne.

La section sécurité ne promettait rien de plus : le document ne prétend ni résoudre ni aggraver les problèmes de sécurité du DNS, mais rappelle qu’un secondaire compromis peut menacer les hôtes de la zone. La diversité opérationnelle doit donc préserver aussi la confiance.

La leçon de RFC 2182 est simple et sévère. La délégation rend l’autorité visible. La disponibilité exige des preuves supplémentaires : ce qui peut tomber ensemble, qui peut atteindre chaque adresse et quelle version est réellement servie.

Sources

  1. RFC 2182 — Selection and Operation of Secondary DNS Servers
  2. Fiche RFC 2182
  3. RFC 1982 — Serial Number Arithmetic
  4. RFC 2181 — Clarifications to the DNS Specification
  5. RFC 2308 — Negative Caching of DNS Queries
  6. Errata de RFC 2182