Résumé

  • RFC 9432 place dans une zone DNS ordinaire la liste des zones membres et certaines propriétés afin qu’un consommateur puisse les ajouter, les retirer ou les reconfigurer automatiquement. Le catalogue ne transporte pas le contenu faisant autorité de ces zones.
  • La validité de la structure, l’identité du pair de transfert, l’admissibilité locale d’un nom, la propriété de l’état à supprimer et l’application effective par le serveur sont cinq preuves différentes.
  • Un consommateur défend son autonomie en conservant le dernier catalogue valide, en filtrant les membres admissibles indépendamment de TSIG ou de TLS, en reliant chaque état à son catalogue d’origine, en bloquant les suppressions massives et en contrôlant les réponses réellement servies.

Zéro membre, zéro erreur de syntaxe

Le scénario critique ne commence pas par un paquet corrompu. Il commence par un export réussi.

Un système d’inventaire alimente un générateur de catalogue. Une requête en base ne renvoie plus aucun client à cause d’un droit expiré, d’un nouveau filtre ou d’une mauvaise valeur d’état. Le générateur augmente le numéro de série SOA et publie une zone parfaitement formée : un SOA, un NS, la propriété version égale à 2, aucun enregistrement membre invalide. Le transfert IXFR est authentifié et s’achève sans perte.

Pour le parseur, il n’existe aucune faute. Pour l’exploitation, la proposition signifie : retirer toutes les zones membres.

RFC 9432 avertit expressément qu’un script produisant un catalogue vide peut supprimer des millions de zones de serveurs secondaires en quelques secondes. L’accident n’est pas extérieur à l’automatisation ; il utilise exactement le chemin rapide conçu pour son efficacité.

La bonne question d’audit n’est donc pas « le catalogue est-il valide ? », mais « quelle autorité transforme cette validité en suppression ? » Une réponse binaire sur la structure est nécessaire. Elle ne couvre pas l’intention.

Le catalogue décrit le parc, pas les données des zones

Une DNS Catalog Zone reste une zone DNS normale à laquelle le consommateur attribue une sémantique particulière. Des PTR situés sous zones désignent les membres. Un libellé unique rattache au membre des propriétés comme group ou coo. Les enregistrements A, AAAA, MX, NS et DNSSEC de la zone membre suivent, eux, le transfert ordinaire depuis ses primaires.

Cette dissociation crée deux chaînes de preuve. La première décide qu’une zone doit exister dans la configuration du secondaire. La seconde apporte le contenu que ce secondaire devra servir. Un membre peut être admis sans que son transfert aboutisse. Un membre peut disparaître de la configuration d’un nœud tandis qu’un autre conserve une copie. Un NOTIFY peut même arriver avant que le catalogue ait présenté le membre.

Un tableau de bord limité au dernier numéro de série du catalogue masque ces écarts. Il faut suivre l’objet reçu, la décision locale, la configuration active, le transfert du membre, son chargement et enfin les réponses faisant autorité depuis les points de présence concernés.

Cinq preuves à ne jamais fondre

La première preuve concerne la structure. La version 2 exige une seule valeur TXT attendue. Un ensemble PTR membre ne peut contenir qu’un enregistrement, et deux libellés ne peuvent pas pointer vers la même zone. Une propriété connue mais mal formée rend le catalogue cassé. Un élément non pris en charge doit être ignoré, pas interprété librement.

La deuxième concerne la provenance du transfert. TSIG authentifie des transactions DNS ; un transfert de zone sous TLS peut protéger le canal et sa confidentialité. Ces mécanismes permettent d’identifier le pair configuré et de détecter une modification inattendue. Ils n’observent pas le système d’inventaire qui a décidé que la liste devait être vide.

La troisième est l’admission locale. RFC 9432 indique que le contrôle administratif des zones servies passe au producteur du catalogue, puis recommande au consommateur de limiter les membres acceptables, par exemple avec une expression régulière ou une vérification dans une autre base. L’authentification répond « de qui vient ce message ? » ; le filtre répond « ce producteur peut-il configurer ce nom ici ? »

La quatrième est la propriété de l’état. Un catalogue ne peut effacer que l’état d’une zone qu’il a initialement provisionnée. Le consommateur doit donc conserver l’origine de chaque membre, et pas seulement son nom actuel.

La cinquième est la conséquence en exécution. Une configuration enregistrée n’est pas encore une zone chargée. Une zone chargée n’est pas forcément servie partout. La preuve finale se trouve dans le processus en cours et dans les réponses DNS observées.

Le catalogue cassé et le catalogue dangereux

La norme traite solidement le premier cas. Si la version manque, si deux PTR se contredisent ou si une propriété connue viole sa forme, le consommateur ne doit pas traiter l’objet comme un catalogue. Si une version auparavant correcte devient cassée, les membres du dernier état valide ne doivent être ni retirés ni reconfigurés. Après un redémarrage, le serveur devrait continuer à les servir.

Cette continuité protège contre une entrée illisible. Elle ne protège pas contre une entrée lisible mais aberrante. Un catalogue vide reste conforme. De même, la suppression de 90 % des membres peut être formellement valide.

Il faut donc ajouter une analyse du changement : nombre et proportion de retraits, suffixes nouveaux, partitions de clients touchées, propriétés qui apparaissent, heure de maintenance, identité du générateur et comparaison avec l’inventaire indépendant. Une proposition vide ou massivement destructive doit s’arrêter dans une zone de quarantaine, même si le transfert et le schéma sont verts.

Ce refus n’altère pas RFC 9432. Il exerce la décision locale que la norme laisse précisément au consommateur.

