Résumé

  • Pour un consommateur compatible RFC 9432, l’appartenance au catalogue est une commande de configuration, pas un simple inventaire.
  • L’authentification du transfert ne remplace ni la limitation des zones admissibles, ni la décision explicite sur l’état transmis lors d’un changement de propriétaire.

Une liste qui configure le service

Le transfert DNS classique synchronise le contenu d’une zone, mais pas la liste entière des zones qu’un secondaire doit servir. La RFC 9432 représente cette liste dans une zone DNS ordinaire. Le producteur y publie des enregistrements PTR et des propriétés; le consommateur transfère le catalogue puis adapte sa configuration.

Le gain est réel: moins d’opérations répétitives et moins de dépendance aux interfaces propres à chaque logiciel. En contrepartie, la norme indique que le contrôle administratif des zones servies passe de l’opérateur du consommateur au producteur. Celui-ci peut provoquer l’ajout, la suppression ou la modification d’un service dans tout le parc.

La norme refuse cependant de donner un sens de commande à un catalogue cassé. Une version obligatoire absente ou inconnue, des membres dupliqués ou une propriété connue invalide empêchent son traitement. Si un catalogue auparavant valide devient cassé, les membres déjà configurés ne doivent pas être supprimés ni reconfigurés. Le dernier état valide reste la référence.

Cette protection ne couvre pas un catalogue vide mais valide. Celui-ci peut ordonner la suppression des zones qu’il avait lui-même installées. Une vérification syntaxique doit donc être précédée d’un contrôle métier: le nombre et l’identité des membres correspondent-ils à l’inventaire approuvé?

Changer de catalogue, transmettre un état

La propriété coo organise le passage d’une zone membre vers un autre catalogue. Le consommateur attend que la zone apparaisse dans la cible et vérifie de nouveau l’instruction de l’ancien catalogue. Si le même libellé de membre est conservé, le nouveau propriétaire peut reprendre l’état associé; un nouveau libellé impose sa réinitialisation.

Le pouvoir porte alors sur davantage qu’un nom. Données de zone, clés DNSSEC et propriétés opérationnelles peuvent être concernés. Le responsable de la migration doit documenter les deux catalogues, le libellé, l’approbateur, l’état à conserver et la preuve que les deux côtés étaient cohérents.

Canal sûr, intention encore à vérifier

La RFC 9432 recommande l’authentification des transferts et mises à jour. TSIG, défini par la RFC 8945, authentifie les messages DNS. La RFC 9103 permet le transfert de zone sur TLS et protège la confidentialité. Les secrets TSIG ne doivent pas figurer dans le catalogue.

Un message authentifié peut néanmoins exprimer une mauvaise intention opérationnelle. Le consommateur devrait donc limiter les zones admissibles, par exemple en les comparant à un inventaire indépendant. La confidentialité importe aussi: le catalogue révèle les zones servies et leurs propriétés de gestion.

Les sources établissent ces mécanismes, pas leur taux d’adoption ni l’existence d’un incident chez un opérateur nommé. Les bénéficiaires sont les équipes DNS et leurs clients; le coût est la concentration du pouvoir et du rayon d’impact. Le contrefactuel, la configuration manuelle de chaque serveur, est plus lente mais diffuse davantage le risque.

Sources