Résumé

  • La révision 13 est un Internet-Draft DNSOP actif visant le statut Best Current Practice ; ce n’est ni une RFC ni une preuve de mise en œuvre, et Datatracker demande une nouvelle révision.
  • La présence d’un jeton unique au bon owner name peut relier une émission de défi à une modification DNS, sans expliquer tout le privilège déclenché chez le fournisseur.
  • Le nom du fournisseur, le service, l’utilisateur, le domaine, la portée, la persistance, l’expiration et la révocation doivent accompagner la demande pour que l’administrateur autorise en connaissance de cause.
  • Un enregistrement persistant, une délégation CNAME ou un droit de mise à jour peut survivre au contrat ; un changement de propriétaire du domaine doit ouvrir un nouvel epoch.

Le changement DNS arrive au bout d’une chaîne humaine

Une validation de contrôle de domaine paraît mécanique : le service produit une valeur, le client la place dans DNS, le service la retrouve. Cette simplicité est précieuse. Elle permet à une autorité de certification, une plateforme d’hébergement ou un autre fournisseur de vérifier qu’une personne peut influencer un nom avant d’accorder une capacité liée à ce nom.

La révision 13 de Domain Control Validation using DNS recommande un TXT sous un label spécifique à l’application. Le fournisseur compare le jeton reçu avec celui qu’il a émis pour le domaine concerné. Le jeton doit être suffisamment unique et, lorsqu’il est aléatoire, imprévisible. Le résultat peut donc établir une relation causale étroite entre le défi et sa présence dans DNS.

Mais l’administrateur qui exécute le changement ne voit souvent qu’un ticket et une chaîne opaque. Il peut prouver ce qu’il a publié sans pouvoir prouver ce qu’il a autorisé. Si l’écran du fournisseur promet une fonction et que le record en active une autre, DNS a correctement transporté une décision mal décrite.

Le label fait partie du contrat

Le préfixe spécifique au fournisseur ou au service évite les collisions avec les hostnames ordinaires. Il donne aussi du sens à l’acte. Un owner name générique transforme plusieurs fournisseurs en consommateurs possibles du même geste. Un owner name précis indique au moins quel système attend la preuve.

La confusion de service décrite par le projet montre la limite. Un service malveillant peut présenter le défi d’un autre fournisseur, convaincre l’utilisateur de publier la valeur, puis laisser l’autre fournisseur interpréter la réponse comme une autorisation. La correspondance cryptographique reste exacte alors que l’intention est fausse.

Le contrôle exige donc une attribution lisible : fournisseur, produit et service autorisé doivent être sans ambiguïté. Si un fournisseur propose plusieurs portées, les applications nouvelles devraient envisager des noms distincts. La documentation publique doit dire quel pouvoir le record ouvre.

Il ne faut pas publier dans DNS les détails sensibles du compte. Le contrat protégé peut conserver utilisateur, ressource et portée. Le DNS garde un label reconnaissable et un jeton. Un identifiant de transaction relie les deux surfaces sans exposer le contenu privé.

Contrôler un domaine ne signifie pas posséder tous les usages

La même capacité de modifier DNS peut déclencher une émission de certificat, une réception de courrier, un custom hostname, une identité sociale ou une délégation à un intermédiaire. Ces effets n’ont ni la même durée ni le même rayon d’impact.

Le projet note que les schémas existants ne distinguent pas toujours une portée étroite d’une portée large. Un administrateur peut donc répondre à une demande qui semble ponctuelle tandis que le produit enregistre un droit durable. Le champ « domaine vérifié » compresse alors la preuve et le privilège.

Avant publication, la demande doit présenter une phrase d’autorisation : quel fournisseur, quel service, quel compte, quelles ressources, quelle durée, quelle capacité récurrente et quelle méthode de retrait. L’approbation porte sur cette phrase. Le TXT prouve ensuite que l’étape DNS liée à cette phrase s’est produite.

Une gouvernance sérieuse refuse les verbes vagues. « Vérifier », « connecter » ou « activer » ne suffit pas. Le changement peut autoriser seulement une émission, une série de révalidations, la création future de challenges ou l’accès à des ressources déjà existantes. Chaque variante mérite une classe de portée.