Supprimer seulement ce que ce catalogue a créé

La règle de retrait donne une assise concrète à la provenance. Quand un membre disparaît d’un catalogue donné, le consommateur ne doit pas supprimer la zone ni son état associé si cette zone n’a pas été initialement configurée par ce même catalogue. Si l’origine correspond, l’état peut comprendre les données de zone et les clés DNSSEC. La norme suggère d’envisager un archivage temporaire pour réparer une erreur.

Une simple table « zone active / inactive » ne suffit pas. Le registre local doit mémoriser le catalogue d’origine, le libellé du nœud membre, le premier numéro de série accepté, le profil de configuration appliqué, les magasins d’état créés et les changements ultérieurs.

L’archivage lui-même comporte une décision. Une rétention infinie de clés et de journaux augmente le risque de confidentialité et de garde. Une purge immédiate rend une erreur de catalogue irréversible. Il faut fixer une durée, un propriétaire, une procédure de restauration et un test permettant de réconcilier l’état restauré avec les modifications autoritatives intervenues pendant l’absence.

Renvoyer l’ancien catalogue ne constitue pas toujours un retour arrière. Si le logiciel a déjà purgé le fichier, le journal, les minuteries ou les clés, le PTR réintroduit peut créer un nouveau membre au lieu de ressusciter l’ancien.

Le libellé opaque qui transfère la garde

Le libellé unique placé sous zones n’a pas de sens descriptif. Pourtant, le changer ordonne une suppression suivie d’un nouvel ajout et remet à zéro l’état associé. Une différence qui ressemble à un identifiant technique peut donc emporter des clés ou un historique de transfert.

La propriété coo organise le changement de propriétaire entre deux catalogues. L’ancien catalogue nomme le nouveau. Le consommateur attend que le membre apparaisse également chez le nouveau producteur, puis vérifie que l’ancien signal existe toujours avant de migrer.

Si le nouveau catalogue conserve le même libellé, l’état associé peut suivre la zone. Cette continuité est utile lorsqu’elle est voulue. Elle devient une prise de garde silencieuse lorsqu’elle ne l’est pas. L’ancien producteur doit modifier le libellé et provoquer une remise à zéro avant ou en même temps que coo s’il ne veut pas transmettre l’état.

Une décision « migrer la zone » est ainsi trop vague. Il faut nommer le sort des données, journaux, clés, minuteries et métadonnées propres au produit. Dans ce protocole, l’opacité du libellé ne réduit pas son pouvoir.

Groupes, extensions et accords locaux

group permet d’indiquer qu’un membre recevra un traitement différent. La chaîne n’a pas de sens universel. Chaque consommateur associe les valeurs reconnues à ses propres profils, ignore celles qu’il ne comprend pas et décide comment traiter plusieurs valeurs.

Les propriétés placées sous ext sont encore plus locales. Leur signification dépend de l’implémentation et aucune interopérabilité générale n’est promise. Le registre IANA pour la version 2 coordonne zones, version, coo, group et l’espace privé *.ext. Il ne transforme pas une extension privée en ordre mondial.

On retrouve ici la spécification initiale minimale défendue par Heng Lu : un noyau déterministe et vérifiable, puis des décisions futures localisées. La publication d’un mot ne lui confère pas de pouvoir. L’adoption se constate lorsqu’un consommateur réel l’interprète, l’applique et demeure compatible avec ses contreparties.

Ce que montrent BIND, Knot DNS et PowerDNS

La documentation actuelle de BIND décrit l’ajout, le retrait et la reconfiguration automatiques, les versions 1 et 2, la remise à zéro par changement de libellé et coo. Un intervalle minimal peut ralentir les mises à jour ; il ne décide pas si elles sont légitimes.

Knot DNS relie les groupes à des profils locaux et précise qu’un membre retiré du catalogue est purgé immédiatement, y compris son fichier de zone, son journal, ses minuteries et ses clés DNSSEC, sous réserve de l’exception documentée pour le fichier. Sa mise à jour peut aussi provoquer un rechargement plus large. Un diff de catalogue devient donc un événement de stockage et de processus.

PowerDNS documente les rôles producteur et consommateur pour la version 2, ainsi que coo, group et la valeur unique servant à demander une remise à zéro. Les fonctions et magasins pris en charge ne sont pas identiques à ceux des autres produits.

Dire « nos serveurs prennent en charge RFC 9432 » reste une affirmation symbolique. La réalité exige une matrice par version : persistance, retrait, redémarrage, groupes, extensions, migration, remise à zéro, archivage et retour arrière. La primauté du code en exécution commence là où cesse la brochure de fonction.

Le journal d’autorité

Pour chaque numéro de série accepté, conserver le hachage du contenu, le diff normalisé, le pair authentifié, la méthode de transport, le verdict structurel, la règle d’admission et sa version, l’origine et le libellé de chaque membre, les conflits, le résultat d’application par consommateur, puis le transfert, le chargement et les sondes DNS du membre.

Pour un retrait, ajouter l’inventaire d’état, l’identifiant d’archive et l’échéance de restauration. Pour coo, conserver les observations des deux catalogues, la continuité ou le changement de libellé et la décision explicite sur la garde. Les secrets et le contenu complet d’un catalogue sensible n’ont pas leur place dans les journaux ordinaires.

Ce registre doit répondre sans hypothèse : qu’a publié le producteur ? qui a authentifié le transfert ? qu’a admis le consommateur ? quel état appartenait au catalogue ? qu’a exécuté le logiciel ? que pouvaient résoudre les clients ?

Sources