Résumé

  • Le RFC 9704 distingue la déclaration de sous-domaines remise localement au client du jeton de vérification publié par la zone parente. La liste privée n’a pas à devenir un annuaire public pour que l’autorisation puisse être contrôlée.
  • Le nom d’authentification du résolveur reste visible dans l’enregistrement public. La confidentialité dépend donc aussi du choix de ce nom, pas seulement de la protection de la liste.
  • Regrouper les services sous une zone enfant réduit les modifications publiques, mais donne davantage de latitude à ceux qui créent les noms sous cette zone.

Une exception étroite coûte parfois plus cher à administrer qu’une autorisation large. Chaque nouveau service appelle une modification, chaque modification mobilise deux équipes, et chaque retard nourrit la demande suivante : pourquoi ne pas approuver une fois pour toutes l’ensemble du domaine ?

Ce raisonnement paraît technique. Il contient pourtant une décision d’organisation. Supprimer une étape de coordination peut être utile ; supprimer avec elle la possibilité de revoir le périmètre est autre chose. Le coût des demandes apparaît immédiatement dans les files de travail. Le coût d’une délégation trop large peut rester invisible jusqu’au changement de prestataire ou d’usage.

Le DNS interne fournit un cas précis de ce dilemme. Certains noms doivent donner une réponse particulière sur le réseau de l’entreprise. Le client peut, pour ses autres requêtes, utiliser un résolveur chiffré extérieur. Il n’est pas nécessairement souhaitable de remplacer ce choix global simplement pour rendre quelques services internes accessibles par leur nom.

Le RFC 9704, publié en janvier 2025 sur la voie de normalisation, décrit un mécanisme permettant de vérifier une telle exception. Son intérêt ne se limite pas à reconnaître le bon serveur. Il rend possible une approbation publique qui ne publie pas la liste des noms privés concernés.

La portée de l’accord n’est pas son mode de publication

Le réseau transmet au client une déclaration : identité du résolveur, zone parente, sous-domaines revendiqués, algorithme et sel. L’opérateur de la zone parente approuve ce contenu en publiant un enregistrement TXT dont le jeton résulte du hachage de la liste mise sous forme canonique avec le sel.

Le client connaît la déclaration locale. Il peut donc calculer la valeur attendue et la comparer à celle que la zone parente rend vérifiable. Un observateur extérieur du seul enregistrement public n’a pas besoin de recevoir la liste détaillée pour que cette comparaison fonctionne.

Il ne s’agit pas de chiffrer un annuaire que le client déchiffrerait ensuite. Le sel n’est pas non plus un mot de passe dissimulé aux destinataires de la déclaration. Les deux objets s’adressent à des publics différents : les participants locaux disposent du détail ; la zone publique porte la confirmation nécessaire.

Cette répartition évite une confusion fréquente entre transparence et diffusion générale. Il est possible de demander qu’une autorisation soit vérifiable sans demander que toute information utile à son fonctionnement soit exposée au même public.

L’entreprise doit toutefois conserver une explication intelligible de son propre accord. Un jeton isolé ne dit pas à un responsable ce qui avait été approuvé. Le dossier interne doit permettre de retrouver le périmètre, le résolveur, l’usage et le responsable du changement. Rendre le registre public moins bavard ne justifie pas de rendre l’exploitation opaque à ses propres équipes.

Le registre IANA des domaines de configuration recense bien splitDnsClaims et les cinq champs de sa déclaration. Il fournit un vocabulaire commun. Il ne prouve ni l’équipement d’un parc, ni la compatibilité d’un fournisseur, ni l’existence d’une autorisation particulière. Un achat fondé sur cette seule inscription confondrait une description normalisée avec une capacité vérifiée.

Ce que le nom du résolveur raconte encore

La liste peut rester hors du DNS public, mais le résolveur a un représentant visible : son nom d’authentification figure dans le nom de l’enregistrement de vérification. Le RFC avertit que ce choix peut divulguer une information sensible.

Prenons une hypothèse, non un incident constaté ici. Une équipe protège les noms d’un projet confidentiel, puis baptise son résolveur avec le nom du projet. Le mécanisme peut fonctionner exactement comme prévu tout en donnant à un observateur un indice que l’équipe voulait garder interne.

Ce problème ne se corrige pas en renforçant l’algorithme de hachage de la liste. Il faut revoir la signification du nom rendu public. Une identité de résolveur peut être stable et vérifiable sans reprendre la nomenclature commerciale ou organisationnelle des services qu’il traite.

Ce choix devrait précéder le déploiement. Une fois un nom observé et copié, retirer l’enregistrement ne rappelle pas les copies. La facilité d’une modification DNS ne doit pas donner une fausse impression de réversibilité de la divulgation.

