dns-persist-01 : état des lieux et arbre de décision pour les certificats TLS

⚡TL;DR

• dns-persist-01 lie un TXT durable à une autorité de certification et à un compte ACME. Depuis le draft -02, le compte y figure sous forme d'URI haché.
• Vous laissez le TXT en place. L'autorité ne s'appuie sur une lecture que 10 jours : après, elle relit le même TXT avant d'émettre un certificat.
• Au 11 octobre 2026, l'issue #64, que Let's Encrypt attendait, est résolue par le draft -02, mais aucune date n'est annoncée. Google Trust Services est en production sur le format du draft -01 : publiez le format documenté par votre CA.

Un TXT qui reste publié peut réduire les écritures DNS nécessaires à la validation des domaines. Voilà l'intérêt de dns-persist-01 pour les équipes qui doivent renouveler leurs certificats TLS plus souvent. Cela ne supprime ni les nouvelles vérifications de l'autorité de certification (CA) ni l'installation du certificat renouvelé.

Le sujet recouvre plusieurs réalités : une méthode admise par les Baseline Requirements (BR), un projet de challenge ACME et des logiciels à différents stades d'intégration. Pour décider, partez de votre chaîne d'émission réelle. Un client prêt ne rend pas son serveur compatible.

Où en est dns-persist-01 au 11 octobre 2026 ?

Statut au 11 octobre 2026

Les BR TLS v2.3.0 autorisent la validation DNS persistante au §3.2.2.4.22. Le Datatracker présente draft-ietf-acme-dns-persist-02, publié le 20 septembre 2026. C'est un document de travail du groupe ACME de l'IETF : sa syntaxe TXT peut encore changer.

Les communications Let's Encrypt consultées n'annoncent ni date de déploiement ni prise en charge du draft -02. Google Trust Services annonce la prise en charge de dns-persist-01 depuis le 28 septembre 2026, sur la base du draft -01.

Le 25 juin 2026, Aaron Gable avait posé une condition : « We will not be deploying dns-persist-01 until [...] is resolved. » Le passage omis désigne l'issue #64, qui demandait une information calculée côté client dans la preuve. Cette réserve portait sur la sécurité du protocole, pas sur un simple retard de packaging. L'issue a été fermée le 23 septembre 2026 avec ce commentaire : « Resolved in PR #67 and published in draft-ietf-acme-dns-persist-02 ». L'issue que visait le message d'Aaron Gable est donc résolue côté IETF. Au 11 octobre 2026, les communications Let's Encrypt consultées n'annoncent pourtant aucune date de déploiement.

La page Challenge Types de Let's Encrypt ne présente toujours pas dns-persist-01 parmi les méthodes actives. Le draft -01 devait expirer le 25 septembre 2026 ; le draft -02 l'a remplacé le 20 septembre. Le challenge garde son nom : -02 désigne la version du document, pas un nouveau challenge. Ce changement de version n'est ni une date de lancement ni une annulation des BR.

Google Trust Services (GTS) a publié le 28 septembre 2026 une page consacrée à dns-persist-01. Elle indique : « Google Trust Services now supports the dns-persist-01 challenge type ». La même page précise la version suivie : « Defined in the IETF Internet-Draft draft-ietf-acme-dns-persist-01 ». Son exemple place une URL de compte en clair dans accounturi, ce qui correspond au format -01. Le draft courant exige un URI haché, et les deux formats sont incompatibles. Un TXT n'est donc valable que pour la CA et le format qu'elle documente.

Chez SwissSign, les sources ont évolué. Le billet du 9 mars 2026 annonçait une mise en production estivale. La CP/CPS TLS version 3.0 du 24 août 2026, toujours actuelle au 11 octobre 2026, décrit la méthode 22 pour Managed PKI uniquement. Son historique situe cet ajout au 17 août. Cela documente une pratique CA dans ce périmètre ; cela ne prouve pas que tout client ACME puisse négocier dns-persist-01 avec ce service.

Ce que cet article n'est pas