Le jeton traverse plusieurs identités

Le fournisseur adresse le défi à un utilisateur authentifié. Cet utilisateur peut transmettre la demande à une équipe DNS. Un intermédiaire peut héberger la cible d’un CNAME. Un resolver retourne la réponse. Enfin l’application rattache le résultat à un compte et une ressource.

Chaque lien possède une identité différente. Un login correct ne prouve pas que l’administrateur DNS a approuvé le périmètre. Une réponse DNS correcte ne prouve pas que le fournisseur a choisi le bon compte. L’authentification d’un intermédiaire ne prouve pas que sa délégation couvre encore ce service.

Le reçu doit conserver l’identifiant utilisateur, le compte, le domaine, l’owner name, le digest du jeton, le fournisseur, le service, la portée demandée, les temps d’émission et d’expiration, l’observation DNS, la décision et l’identifiant du privilège créé. Une correction ajoute un état ; elle n’efface pas la première attribution.

DNSSEC peut renforcer l’intégrité de la réponse quand il est déployé et validé. Il ne fournit pas la sémantique du produit. À l’inverse, une documentation parfaite ne compense pas une lecture du mauvais nom ou une liaison au mauvais utilisateur.

Plusieurs TXT rendent le succès ambigu

Plusieurs records peuvent coexister au même nom. Le fournisseur doit trouver au moins une correspondance selon sa spécification. La réponse peut donc contenir un défi courant, des valeurs expirées et des jetons d’autres opérations.

Un journal « trouvé » perd l’essentiel. Il faut retenir la RDATA exacte, le challenge émis, l’heure, le TTL, la chaîne CNAME et les autres valeurs présentes. Pour des character-strings multiples dans une RDATA, le comparateur utilise la concaténation ; le reçu conserve la forme canonique comparée.

Le nettoyage n’est pas décoratif. Des valeurs anciennes rendent les enquêtes incertaines, augmentent la taille des réponses et peuvent être réintroduites dans un autre contexte. L’absence de suppression ne prouve pas une attaque, mais elle détruit progressivement la qualité de l’autorisation.

Expirer le défi ne retire pas forcément le droit

Pour une validation one-off, le record peut généralement disparaître après confirmation. Le fournisseur doit expliquer combien de temps le jeton est valable et quand le retirer. La révision permet une métadonnée expiry, y compris une date ou never, mais accepte aussi une politique hors DNS.

Ces options ne créent pas une horloge universelle. Le jeton peut cesser d’être accepté alors que le privilège demeure. Le TXT peut être retiré alors qu’un credential de mise à jour DNS subsiste. Le compte peut être fermé alors qu’un CNAME continue de déléguer. Le TTL peut maintenir une ancienne réponse après la suppression autoritative.

La fermeture vérifie séparément l’expiration du défi, la disparition autoritative, l’âge des caches, l’arrêt des révalidations, la révocation du credential et la suppression du droit applicatif. Sans ce parcours, « record supprimé » n’est pas une preuve de sortie.

La persistance transforme une preuve en relation

Une validation persistante évite de répéter chaque changement. Un CNAME peut déléguer la validation à un intermédiaire qui répond aux défis suivants. Cette commodité est une autorité renouvelable.

Le fournisseur doit donner la fréquence de révalidation et les instructions de révocation. L’organisation doit nommer un propriétaire de la relation, une date de revue, les services autorisés et un test de retrait. Une valeur expiry=never sans propriétaire ni justification est un risque de gouvernance.

La présence du record ne vaut pas consentement perpétuel. Le contrat peut finir, l’employé partir, le fournisseur changer ou le produit élargir sa portée. Un inventaire compare les délégations DNS aux relations commerciales et aux comptes actifs.

Les credentials d’automatisation sont parfois plus importants que le TXT visible. Si l’utilisateur conserve un droit d’écriture, il peut effectuer de nouvelles validations après la suppression d’un ancien record. La sortie doit donc examiner la capacité de recréer la preuve.

Un nouveau propriétaire ouvre une nouvelle époque

