Résumé

  • La zone catalogue ne décrit pas seulement un parc : son interprétation peut créer, modifier ou supprimer la configuration de zones membres sur les serveurs consommateurs.
  • Une transmission authentifiée atteste l'origine d'une génération, pas la justesse de sa liste ; l'exploitation sûre conserve donc un contrôle local, une trace de l'état et une preuve depuis la source jusqu'aux réponses autoritatives.

Supposons un matin qu'un générateur publie une nouvelle zone catalogue. Le SOA est présent, le numéro de série a progressé, l'enregistrement NS requis existe et version.$CATZ contient exactement la valeur 2. Le transfert arrive par un canal authentifié. Aucun enregistrement PTR membre n'est mal formé : il n'y en a aucun.

Le catalogue est vide.

Cette génération n'est pas cassée au sens de RFC 9432. Elle est parfaitement lisible et signifie que tous les membres ont été retirés. Pour les zones initialement configurées depuis ce catalogue, le consommateur doit alors retirer la zone et l'état associé. Le RFC avertit lui-même qu'un script produisant accidentellement un catalogue vide pourrait faire supprimer des millions de zones secondaires en quelques secondes. Il s'agit d'un scénario de norme, pas d'un incident attribué.

La leçon tient en une distinction : l'authenticité du message ne garantit pas la vérité de l'inventaire qui l'a produit.

Un plan de configuration transporté comme une zone

AXFR et IXFR synchronisent le contenu d'une zone déjà connue. Ils ne synchronisent pas automatiquement la liste des zones qu'un serveur doit prendre en charge. Historiquement, l'ajout d'une zone demandait donc une opération sur le primaire et d'autres opérations de configuration sur les secondaires.

RFC 9432 encode cette liste dans une zone DNS ordinaire à structure spéciale. Chaque membre apparaît dans la donnée d'un PTR placé sous un identifiant unique. Après transfert, un consommateur compatible peut créer la configuration correspondante, récupérer les données de la zone membre et commencer à servir. Le retrait emprunte le chemin inverse.

Le catalogue est ainsi au-dessus du contenu. La zone membre répond à la question « quelles données publier pour ce nom ? ». Le catalogue répond d'abord à « ce serveur doit-il devenir autoritatif pour cette zone ? ». Un même mécanisme de transport ne doit pas effacer cette différence d'autorité.

Le texte normatif est exceptionnellement explicite : le contrôle administratif des zones servies passe de l'opérateur consommateur au propriétaire du contenu catalogue. Mais ce transfert n'est pas illimité. Le consommateur devrait borner les noms admissibles, par expression, liste indépendante ou vérification dans sa propre base. Le producteur apporte une proposition exécutable ; le consommateur conserve le droit de déterminer le périmètre où elle peut agir.

Un catalogue cassé ne vaut pas un catalogue vide

La syntaxe crée des refus déterministes. Une version absente, multiple ou non prise en charge rend le catalogue inutilisable. Deux identifiants pointant vers la même zone, plusieurs PTR dans le même RRset ou une propriété connue de forme impossible produisent aussi un catalogue cassé. Le consommateur ne doit pas interpréter cette génération.

Le comportement de repli est essentiel. Lorsqu'un catalogue jusque-là correct devient cassé, ses membres déjà configurés ne sont ni supprimés ni reconfigurés. Même après redémarrage, le serveur devrait continuer à servir le dernier état valable. L'expiration suspend également l'interprétation sans inventer une suppression générale.

Cette règle protège l'exploitation contre une absence de sens. Elle ne protège pas automatiquement contre un sens valable mais absurde. Un catalogue vide, une suppression massive ou un membre extérieur au portefeuille contractuel peuvent tous être syntaxiquement corrects. Il faut donc trois verdicts séparés : structure, provenance du canal et admissibilité opérationnelle.

Un contrôle unique marqué « valide » ne peut pas répondre aux trois questions suivantes :

  1. Le document respecte-t-il RFC 9432 ?
  2. Vient-il du producteur et du canal attendus ?
  3. Cette modification précise est-elle autorisée, proportionnée et récupérable pour ce consommateur ?