Cet état des lieux aide à décider si une évaluation a du sens pour votre parc TLS. Il ne remplace pas le calendrier complet des certificats de 47 jours ni le guide pour automatiser le renouvellement des certificats TLS. Ces sujets couvrent aussi la planification, le déploiement et la surveillance des certificats.

Ce n'est pas davantage un guide CAA ou DNSSEC : leurs fonctions sont distinguées plus bas, avec les ressources dédiées. Enfin, ce n'est pas une procédure de déploiement dns-persist-01. Publier un TXT ne suffit pas à faire accepter le challenge par une CA ni à régler tous les renouvellements.

Que valide le TXT persistant, et pendant combien de temps ?

Le TXT matérialise une autorisation de validation de domaine liée à un émetteur et à un compte. Sa durée de présence diffère de celle de la preuve obtenue par la CA.

_validation-persist.[ADN] : nom DNS, émetteur et compte autorisé

La méthode figure dans les BR §3.2.2.4.22, DNS TXT Record with Persistent Value. ADN signifie Authorization Domain Name, le nom de domaine utilisé pour obtenir l'autorisation relative au nom demandé. Il ne désigne pas systématiquement le domaine racine. Pour un service sous app.captaindns.com, ne présumez donc pas que la CA consultera forcément un TXT sous captaindns.com.

Le nom interrogé suit la forme _validation-persist.[ADN]. Sa valeur reprend la syntaxe issue-value du RFC 8659, section 4.2 : issuer-domain-name; accounturi=URI_HACHÉ. Cette notation décrit les champs ; ce n'est pas une valeur à publier. issuer-domain-name identifie l'émetteur selon sa CP/CPS, et accounturi désigne le compte autorisé auprès de lui. Un nom de CA ressemblant à sa marque ne remplace pas l'identifiant qu'elle déclare.

Le draft -02 change la forme de accounturi (§4.1). Le paramètre doit être un URI haché de forme <accountHashPrefix><hash-alg>/<valeur base64url>. La CA publie le préfixe dans les métadonnées de son répertoire ACME. SHA-256 est obligatoire côté client comme côté CA. Le hash porte sur quatre éléments : la longueur du domaine, le domaine où le TXT est publié (sans _validation-persist), l'empreinte SHA-256 (RFC 7638) de la clé publique du compte ACME au format JSON (JWK) et l'URL du compte. Après une rotation de clé, la CA doit accepter un hash calculé avec la clé courante ou avec une clé antérieure qu'elle a conservée.

Le hash apporte deux protections. D'abord, le canal qui vous transmet l'URL du compte peut être compromis et y substituer celle d'un autre compte. Le TXT produit est alors inutilisable, car le hash dépend aussi de la clé du compte légitime. Ensuite, un même compte produit une valeur différente pour chaque domaine. Un observateur du DNS ne peut donc plus relier les domaines d'un compte par la seule lecture des TXT. Le hash ne cache pas le compte à la CA : elle recalcule la valeur et retrouve ainsi l'URL du compte (§7.2.3). Le client peut aussi remplacer le domaine par *. La même valeur apparaît alors dans chaque TXT, et ces domaines redeviennent reliables.

La forme du draft -01, une URL de compte en clair sans lien cryptographique, « is no longer accepted » selon le change log du -02. Elle n'est donc plus conforme au draft courant. C'est pourtant celle que documente Google Trust Services au 11 octobre 2026.

Le paramètre optionnel persistUntil ajoute une échéance exprimée en secondes Unix. Après cette échéance, l'enregistrement ne peut plus servir à une nouvelle validation. Sans ce paramètre, le TXT n'a pas d'expiration propre à cette syntaxe. Le projet ACME reste un document de travail : notez la version du draft et le format de TXT associés à toute évaluation.

Le compte mérite autant d'attention que le DNS. Haché ou en clair, accounturi désigne toujours un compte précis. Lorsqu'un prestataire quitte votre organisation, garder le TXT de son compte dans la zone revient à conserver une autorisation que vous ne souhaitez peut-être plus. Prévoyez son retrait, les délais de cache et la gestion des preuves déjà obtenues. Supprimer le TXT ne révoque pas les certificats déjà émis.