Après transfert d’un domaine, un nouvel opérateur peut remettre un ancien record depuis une sauvegarde ou suivre une instruction qui reproduit la même valeur. Pour une validation persistante, le service pourrait croire que l’ancien utilisateur conserve l’accès.

Le problème devient plus grave si le service associe toute nouvelle validation aux ressources historiques : configuration, messages, secrets ou identifiants créés par le propriétaire précédent. Contrôler aujourd’hui le domaine ne donne pas automatiquement droit au compte d’hier.

Le fournisseur ouvre un nouvel epoch de propriété et traite la validation comme une nouvelle demande. Le transfert de ressources suit une procédure distincte, avec des preuves supplémentaires. La réactivation silencieuse n’est pas un mécanisme de récupération acceptable.

La continuité peut être légitime lors d’une acquisition ou d’une migration. Elle reste une décision explicite, journalisée et réversible. L’ancien propriétaire, le nouveau, le registrar et le fournisseur possèdent des éléments différents ; aucun TXT unique ne les remplace.

Les suffixes publics révèlent l’étendue du risque

Un nom au niveau d’un suffixe public peut affecter de nombreux locataires indépendants. Le projet recommande généralement de ne pas valider la propriété d’un domaine figurant dans la division ICANN de la Public Suffix List. Les suffixes privés peuvent nécessiter des contrôles additionnels.

La question n’est pas seulement « puis-je écrire ce nœud ? ». Elle est « quelle population le privilège obtenu couvrira-t-il ? ». Un tenant autorisé à créer un enfant commençant par underscore ne devrait pas engager tous les autres utilisateurs du suffixe.

Le système de validation doit identifier la frontière enregistrable, la zone déléguée et l’autorité réelle de mise à jour. Le contrôle d’un nœud est un fait ; l’étendue commerciale ou technique du privilège reste une décision.

Le statut du texte interdit les certitudes faciles

À la date de gel, Datatracker présente la révision 13 comme un Internet-Draft DNSOP actif visant Best Current Practice. L’état du groupe demande une nouvelle version après un problème soulevé. L’IESG ne l’a pas approuvé et aucune RFC n’est publiée.

Ces éléments bornent l’analyse. Les recommandations et le threat model sont des sources utiles, mais ils peuvent changer. Aucun document cité ne prouve un déploiement, une confusion réelle de service, un compte repris, un certificat émis sans autorisation ou un incident.

L’ouverture est une construction analytique. Elle montre la différence entre une exécution DNS démontrable et une autorisation institutionnelle invisible. Elle ne décrit aucune entreprise.

Construire un reçu à deux faces

La face DNS retient la query canonique, le domaine, l’owner name, le jeton hashé, la RDATA correspondante, le CNAME, le resolver, l’état DNSSEC observable, le TTL, l’heure et le résultat. Elle répond : quelle preuve publique a été vue ?

La face autorisation retient fournisseur, service, utilisateur, compte, ressource, portée, persistance, approbateur, politique, durée, grant ID et mécanisme de révocation. Elle répond : quel pouvoir l’organisation a-t-elle choisi d’accorder ?

Le lien entre les faces porte un identifiant unique et un epoch de propriété. Pour une relation persistante, il est renouvelé. Pour un intermédiaire, il détaille chaque délégation. Pour une cession de domaine, il ne traverse pas automatiquement la frontière.

L’issue du service vient ensuite. Une validation réussie peut précéder un échec de configuration. Un service peut fonctionner sans utiliser le nouveau droit. Le résultat opérationnel exige une observation séparée.

La question de direction est simple

Avant toute automatisation, demander : si ce jeton correspond, exactement quel pouvoir notre système exercera-t-il, pour quel utilisateur, pendant combien de temps, et qui pourra le retirer ? Si la réponse n’est disponible qu’après le succès, le contrôle arrive trop tard.

Le fait durable reste étroit : une valeur issue pour un défi actif a été observée au nom DNS prévu. Le fournisseur peut utiliser ce fait dans une décision. Il ne doit pas lui faire signer silencieusement l’identité du service, la portée, la persistance, l’héritage d’un compte ou le résultat.

Sources