La troisième décision n'appartient ni au PTR ni à TSIG.

L'identifiant opaque porte pourtant l'état

L'étiquette unique placée sous zones.$CATZ ne décrit ni le client ni la propriété juridique. Elle sert seulement à identifier une entrée. Pourtant, sa stabilité possède un effet majeur : un changement d'étiquette est traité comme une suppression suivie d'un nouvel ajout. Les données transférées, les clés DNSSEC et d'autres états associés peuvent être éliminés puis recréés.

La propriété coo organise un changement de catalogue. L'ancien catalogue désigne le nouveau ; le consommateur attend que le membre apparaisse dans la cible et vérifie encore l'autorisation de départ avant de migrer. Conserver la même étiquette peut permettre la reprise de l'état. La modifier impose une remise à zéro.

Une revue de changement ne peut donc pas se limiter à « une ligne a bougé ». Elle doit expliquer le catalogue d'origine, l'identifiant avant et après, les propriétés transmises et le sort attendu des clés, journaux, minuteries et données locales.

Sans prise en charge commune de coo, le retrait puis l'ajout dans deux catalogues peut arriver dans le mauvais ordre. Le nouveau catalogue atteint un consommateur avant que l'ancien retrait ne soit visible ; le nom entre en collision et l'ajout est ignoré. RFC 9432 laisse la récupération hors de son champ. L'opérateur doit alors prouver l'ordre, forcer au besoin un nouveau transfert et vérifier le service.

Un format commun, des effets locaux

Les groupes ne constituent pas une politique universelle. Leur sens résulte d'un accord entre producteur et consommateur. Une valeur inconnue est ignorée ; plusieurs valeurs peuvent être traitées en totalité, en partie ou pas du tout. Les propriétés privées sous *.ext n'offrent aucune promesse d'interopérabilité.

La documentation des logiciels le confirme. BIND applique les catalogues par vue et propose un intervalle minimal entre mises à jour. PowerDNS documente des contraintes de backend et une prise en charge limitée de certaines fonctions de groupe ou d'extension. Knot DNS décrit des modèles locaux, une validation externe, une purge immédiate de l'état décatalogué dans sa mise en œuvre actuelle et des limites de migration.

Ces différences ne sont pas des défauts du RFC. Elles matérialisent la décision locale qu'il laisse volontairement ouverte. En revanche, elles rendent insuffisante la phrase « les serveurs ont reçu le même catalogue ». Il faut connaître version, options, modèle, persistance, propriété prise en charge et résultat configuré sur chaque cohorte.

Protéger le transport sans sacraliser le contenu

RFC 9432 recommande l'authentification des transferts de catalogue, des mises à jour et des transferts des zones membres. TSIG assure l'authenticité et l'intégrité entre acteurs partageant une clé. XFR sur TLS peut ajouter confidentialité et authentification d'extrémité. La confidentialité importe : un catalogue peut révéler le portefeuille de zones d'un opérateur et ses propriétés de traitement.

Mais la cryptographie ne remonte pas jusqu'à la requête qui a alimenté le générateur. Elle ne sait pas qu'une jointure a renvoyé zéro ligne, qu'un filtre de résiliation a sélectionné tous les clients ou qu'une migration a perdu ses identifiants stables. Un canal sûr peut transmettre fidèlement une décision erronée.

Le dossier probant commence donc par l'instantané autorisé de l'inventaire, le changement approuvé, la version et l'entrée du générateur, le nombre attendu et le hachage de sortie. Il conserve ensuite le numéro de série, le diff sémantique, les étiquettes, les propriétés et l'identité de transfert. Enfin, il vérifie la liste réellement configurée, les transferts des membres, le SOA chargé, les clés concernées et les réponses directes de chaque site autoritatif.

La délégation parente reste indépendante. Retirer une zone d'un secondaire ne retire pas les NS du parent ; le parent peut continuer à envoyer les requêtes vers un serveur qui ne répond plus pour cette zone. Le succès d'un catalogue n'est donc jamais, à lui seul, une preuve de service.

Sources