Un TXT durable, une preuve CA réutilisable 10 jours au maximum

La limite de réutilisation des données de validation est 10 jours au maximum pour cette méthode, dès son utilisation. Elle n'attend pas 2029. Lorsqu'une CA ne peut plus réutiliser sa preuve, elle doit revalider le domaine avant de s'appuyer de nouveau sur cette méthode pour émettre.

Quatre durées coexistent : la présence du TXT, son éventuelle échéance persistUntil, la fraîcheur de la preuve CA et la validité du certificat. Un TXT publié pendant un an peut servir à plusieurs vérifications successives. Cela ne donne jamais un an de réutilisation à la première preuve. Inversement, la limite de dix jours n'impose pas au titulaire de remplacer le TXT tous les dix jours.

C'est le changement opérationnel recherché : la CA peut relire un enregistrement stable, tandis que le client continue de demander et de déployer les certificats. Vous réduisez les modifications de zone liées à la validation, sans supprimer le travail de renouvellement.

DV, OV, EV et wildcard : quel périmètre ?

Pour les certificats TLS DV, OV et EV, cette méthode concerne la validation du nom. Elle ne vérifie pas l'identité de l'entreprise et ne remplace aucune vérification organisationnelle exigée pour OV ou EV. L'acceptation d'un type de certificat reste une décision de la CA, soumise aux règles du profil concerné.

Les BR admettent la méthode persistante pour valider des noms wildcard, sans lever les restrictions propres aux profils de certificats. Dans le projet ACME, policy=wildcard est optionnel, au sens normatif MAY. Le billet technique de Let's Encrypt décrit cette extension de portée ; il ne constitue pas une offre disponible. Au 11 octobre 2026, Let's Encrypt ne présente pas dns-persist-01 parmi ses challenges actifs, wildcard compris. Google Trust Services documente policy=wildcard pour couvrir le domaine, ses sous-domaines et le wildcard ; ce constat ne vaut que pour cette CA. La CP/CPS SwissSign consultée réserve la validation wildcard à d'autres méthodes.

Pour les IP, le §3.2.2.5.8 prévoit _ip-validation-persist sous le nom de zone inverse correspondant ; cette disposition BR ne prouve pas sa disponibilité ACME.

S/MIME reste une zone grise dans les documents rapprochés ici : sa mention dans le billet SwissSign ne permet pas de conclure à une prise en charge du challenge. La signature de code et les VMC sont hors périmètre.

DNS-01, dns-account-01 et CAA : trois distinctions essentielles

Ces mécanismes répondent à des besoins différents, même lorsqu'ils utilisent le DNS ou un identifiant de compte ACME.

DNS-01 utilise _acme-challenge, pas le TXT persistant

DNS-01 demande une valeur liée au challenge sous _acme-challenge. L'enregistrement participe à une preuve ponctuelle ; il ne constitue pas l'autorisation persistante décrite ici. Son fonctionnement est défini dans le RFC 8555, section 8.4.

Avec dns-persist-01, le nom interrogé et le contenu attendu changent. Laisser un ancien jeton DNS-01 dans la zone ne le transforme pas en TXT persistant. Une délégation CNAME de _acme-challenge ne réalise pas non plus cette conversion. Pour un parc déjà automatisé, DNS-01 conserve son intérêt tant que le couple client/CA le prend en charge.

dns-account-01 relève d'une autre méthode des BR

dns-account-01 sépare les noms de validation selon le compte ACME. Cela facilite notamment la coexistence de plusieurs clients ou prestataires sans leur faire partager exactement le même nom de challenge. La valeur reste liée à une validation, contrairement à l'autorisation durable de dns-persist-01.

Les BR le référencent au §3.2.2.4.21, avec une procédure rattachée au draft 00. Le Datatracker du projet dns-account-label affiche toujours la version -03 au 11 octobre 2026. Une référence normative dans les BR, l'avancement IETF et la prise en charge par une CA sont trois informations distinctes. Le qualifier simplement de brouillon masquerait la première.

accounturi dans CAA n'a pas le même rôle