La confidentialité a aussi une face contractuelle et opérationnelle que ce protocole ne règle pas à lui seul. Le résolveur voit les requêtes qu’il traite. Le RFC 9463 rappelle que le chiffrement du transport ne réduit pas les données accessibles au résolveur. Confier une vue interne à un prestataire exige donc de discuter de ce qu’il reçoit et de ce qu’il en fait, même si le canal est correctement chiffré.

Dans ses conseils techniques sur les passerelles, l’ACSC d’ASD recommande de considérer les modèles de confiance et de menace avant d’exposer des vues internes à des prestataires externes. Le guide met aussi en garde contre l’emploi d’une sélection de vue par adresse IP comme mécanisme de sécurité. Il cite le RFC 9704, mais cette référence reste un conseil technique, pas une mesure de déploiement ou une garantie de sûreté.

Le parent confirme ; le réseau ne se confirme pas lui-même

Le contrôle du jeton doit emprunter une voie que l’opérateur local ne peut pas modifier à sa convenance. Le client peut utiliser un résolveur extérieur chiffré déjà configuré, en conservant ses règles habituelles d’acceptation, ou effectuer lui-même une validation DNSSEC complète de l’enregistrement.

Un délai dépassé sur la voie extérieure signifie un échec de vérification. Il ne transforme pas la nécessité d’atteindre un service interne en preuve d’autorisation. Avec DNSSEC, les états Bogus et Indeterminate entraînent le rejet ; un état Insecure appelle une autre méthode ou l’échec si le client ne réessaie pas.

Le mécanisme concerne des noms rattachés au DNS global et des résolveurs proposant un transport chiffré authentifié. Il ne valide pas de cette façon les noms à usage spécial, tels que local.. Il ne permet pas non plus à un réseau de revendiquer le filtrage d’un domaine appartenant à un tiers. L’approbation doit venir du parent approprié.

La découverte du serveur conserve un rôle distinct. Le RFC 9463 transporte son nom, ses adresses et ses paramètres de service. Vérifier le certificat par rapport au nom fourni ne valide pas, à lui seul, la sécurité de la distribution de cette configuration ou la confiance de l’utilisateur dans le réseau. Un certificat valable pour un résolveur ne constitue pas une permission portant sur tous les noms.

Cette discipline ne promet pas que toute application sera accessible. Résoudre un nom et autoriser un utilisateur à entrer dans le service sont deux opérations différentes. La confidentialité du nom ne remplace pas davantage les contrôles du service. Le gain est plus précis : une vue locale peut être admise sur une base explicable, pour les noms concernés, sans absorber toutes les autres requêtes.

Une zone enfant achète de l’autonomie

Le RFC 9704 recommande de regrouper les noms internes sous une zone enfant afin de réduire la fréquence des modifications de l’enregistrement de vérification. Cette organisation n’est pas indispensable pour éviter de publier les noms individuels.

Elle peut être très utile. Lorsque le périmètre est stable, l’équipe interne ajoute des services sans solliciter constamment l’administrateur de la zone publique. La coopération entre les deux équipes demeure nécessaire, mais elle porte moins souvent sur chaque changement ordinaire.

Il faut cependant approuver cette autonomie en connaissance de cause. Un sous-arbre ne contient pas seulement les noms présents lors de la revue. Il réserve aussi un espace dans lequel d’autres noms pourront être créés. La granularité de l’autorisation détermine donc la quantité de décisions futures qui seront prises sans nouvelle intervention du parent.

Une liste restreinte, une zone interne cohérente et une revendication couvrant tout le parent n’ont pas le même effet. Aucun de ces choix ne devrait être sélectionné uniquement parce qu’il est le plus simple dans un écran de configuration. La bonne question est de savoir à qui l’organisation veut confier l’évolution de cet espace.

Enfin, l’approbation publique et la déclaration locale ne circulent pas ensemble. Le nouvel enregistrement doit être disponible avant la modification de la déclaration, tandis que l’ancien doit rester assez longtemps pour les clients conservant une configuration encore valide. Le RFC 8801 définit séparément la durée de validité et le renouvellement des informations du domaine de configuration. Une seule opération réussie ne signifie pas que tous les clients ont changé de génération.

Aucune expérimentation de matériel, mesure d’adoption ou estimation économique n’est présentée ici. L’analyse porte sur les choix que les textes rendent visibles. Maintenir une exception précise demande de la coordination ; publier une approbation demande une politique de divulgation ; déléguer un sous-arbre demande de regarder les décisions qu’il permettra demain. Ces coûts font partie de la commodité, même lorsqu’ils n’apparaissent pas dans le prix du résolveur.