Résumé

  • ISC a présenté à l’APNIC 62 la liste des zones et la détection d’écarts de numéros de série parmi les fonctions DNS actuelles de Stork. Les sources ne décrivent ni déploiement de production d’APNIC ni incident réel de zone obsolète.
  • Un écart renseigne sur les lignes que Stork a effectivement découvertes et collectées. L’absence d’écart ne peut s’étendre à tout un parc sans l’état des collectes, les vues non prises en charge, les exclusions et l’âge du cache.
  • Le résultat devrait voyager avec un reçu de comparaison : versions, périmètre attendu et observé, état de collecte, valeurs SOA brutes, horodatage, durée de validité et traitement des éléments indisponibles.

Le tableau ne peut pas contredire une ligne qu’il n’a jamais reçue

Une console centrale résout un vrai problème DNS. Au lieu de consulter séparément chaque serveur, l’opérateur peut voir qu’un même nom de zone porte des numéros de série différents. Dans les diapositives de Marcin Siodelski à l’APNIC 62, la liste et le filtrage des zones, le visualiseur et la détection d’écarts figurent dans la colonne des fonctions disponibles aujourd’hui. Le compte rendu d’APNIC reprend cette capacité.

La précision de l’écart n’est pas en cause. Son périmètre l’est.

Stork ne connaît pas spontanément tous les serveurs faisant autorité d’une organisation. Un agent doit détecter le démon, retrouver la configuration qu’il utilise, obtenir les accès nécessaires à ses interfaces puis transmettre les informations de zones au serveur Stork. Une zone ou une vue qui ne franchit pas cette chaîne ne produit ni ligne rouge ni ligne verte.

La documentation DNS de Stork 2.4.1 détaille ce point pour BIND 9. L’agent commence par le processus named, recherche son fichier de configuration puis utilise notamment le canal de statistiques pour récupérer les vues et les zones configurées. Si la configuration n’est pas trouvée, le démon n’apparaît pas parmi les démons détectés. Pour PowerDNS, Stork s’appuie sur la configuration et l’API web du serveur.

Une absence peut être parfaitement légitime. Un serveur peut être volontairement exclu du périmètre, une interface peut être désactivée ou un agent peut ne pas être autorisé à lire un secret. Rien ne permet d’appeler cela une panne. Cela interdit seulement de transformer le résultat observé en déclaration sur un ensemble plus large.

La collecte ajoute une seconde limite. La liste affichée par Stork est copiée dans sa propre base. Elle est vide au départ ; l’utilisateur lance Fetch Zones ; puis elle reste en cache jusqu’à la prochaine collecte manuelle. Les erreurs sont visibles sous Fetch Status. Un écran consulté à 16 heures peut donc décrire correctement l’inventaire demandé à 10 heures, sans pour autant décrire les modifications intervenues entre-temps.

L’interface conserve deux nombres qui devraient accompagner toute conclusion. Zone Configs Count compte les configurations, donc plusieurs occurrences lorsqu’un même nom existe dans plusieurs vues. Distinct Zones ne compte ce nom qu’une fois. Leur différence n’est pas un détail d’affichage : elle indique combien de surfaces de configuration peuvent se cacher derrière un seul nom de zone.

Les vues illustrent aussi le problème d’identité. Pour examiner le contenu d’une zone BIND non placée dans la vue par défaut, Stork a besoin d’une clé TSIG permettant à BIND de sélectionner la bonne vue. Les règles match-clients et allow-transfer fournissent cette discrimination. Stork 2.4.1 indique en revanche que les vues apparues dans PowerDNS 5.0 ne sont pas encore prises en charge. Une telle vue absente n’a donc pas « le même numéro » : elle n’appartient pas à l’observation.

Il faut ici séparer deux chemins. La liste des zones et leurs séries provient des interfaces des serveurs et est mise en cache après Fetch Zones. Le contenu détaillé d’une zone est demandé lorsqu’un utilisateur clique sur Show Zone ; Stork utilise alors AXFR et peut réafficher une copie antérieure jusqu’à Refresh from DNS. L’échec d’un AXFR peut empêcher de lire les enregistrements tout en laissant visible un numéro de série déjà recensé. Réciproquement, un numéro visible ne prouve pas que le contenu complet a été transféré.

La surveillance des transferts constitue encore une autre fonction. Le jeu de diapositives place le suivi XFR dans la version de développement 2.5.1. Le manuel de l’agent 2.5.1 précise que ce suivi des journaux BIND est désactivé par défaut, doit être activé explicitement et ne fonctionne pas lorsque les événements ne sont disponibles que dans syslog. La page produit d’ISC classe 2.4.1 comme version stable et 2.5.1 comme version de développement. Un rapport fondé sur 2.4.1 ne peut donc pas s’attribuer silencieusement la visibilité de 2.5.1.

Le nombre SOA lui-même demande de la prudence. RFC 1912 rappelle que le secondaire consulte ce numéro pour savoir si une version plus récente doit être transférée. RFC 1982 définit un espace circulaire sur 32 bits. Deux valeurs inégales ne se classent pas toujours comme de simples entiers ; à exactement la moitié de l’espace, l’ordre n’est pas défini.

Les sources établissent que Stork signale des différences. Elles ne permettent pas d’affirmer comment chaque paire est qualifiée comme « ancienne » ou « nouvelle ». Le reçu doit donc conserver les deux valeurs brutes et, si un ordre est affiché, la règle et le résultat de comparaison. Un écart est un fait. Dire quel serveur est en retard est une interprétation supplémentaire.

Même l’égalité a une portée limitée. Elle ne garantit pas que tous les enregistrements sont identiques, que DNSSEC est valide ou que le service répond comme prévu. D’autres contrôles répondent à ces questions. La question préalable, propre à cette vue Stork, est de savoir si tous les éléments que l’opérateur voulait comparer étaient présents et assez récents.

Un reçu utile resterait court. Il nommerait les versions de Stork, des agents et des démons DNS ; le serveur, la vue et la configuration de zone ; le périmètre attendu et son responsable ; l’heure et l’état de la collecte ; les comptes de configurations et de zones distinctes ; les exclusions et limites de prise en charge ; les séries brutes ; l’heure d’observation et la limite de fraîcheur ; enfin le résultat, la décision d’alerte et toute correction ultérieure.

Ce reçu autorise quatre états honnêtes : complet pour le périmètre déclaré, partiel parce que certaines lignes manquent, périmé parce que le cache est trop ancien, ou non comparable parce que l’inventaire a changé. Un écart reste utile dans un résultat partiel. Une absence d’écart n’acquiert pas, par simple couleur, la portée des lignes qui ne sont pas là.

Cette exigence ne diminue pas Stork. Elle donne au contraire une forme exploitable à son avantage principal : réunir ce qui était dispersé. Le logiciel construit l’ensemble observé. L’opérateur doit encore déclarer l’ensemble attendu. Quand les deux sont réconciliés, le tableau devient une preuve reproductible plutôt qu’une impression de complétude.

Sources