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. Sa disponibilité dépend des deux côtés du protocole.
• 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 16 septembre 2026, le déploiement Let's Encrypt reste gelé. Vérifiez d'abord votre autorité, puis votre client, avant d'envisager une évaluation.

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 16 septembre 2026 ?

Statut au 16 septembre 2026

Les BR TLS v2.3.0 autorisent la validation DNS persistante au §3.2.2.4.22. Le Datatracker présente toujours draft-ietf-acme-dns-persist-01, un document de travail dont la syntaxe TXT peut changer.

Let's Encrypt maintient son déploiement gelé dans l'attente de la résolution de l'issue IETF ACME #64, encore ouverte. Sa documentation décrit HTTP-01, DNS-01 et TLS-ALPN-01 comme méthodes utilisables. Aucune date de production n'est confirmée ici, pas plus que le fonctionnement actuel du staging.

Le blocage est explicite. Le 25 juin 2026, Aaron Gable écrit : « We will not be deploying dns-persist-01 until [...] is resolved. » Le passage omis désigne l'issue #64, qui demande une information calculée côté client dans la preuve. Cette réserve porte sur la sécurité du protocole, pas sur un simple retard de packaging. Le message d'Aaron Gable reste le point de référence pour ce gel.

La page Challenge Types de Let's Encrypt ne présente pas dns-persist-01 parmi les méthodes actives. Elle conserve aussi une notice historique sur TLS-SNI-01, retiré. L'expiration du draft -01 le 25 septembre 2026 concerne cette version du document IETF. Ce n'est ni une date de lancement ni une annulation des BR.

Chez SwissSign, les sources ont évolué. Le billet du 9 mars 2026 annonçait une mise en production estivale. La CP/CPS TLS actuelle, version 3.0 du 24 août 2026, décrit désormais 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_DU_COMPTE. 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 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 protocole ACME restant en discussion, conservez la version de spécification associée à toute évaluation.

Le compte mérite autant d'attention que le DNS. Lorsqu'un prestataire quitte votre organisation, garder son URI 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 statut retenu ici, dns-persist-01 n'est pas utilisable chez Let's Encrypt, wildcard compris. La CP/CPS SwissSign consultée réserve, elle, 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 la version -03 au jour du constat. 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 16 septembre 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 16 septembre 2026 ; elle ne classe pas les autorités capables d'émettre.

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	Release v5.0.0, notamment changement #2991	16/09/2026	Preuve pour lego ≥ v5.0.0 ; vérifier la compatibilité de la version retenue avec la CA. Aucune disponibilité LE déduite.
acme.sh	La release 3.1.4 annonce dns-persist-01 ; mode documenté	Release 3.1.4 et wiki DNS persist mode	16/09/2026	Version probante, sans prétendre établir la première version compatible. 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 #10633 et issue #10549	16/09/2026	Le changement du module manuel n'est pas livré par cette PR. Aucun parcours utilisable déduit de son ancien jalon.
cert-manager	Demande #8373 ouverte	Issue #8373	16/09/2026	Une demande ne démontre aucune implémentation publiée ni compatibilité avec une CA.
win-acme	Demande #2849 ouverte	Issue #2849	16/09/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 : attribuer l'arrivée du challenge à une version ultérieure serait trompeur. Pour Certbot, l'état fermé de la PR ne signifie pas qu'elle a été fusionnée ; l'API GitHub confirme merged: false. Ces différences changent la décision opérationnelle.

Conservez les références de version dans votre dossier d'évaluation. 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.

Si la réponse est non ou indéterminée, conservez une méthode prise en charge. Pour Let's Encrypt au statut décrit, la décision est d'attendre. 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 de la spécification acceptée par la CA. 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.

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 16 septembre 2026 ?

Le déploiement reste gelé dans l'attente de l'issue IETF #64. La documentation des challenges actifs ne le propose pas. Aucune disponibilité de production ni de staging n'est établie ici.

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. Let's Encrypt ne la propose pas au statut constaté.

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.