Résumé

  • La RFC 9103 protège le contenu d’AXFR et d’IXFR contre la collecte passive sur une liaison en clair. Elle ne masque ni les relations entre serveurs, ni tous les signaux de volume et de temps, ni l’énumération DNSSEC.
  • Une affirmation XoT vérifiable exige une chaîne de reçus : identité du primaire, autorisation propre à la zone, transfert exclusivement sous TLS, réplique acceptée, cohérence du transfer group et règles de garde chez le secondaire.

L’intrus qui n’avait besoin d’aucun identifiant

Un primaire peut refuser un AXFR aux adresses inconnues et exiger une signature TSIG. Cela bloque un client non autorisé. Cela ne bloque pas l’observateur qui se trouve déjà sur le trajet réseau si la réponse circule en clair. Celui-ci n’a pas à usurper le secondaire ni à casser la clé : il lit les enregistrements pendant leur passage.

La RFC 9103, publiée sur le Standards Track de l’IETF en août 2021, vise précisément cette collecte. Elle spécifie XFR over TLS, ou XoT, pour le transfert complet AXFR comme pour le transfert incrémental IXFR. La valeur du mécanisme est concrète : un flux de réplication peut livrer, en une fois, une cartographie bien plus dense que des requêtes publiques isolées.

Il faut pourtant résister à la formule « la zone est sécurisée ». Le résultat attesté est plus étroit : le contenu du transfert n’est plus lisible par simple surveillance passive de cette liaison. Il reste à savoir si le secondaire a authentifié le bon primaire, si le primaire a autorisé cette requête pour cette zone, si chaque message est resté sous TLS, qui conserve la copie reçue et quelles données restent accessibles par le DNS public.

Cette séparation n’affaiblit pas la norme. Elle rend chaque propriété testable.

TSIG signe un message, TLS protège un canal

La RFC 8945 définit TSIG comme une authentification de transactions DNS fondée sur un secret partagé. La RFC 5936 l’emploie pour autoriser des clients de transfert et protéger l’intégrité. Une authentification de message ne chiffre toutefois pas le message. Un AXFR muni d’un TSIG valide, envoyé sur TCP en clair, peut être authentique et néanmoins parfaitement lisible sur le réseau.

TLS fournit une autre propriété. Pour qu’un transfert soit protégé selon la RFC 9103, le secondaire doit authentifier le serveur primaire selon un profil strict. Le primaire doit, de son côté, valider le droit du client au moyen de TLS mutuel, ou d’une ACL IP combinée à TSIG ou SIG(0). Un profil TLS strict apporte l’authentification du serveur et la confidentialité du canal ; mTLS ajoute l’identité du client ; TSIG apporte l’authentification de l’origine des données. Aucun de ces reçus ne remplace automatiquement les autres.

Une connexion TLS acceptée n’est donc pas une permission générale. Plusieurs zones et plusieurs requêtes peuvent partager une connexion. L’admission se décide souvent par requête, une fois le canal établi. Le port ouvert, la poignée de main réussie et le droit de copier une zone précise sont trois événements.

La politique doit couvrir le groupe, y compris l’exception

La RFC nomme transfer group l’ensemble des primaires et secondaires qui échangent les zones concernées. La confidentialité globale suppose que chaque chemin AXFR et IXFR de ce groupe impose XoT. Un secondaire ancien, une exception de migration ou une liaison non chiffrée derrière un proxy suffit à laisser subsister le point d’observation.

Le mode opportuniste ne donne pas la garantie recherchée. Il peut poursuivre sans identité de serveur correctement établie, voire revenir au clair si TLS est indisponible. Ce comportement peut améliorer une situation ordinaire, mais il ne prouve pas l’interdiction du clair exigée par une politique XoT.

Le reçu doit donc décrire les membres, les méthodes d’authentification, la règle de repli et le lieu exact où TLS se termine. Un proxy qui reçoit du TLS puis parle en clair au primaire coupe le périmètre de confidentialité en deux. Une capture d’une connexion réussie ne révèle pas cette seconde moitié.

Certains contrôles négatifs sont accessibles : tenter un transfert en clair, depuis une adresse interdite ou sans TSIG requis. D’autres le sont moins : confirmer que tous les secondaires rejettent des données non signées, qu’ils utilisent un profil strict, ou qu’un prestataire applique XoT à ses propres pairs. La RFC 9103 laisse la coordination et l’exécution de cette politique hors de son périmètre.

Le canal se ferme, la garde commence

Imaginons une exécution parfaite : identité du primaire validée, client autorisé, TLS 1.3 établi, IXFR reçu et nouveau numéro de série accepté. L’observateur du fil n’a plus le contenu. En revanche, une copie vient d’entrer dans un autre domaine administratif.

Cette copie peut vivre dans un journal, un fichier de zone, une base, une sauvegarde ou un outil de support. Elle peut être transférée à un autre secondaire. Le service autoritaire répondra volontairement aux requêtes publiques prévues. Rien de cela ne constitue une défaillance de TLS ; ce sont des conséquences de garde et de publication après une réplication réussie.

L’identité cryptographique du secondaire ne peut donc être le dernier contrôle. Il faut enregistrer la conservation, les accès locaux, les sauvegardes, les journaux, les destinations ultérieures et le processus de retrait. Révoquer un certificat ou une clé TSIG peut empêcher la prochaine copie, mais ne récupère pas celle qui a déjà été livrée.

ZONEMD trace une autre frontière. La RFC 8976 fournit un condensat pour un objet zone autonome. La RFC 9103 le décrit comme complémentaire et orthogonal à la protection du canal. Un condensat ne cache pas le transfert ; un canal confidentiel ne garantit pas que le contenu de la zone soit exact, actuel ou légitimement approuvé.

Le DNS public conserve ses propres voies

La surveillance d’un transfert et l’énumération d’une zone sont deux voies distinctes. NSEC peut permettre de parcourir une zone signée. NSEC3 hache les noms afin de rendre cette opération plus difficile, sans transformer XoT en dispositif de secret global. Les requêtes autoritaires ordinaires constituent une troisième voie : un enregistrement destiné à être public continuera d’être servi.

La conclusion honnête doit tenir les deux côtés. XoT supprime une collecte en clair, dense et commode. Il ne rend pas invisible la relation entre serveurs, n’efface pas les signaux temporels, n’empêche pas un destinataire autorisé d’abuser de sa copie et ne retire pas les données du service DNS public.

Huit lignes pour un reçu de confidentialité

La première ligne fixe le périmètre : zone, version de politique, transfer group et responsables. La deuxième établit l’identité du primaire : nom d’authentification ou empreinte SPKI, certificat, version TLS et point terminal. La troisième porte l’admission du secondaire : identité mTLS ou ACL IP plus TSIG/SIG(0), décision par zone et essais de refus.

La quatrième décrit le transport : AXoT ou IXoT, interdiction du clair, repli et proxies. La cinquième consigne l’achèvement : série demandée, éventuel passage d’IXFR à AXFR, série acceptée et erreur. La sixième documente la garde de la réplique : stockage, accès, sauvegarde, journalisation et transferts ultérieurs.

La septième recense l’exposition résiduelle : requêtes ordinaires, NSEC/NSEC3, relations d’extrémités, taille et rythme. La huitième définit la revalidation après changement de certificat, clé, ACL, proxy, secondaire, topologie ou politique de signature.

Une poignée de main TLS atteste un canal. TSIG atteste un message. Un transfert terminé atteste une livraison. Aucune de ces preuves, isolément, n’atteste la correction du contenu ni la confidentialité de toutes ses copies.

Sources