Résumé

  • Pour RFC 1912, une délégation était boiteuse lorsqu’un serveur figurait dans les NS d’une zone sans lui rendre réellement le service de noms attendu.
  • La publication parente, le consentement du secondaire, le chargement et le rafraîchissement de la zone, la fin des caches et la réponse autoritative relevaient de commandes distinctes.
  • Compter deux noms de serveurs ne prouvait donc pas deux copies opérationnelles : selon le serveur choisi, la panne pouvait rester intermittente et produire trafic inutile, noms introuvables ou courrier rejeté.

Une plaque n’installe pas le service

Le mécanisme de délégation du DNS était volontairement sobre. Au point de coupure entre deux zones, le parent publiait les noms des serveurs de l’enfant. Si l’adresse de l’un d’eux dépendait elle-même de la zone déléguée, des données de glue permettaient d’amorcer le trajet. Le résolveur recevait une direction praticable.

RFC 1034 précisait pourtant l’ordre : les serveurs devaient être installés avant l’ajout, comme dernière étape, des NS et de la glue dans le parent. Les administrateurs des deux côtés de la coupure devaient maintenir ces informations cohérentes. Le parent possédait le pouvoir de publier son renvoi, pas celui de remplir la configuration d’un hôte appartenant à quelqu’un d’autre.

La délégation boiteuse réussissait donc assez pour tromper. Le parent répondait, le nom du serveur existait et l’adresse pouvait être joignable. L’échec n’apparaissait qu’à la requête suivante : le processus distant ne répondait pas comme autorité de la zone enfant.

Ce test sépare plusieurs reçus. Le NS atteste une publication dans le parent. Il n’atteste ni l’accord de l’opérateur distant, ni la création de la zone, ni un transfert réussi, ni la fraîcheur de la copie, ni la réponse autoritative observée maintenant.

Le « secondaire surprise »

En 1993, RFC 1537 décrivait déjà des machines bombardées de requêtes parce que les données d’enregistrement les présentaient comme secondaires. Le responsable du serveur pouvait n’avoir été ni consulté ni même informé. Le document appelait cela la surprise du serveur secondaire.

La formule révèle une erreur institutionnelle minuscule mais complète. Une personne ayant accès au registre pouvait attribuer une charge à un autre domaine opérationnel. La publication déclenchait des conséquences avant que le destinataire n’ait accepté la responsabilité. Le trafic, lui, croyait la plaque.

RFC 1713 aborda le problème par l’enquête : il fallait interroger chaque serveur déclaré et regarder ce qu’il faisait. L’inscription indiquait la cible du test ; elle n’en fournissait pas le résultat.

Publié en février 1996, RFC 1912 reprit ce savoir d’exploitation et remplaça RFC 1537. Le texte était Informational, non une norme Internet. Son exemple classique associait un serveur préparé pour une nouvelle zone fictive à un serveur externe qui ne détenait aucune information sur cette zone, même si le DNS affirmait qu’il devait la servir. Dans le meilleur cas, cette discordance ajoutait du trafic ; dans le pire, elle pouvait empêcher la résolution et faire rejeter du courrier. Le texte n’affirmait pas que chaque requête suivait le pire scénario.

Il rapportait aussi que certains sites ajoutaient le nom de serveurs populaires en espérant qu’ils fourniraient « magiquement » un service supplémentaire. C’est le témoignage d’une pratique, pas la preuve d’un incident nommé, d’une intention universelle ou d’une fréquence mesurée.

Cinq états derrière un seul nom

Un serveur pouvait être nommé dans le parent, joignable au niveau réseau, configuré pour l’enfant, détenteur d’une copie à jour, puis réellement autoritatif dans sa réponse. Le passage entre ces états n’était pas automatique.