CAA exprime une politique d'émission : il détermine quelles autorités peuvent émettre et peut restreindre cette permission à un compte. L'extension accounturi est définie dans le RFC 8657. Son nom commun avec le paramètre du TXT persistant n'en fait pas la même preuve.

Une politique CAA compatible n'établit pas à elle seule le contrôle du domaine. Réciproquement, un TXT persistant valide ne dispense pas la CA de vérifier CAA. Le rôle des enregistrements CAA reste donc complémentaire à la méthode choisie pour la validation.

Pourquoi les certificats de 47 jours changent-ils la donne ?

Des renouvellements plus rapprochés rendent les interventions DNS répétées plus coûteuses, surtout lorsque chaque changement exige une validation humaine.

En 2029, 47 jours de certificat et 10 jours de réutilisation DCV

À partir du 15 mars 2029, le plafond prévu pour les certificats TLS publics sera de 47 jours, avec dix jours de réutilisation des données de validation de domaine. Le calendrier des certificats TLS de 47 jours détaille les étapes intermédiaires. Ce calendrier général ne reporte pas la limite de dix jours déjà attachée à la méthode persistante.

L'intérêt dépend de vos contraintes. Une équipe dont le DNS impose des changements manuels peut éviter des interventions récurrentes si sa CA accepte une autorisation durable. Une équipe pour qui DNS-01 fonctionne déjà avec des droits restreints aura un autre arbitrage. Dans les deux cas, le certificat doit toujours atteindre le bon service avant son expiration.

Délégation CNAME et acme-dns : ce que recommandent les BR

Les BR §3.2.2.4.7 visent précisément le cas où une CA, ou une entité affiliée, exploite une zone recevant des délégations CNAME de validation. Ce service ressemble au modèle acme-dns. Le texte dit SHOULD NOT pour son exploitation et SHOULD pour l'orientation des utilisateurs vers le §3.2.2.4.22. L'ajout vient du ballot SC-088v3.

Ce sont des recommandations normatives fortes, pas une interdiction absolue de toute délégation CNAME. Leur sujet est la CA ou son affiliée qui exploite le service. Elles ne constituent pas un ordre de supprimer immédiatement votre instance acme-dns, encore moins de migrer vers un challenge indisponible chez Let's Encrypt. Demandez quelle méthode votre autorité accepte avant de modifier un dispositif opérationnel.

Clients ACME : quelles preuves de prise en charge au 11 octobre 2026 ?

Les preuves disponibles vont d'une release publiée à une demande de fonctionnalité ouverte. La matrice ci-dessous décrit cet état documentaire, vérifié le 11 octobre 2026 ; elle ne classe pas les autorités capables d'émettre. Elle distingue le draft -01 (URL de compte en clair) du draft -02 (URI haché).

Client	Version ou état du changement	Source primaire exacte	Date du constat	Portée et limite côté CA
lego	Implémentation présente dès v5.0.0, avec adaptation au draft -01 ; notes de v5.5.0, v5.5.1 et v5.5.2 sans mention du draft -02	Release v5.0.0, notamment changement #2991, et releases lego	11/10/2026	Preuve pour le format -01 dans lego ≥ v5.0.0 ; aucune preuve de prise en charge du -02. Vérifier le format attendu par la CA. Aucune disponibilité LE déduite.
acme.sh	La release 3.1.4 annonce dns-persist-01 ; mode documenté ; 3.1.5 et 3.1.6 sans mention du draft -02, 3.1.6 indiquant « No functional change since 3.1.5 »	Release 3.1.4, wiki DNS persist mode et releases acme.sh	11/10/2026	Version probante, sans prétendre établir la première version compatible ; aucune preuve de prise en charge du -02. Les exemples du wiki ne prouvent pas une disponibilité LE actuelle.
Certbot	PR #10633 fermée le 3 août 2026, non fusionnée ; demande #10549 ouverte ; PR #10794 (brouillon), #10799 et #10800 (plugin et documentation) ouvertes, non fusionnées	PR #10633, issue #10549, PR #10794, PR #10799 et PR #10800	11/10/2026	Aucune de ces PR n'est livrée dans une release. Le draft visé n'est pas établi ici. Aucun parcours utilisable déduit.
cert-manager	Demande #8373 ouverte	Issue #8373	11/10/2026	Une demande ne démontre aucune implémentation publiée ni compatibilité avec une CA.
win-acme	Demande #2849 ouverte	Issue #2849	11/10/2026	Le trimestre cité dans le titre de l'issue ne constitue pas une date de livraison. Acceptation CA à vérifier séparément.