Un démon DNS joignable pouvait servir cent autres zones et ignorer celle-ci. Un secondaire correctement installé pouvait perdre ses rafraîchissements puis laisser sa copie expirer. Des ensembles NS identiques dans le parent et l’enfant pouvaient contenir la même erreur. À l’inverse, un serveur encore valable pouvait disparaître du fichier enfant mais continuer d’être choisi à cause d’anciennes données mises en cache.

RFC 2181 clarifia plus tard la géométrie de la coupure : les NS au sommet de l’enfant appartiennent à ses données autoritatives, tandis que le parent porte les données de délégation qui orientent vers le bas. Les noms doivent converger, mais les deux ensembles n’exercent pas la même autorité. RFC 8499 conserva ensuite la distinction terminologique entre le renvoi et le serveur configuré pour répondre.

Comparer les listes restait nécessaire, jamais suffisant. L’audit complet devait atteindre chaque adresse, poser une question sur l’enfant, observer l’indicateur d’autorité et vérifier une donnée de zone plausible sur plusieurs cycles.

La redondance devait se prouver serveur par serveur

Deux NS promettaient une alternative. Ils ne prouvaient pas deux services. Si l’un était boiteux, les résolveurs pouvaient connaître des histoires différentes selon leur choix de serveur, leurs caches, leurs délais et leur logique de reprise. Un test unique pouvait tomber sur le membre sain et masquer la fragilité ; un utilisateur lointain pouvait tomber d’abord sur l’autre.

La disponibilité moyenne cachait alors une erreur de dénominateur. L’ensemble annoncé comptait deux noms, mais l’ensemble autoritatif en comptait peut-être un. Une implantation sur un autre réseau n’apportait aucune indépendance si l’opérateur n’avait pas reçu la zone.

La bonne unité de preuve était chaque membre : accessibilité depuis les réseaux pertinents, configuration, SOA crédible, fraîcheur suffisante et réponse autoritative. La diversité géographique n’était qu’une propriété de noms tant que ces observations manquaient.

Retirer un nom ne retirait pas immédiatement son trafic

Le temps compliquait la réparation. RFC 1912 avertissait que des caches pouvaient continuer à considérer un ancien secondaire comme valide après son déplacement ou son retrait. Le texte recommandait de maintenir le service sur l’ancien hôte pendant la période nécessaire au vieillissement des informations plutôt que de confondre l’heure de l’édition et la fin du trajet.

Le site, son parent et l’hébergeur du secondaire détenaient chacun une partie du changement. Un déplacement du primaire imposait la mise à jour et le rechargement des secondaires. Un déplacement du secondaire imposait de corriger les adresses et les enregistrements aux bons niveaux. Les résolveurs expiraient ensuite des états créés plus tôt.

Il n’existait donc pas un reçu final unique. Publication du parent, rechargement, transfert réussi et dernière disparition d’un cache ancien étaient des événements différents. Revenir sur le NS ne configurait pas le serveur ; remettre le serveur en marche ne purgeait pas tous les caches.

Le registre doit suivre la réalité adoptée

La leçon ne retire aucune valeur au parent. Sans son renvoi, la zone enfant resterait difficile à découvrir. Elle limite seulement la portée de ce pouvoir. Le parent peut dire où l’autorité devrait se trouver. Il ne peut pas, par l’écriture, faire accepter une fonction à un opérateur distant.

À cette échelle, la différence entre le registre et la relation en fonctionnement devient directement observable. Le parent publie. L’enfant maintient ses données. Le secondaire accepte et exécute. Le résolveur choisit localement parmi les chemins. Aucun de ces acteurs ne possède seul l’issue.

Le noyau commun reste mince : format du renvoi, règles de coupure et interopérabilité. La décision future d’héberger la zone devient réelle par adoption opérationnelle. Publier d’abord en espérant que le code et l’opérateur suivront inverse cet ordre.

Une délégation boiteuse est ainsi plus qu’une faute de configuration. C’est une expérience historique sur la différence entre nommer une responsabilité et l’assumer. La réparation exige un accord, une mise en service et une observation, pas seulement une ligne correcte dans un fichier.

Sources