Pour lego, v5.0.0 fournit déjà une preuve publiée pour le draft -01 : attribuer l'arrivée du challenge à une version ultérieure serait trompeur. Pour Certbot, l'état fermé de la PR #10633 ne signifie pas qu'elle a été fusionnée ; l'API GitHub confirme merged: false. Les PR ouvertes en octobre 2026 restent des travaux en cours tant qu'elles ne sont ni fusionnées ni publiées. Ces différences changent la décision opérationnelle.

Conservez les références de version dans votre dossier d'évaluation, avec le draft suivi par chaque composant. Un paquet fourni par une distribution ou embarqué dans un autre produit peut différer de la dernière release amont. Vérifiez ensuite la méthode réellement proposée par la CA pour l'autorisation concernée. La présence d'une option dans le client ne remplace pas cette vérification.

DNSSEC et MPIC : pourquoi le TXT peut être présent et la validation échouer

Une réponse TXT lisible depuis votre poste ne prouve ni sa validité DNSSEC ni sa visibilité depuis les perspectives de la CA.

SC-085 concerne aussi la validation DNS persistante

SC-085 impose la validation DNSSEC des requêtes DCV par la perspective principale de la CA. La méthode persistante n'y échappe pas. Les BR v2.3.0 consolident ces exigences au §4.2.2.2. Une chaîne signée invalide peut donc bloquer une validation alors que le texte du TXT est correct.

Cela ne rend pas la signature DNSSEC obligatoire pour tous les domaines. Il faut distinguer une zone non signée et une zone dont la chaîne de confiance est cassée. Un changement de prestataire DNS avec un ancien DS encore publié peut provoquer le second cas. Notre article sur la validation DNSSEC des certificats TLS et SC-085 explique ce diagnostic.

Des réponses DNS géo-variables peuvent faire échouer MPIC

MPIC, Multi-Perspective Issuance Corroboration, confronte les observations de plusieurs perspectives réseau. Pour la méthode persistante, les perspectives qui corroborent doivent observer une preuve valable contenant le même accounturi que la perspective principale. Le mécanisme suit les règles de quorum des BR, pas une simple consultation DNS locale.

Un DNS géo-variable peut échouer si certaines perspectives reçoivent un autre compte ou ne trouvent pas de preuve exploitable. Cela ne condamne pas tout GeoDNS : des réponses A différentes selon la région peuvent coexister avec un TXT de validation cohérent. La question porte sur la réponse utilisée pour la validation et sur les perspectives requises, pas sur l'étiquette commerciale du service DNS.

Arbre de décision : attendre, évaluer ou conserver la méthode actuelle ?

Commencez par l'autorité, puis examinez le client et votre capacité à gérer l'autorisation. Chaque réponse doit reposer sur une preuve datée.

Votre autorité accepte-t-elle la méthode pour le certificat visé ?

Cherchez une pratique déclarée dans la CP/CPS et une documentation du service correspondant à votre contrat. Une mention Managed PKI ne vaut pas ouverture à tous les comptes ni à tous les profils. Vérifiez aussi le cas wildcard si vous en dépendez. Notez enfin le draft et le format de TXT que la CA documente : URL de compte en clair (-01) ou URI haché (-02).

Si la réponse est non ou indéterminée, conservez une méthode prise en charge. Pour Let's Encrypt, la décision reste d'attendre : aucune date n'est annoncée au 11 octobre 2026. Une annonce ancienne ou une capture de staging ne permet pas de planifier une bascule de production.

Votre client dispose-t-il d'une implémentation publiée et compatible ?

Rapprochez la version installée de la matrice, puis du draft accepté par la CA, -01 ou -02. Un client qui produit le format -01 ne convient pas à une CA qui exige l'URI haché, et inversement. Une PR non fusionnée ou une demande ouverte laisse cette étape sans preuve de livraison. Selon votre contexte, attendez ou préparez une évaluation hors production avec les composants effectivement disponibles.

Documentez le résultat attendu : négociation du challenge, validation, émission, puis renouvellement. Un premier certificat obtenu ne démontre pas à lui seul que le renouvellement fonctionnera après expiration de la preuve CA.

Votre DNS et votre gestion des autorisations sont-ils prêts ?

Identifiez qui contrôle le TXT, qui possède le compte autorisé et qui peut retirer cette autorisation. Vérifiez DNSSEC et la visibilité du nom depuis plusieurs réseaux. Ajoutez le départ d'un prestataire ou le remplacement d'un compte aux situations à traiter. Prévoyez aussi de republier le TXT si votre CA passe du format -01 au format haché.

Si toutes les conditions sont documentées, une évaluation encadrée chez la CA concernée devient raisonnable. Gardez le suivi des renouvellements et une méthode de reprise éprouvée. Le gain attendu est une réduction des écritures DNS ; il se mesure sans supposer que toute intervention future disparaît.

Vérifier le TXT et DNSSEC sans présumer de l'acceptation par la CA

Le lookup TXT aide à observer le nom _validation-persist réellement concerné. Le contrôle DNSSEC examine la chaîne de confiance du domaine. Ces deux vérifications renseignent le diagnostic DNS ; elles ne négocient pas le challenge avec votre autorité et ne garantissent pas la délivrance d'un certificat.

DNS watch peut compléter ce travail comme suivi transversal gratuit des changements DNS. Une alerte aide à repérer un retrait ou une modification ; elle ne certifie pas la compatibilité ACME. La preuve finale reste le comportement documenté du couple client/CA pour le certificat demandé.

FAQ

dns-persist-01 remplace-t-il DNS-01 et dns-account-01 ?

Non. Il propose une autorisation DNS durable liée à un compte et à un émetteur. DNS-01 et dns-account-01 utilisent d'autres preuves et restent des choix distincts selon leur prise en charge.

Let's Encrypt permet-il d'utiliser dns-persist-01 au 11 octobre 2026 ?

Pas à cette date. L'issue IETF #64, dont Let's Encrypt attendait la résolution en juin, est fermée depuis le 23 septembre 2026 : le draft -02 la résout. Les communications consultées n'annoncent pourtant aucune date de déploiement, et la documentation des challenges actifs ne le propose pas.

Un TXT au format du draft -01 fonctionne-t-il encore ?

Chez Google Trust Services, oui : c'est le format qu'elle documente au 11 octobre 2026. En revanche, il n'est plus conforme au draft -02, qui exige un URI de compte haché. Publiez le format documenté par votre CA et prévoyez de republier le TXT si elle adopte le format haché.

Pourquoi revalider le domaine si le TXT reste publié ?

L'autorité ne peut s'appuyer sur une lecture du DNS que pendant 10 jours au maximum. Ensuite, elle relit le même TXT avant d'émettre un certificat ; vous n'avez pas à le remplacer.

dns-persist-01 couvre-t-il les certificats DV, OV, EV et wildcard ?

La validation persistante concerne le nom pour DV, OV et EV, sans remplacer les contrôles d'entreprise. Les BR permettent la validation wildcard par cette méthode, sous réserve des règles du profil et de l'acceptation de la CA. Cette option est documentée par Google Trust Services avec policy=wildcard. Let's Encrypt ne la propose pas au 11 octobre 2026.

Un client ACME compatible suffit-il pour utiliser dns-persist-01 ?

Non. La CA doit accepter la méthode pour votre compte et votre certificat. Une release client prouve une implémentation, pas la disponibilité du service distant.

Un TXT visible dans un lookup garantit-il une validation DNSSEC et MPIC réussie ?

Non. Le résultat dépend du résolveur et du point d'observation. La CA doit encore valider DNSSEC et obtenir la corroboration requise depuis ses perspectives réseau.