dns-persist-01: stato e albero decisionale per i certificati TLS

⚡TL;DR

• dns-persist-01 lega un TXT duraturo a un'autorità di certificazione e a un account ACME. La disponibilità dipende da entrambi i lati del protocollo.
• Lasci il TXT al suo posto. L'autorità può basarsi su una lettura solo per 10 giorni: dopo, rilegge lo stesso TXT prima di emettere un certificato.
• Al 16 settembre 2026, il rilascio presso Let's Encrypt resta congelato. Verifica prima la tua autorità, poi il client, prima di considerare una valutazione.

Un TXT che rimane pubblicato può ridurre le scritture DNS necessarie per validare i domini. È questo l'interesse di dns-persist-01 per i team che devono rinnovare più spesso i propri certificati TLS. Non elimina né le nuove verifiche dell'autorità di certificazione (CA) né l'installazione del certificato rinnovato.

Il tema comprende realtà diverse: un metodo ammesso dai Baseline Requirements (BR), una proposta di challenge ACME e software in fasi di integrazione differenti. Per decidere, parti dalla tua catena di emissione effettiva. Un client pronto non rende compatibile il suo server.

A che punto è dns-persist-01 al 16 settembre 2026?

Stato al 16 settembre 2026

I BR TLS v2.3.0 consentono la validazione DNS persistente al §3.2.2.4.22. Datatracker presenta ancora draft-ietf-acme-dns-persist-01, un documento di lavoro la cui sintassi TXT può cambiare.

Let's Encrypt mantiene il rilascio congelato in attesa della risoluzione dell'issue IETF ACME #64, ancora aperta. La documentazione descrive HTTP-01, DNS-01 e TLS-ALPN-01 come metodi utilizzabili. Qui non si conferma alcuna data di produzione né il funzionamento attuale dell'ambiente di staging.

Il blocco è esplicito. Il 25 giugno 2026, Aaron Gable ha scritto: "We will not be deploying dns-persist-01 until [...] is resolved." Il passaggio omesso rimanda all'issue #64, che richiede un'informazione calcolata dal client all'interno della prova. Questa riserva riguarda la sicurezza del protocollo, non un semplice ritardo nel confezionamento dei pacchetti. Il messaggio di Aaron Gable resta il riferimento per questo congelamento.

La pagina sui tipi di challenge di Let's Encrypt non elenca dns-persist-01 tra i metodi attivi. Conserva anche una nota storica su TLS-SNI-01, ritirato. La scadenza della bozza -01 il 25 settembre 2026 riguarda quella versione del documento IETF. Non è una data di lancio né un annullamento dei BR.

Per SwissSign, le fonti sono cambiate. Il post del 9 marzo 2026 annunciava un avvio in produzione durante l'estate. L'attuale CP/CPS TLS, versione 3.0 del 24 agosto 2026, descrive ora il metodo 22 solo per Managed PKI. La cronologia colloca questa aggiunta al 17 agosto. Ciò documenta una pratica della CA in quell'ambito; non dimostra che qualsiasi client ACME possa negoziare dns-persist-01 con il servizio.

Cosa non copre questo articolo

Questa analisi ti aiuta a decidere se una valutazione ha senso per il tuo insieme di certificati TLS. Non sostituisce il calendario completo dei certificati di 47 giorni né la guida per automatizzare il rinnovo dei certificati TLS. Questi temi comprendono anche pianificazione, distribuzione e monitoraggio dei certificati.

Non è neppure una guida a CAA o DNSSEC: le loro funzioni sono distinte più avanti, con risorse dedicate. Infine, non è una procedura di implementazione di dns-persist-01. Pubblicare un TXT non basta a far accettare il challenge da una CA né a risolvere tutti i rinnovi.

Cosa valida il TXT persistente e per quanto tempo?

Il TXT rappresenta un'autorizzazione alla validazione del dominio legata a un emittente e a un account. La durata della sua presenza è diversa da quella della prova ottenuta dalla CA.

_validation-persist.[ADN]: nome DNS, emittente e account autorizzato

Il metodo compare nei BR §3.2.2.4.22, record DNS TXT con valore persistente. ADN significa Authorization Domain Name, il nome di dominio usato per ottenere l'autorizzazione relativa al nome richiesto. Non indica sempre il dominio radice. Per un servizio sotto app.captaindns.com, non presumere quindi che la CA consulterà necessariamente un TXT sotto captaindns.com.

Il nome interrogato segue la forma _validation-persist.[ADN]. Il suo valore riprende la sintassi issue-value del RFC 8659, sezione 4.2: issuer-domain-name; accounturi=URI_ACCOUNT. Questa notazione descrive i campi; non è un valore da pubblicare. issuer-domain-name identifica l'emittente secondo la sua CP/CPS, mentre accounturi indica l'account autorizzato presso di esso. Un nome di CA simile al suo marchio non sostituisce l'identificativo che dichiara.

Il parametro facoltativo persistUntil aggiunge una scadenza espressa in secondi Unix. Dopo tale scadenza, il record non può più essere usato per una nuova validazione. Senza questo parametro, il TXT non ha una scadenza propria di questa sintassi. Poiché il protocollo ACME è ancora in discussione, conserva la versione della specifica associata a ogni valutazione.

L'account merita la stessa attenzione del DNS. Quando un fornitore lascia la tua organizzazione, mantenere il suo URI nella zona significa conservare un'autorizzazione che potresti non volere più. Prevedi la sua rimozione, i tempi della cache e la gestione delle prove già ottenute. Eliminare il TXT non revoca i certificati già emessi.

Un TXT duraturo, una prova della CA riutilizzabile per un massimo di 10 giorni

Il limite di riutilizzo dei dati di validazione è di 10 giorni al massimo per questo metodo, fin dal suo utilizzo. Non entra in vigore solo nel 2029. Quando una CA non può più riutilizzare la propria prova, deve validare nuovamente il dominio prima di basarsi ancora su questo metodo per emettere.

Coesistono quattro durate: la presenza del TXT, la sua eventuale scadenza persistUntil, l'attualità della prova della CA e la validità del certificato. Un TXT pubblicato per un anno può servire a più verifiche successive. Questo non consente mai di riutilizzare la prima prova per un anno. Viceversa, il limite di dieci giorni non impone al titolare di sostituire il TXT ogni dieci giorni.

È questo il cambiamento operativo cercato: la CA può rileggere un record stabile, mentre il client continua a richiedere e distribuire i certificati. Riduci le modifiche alla zona legate alla validazione senza eliminare il lavoro di rinnovo.

DV, OV, EV e wildcard: qual è l'ambito?

Per i certificati TLS DV, OV ed EV, questo metodo riguarda la validazione del nome. Non verifica l'identità dell'azienda e non sostituisce alcun controllo organizzativo richiesto per OV o EV. L'accettazione di un tipo di certificato resta una decisione della CA, soggetta alle regole del profilo interessato.

I BR ammettono il metodo persistente per validare nomi wildcard senza eliminare le restrizioni proprie dei profili dei certificati. Nella bozza ACME, policy=wildcard è facoltativo, nel senso normativo di MAY. Il post tecnico di Let's Encrypt descrive questa estensione dell'ambito; non costituisce un'offerta disponibile. Allo stato riportato qui, dns-persist-01 non è utilizzabile presso Let's Encrypt, wildcard compresi. La CP/CPS SwissSign consultata riserva invece la validazione wildcard ad altri metodi.

Per gli IP, il §3.2.2.5.8 prevede _ip-validation-persist sotto il nome della zona inversa corrispondente; questa disposizione dei BR non dimostra la disponibilità in ACME.

S/MIME resta un punto poco chiaro nei documenti confrontati qui: la menzione nel post SwissSign non consente di concludere che il challenge sia supportato. La firma del codice e i VMC sono fuori ambito.

DNS-01, dns-account-01 e CAA: tre distinzioni essenziali

Questi meccanismi rispondono a esigenze diverse, anche quando utilizzano il DNS o un identificativo di account ACME.

DNS-01 usa _acme-challenge, non il TXT persistente

DNS-01 richiede un valore legato al challenge sotto _acme-challenge. Il record contribuisce a una prova puntuale; non costituisce l'autorizzazione persistente descritta qui. Il funzionamento è definito nel RFC 8555, sezione 8.4.

Con dns-persist-01 cambiano il nome interrogato e il contenuto atteso. Lasciare un vecchio token DNS-01 nella zona non lo trasforma in un TXT persistente. Neppure una delega CNAME di _acme-challenge realizza questa conversione. Per un ambiente già automatizzato, DNS-01 rimane utile finché la coppia client/CA lo supporta.

dns-account-01 rientra in un altro metodo dei BR

dns-account-01 separa i nomi di validazione in base all'account ACME. Questo facilita in particolare la coesistenza di più client o fornitori senza costringerli a condividere esattamente lo stesso nome di challenge. Il valore resta legato a una validazione, a differenza dell'autorizzazione duratura di dns-persist-01.

I BR lo citano al §3.2.2.4.21, con una procedura collegata alla bozza 00. Il Datatracker del progetto dns-account-label mostra la versione -03 alla data dell'analisi. Un riferimento normativo nei BR, l'avanzamento presso l'IETF e il supporto di una CA sono tre informazioni distinte. Definirlo semplicemente una bozza nasconderebbe la prima.

accounturi in CAA non ha lo stesso ruolo

CAA esprime una politica di emissione: determina quali autorità possono emettere e può restringere tale permesso a un account. L'estensione accounturi è definita nel RFC 8657. Il nome condiviso con il parametro del TXT persistente non ne fa la stessa prova.

Una politica CAA compatibile non dimostra da sola il controllo del dominio. Viceversa, un TXT persistente valido non esonera la CA dal verificare CAA. Il ruolo dei record CAA rimane quindi complementare al metodo di validazione scelto.

Perché i certificati di 47 giorni cambiano la situazione?

Rinnovi più ravvicinati rendono più costosi gli interventi DNS ripetuti, soprattutto quando ogni modifica richiede un'approvazione umana.

Nel 2029, certificati di 47 giorni e 10 giorni di riutilizzo DCV

Dal 15 marzo 2029, la durata massima prevista per i certificati TLS pubblici sarà di 47 giorni, con dieci giorni di riutilizzo dei dati di validazione del dominio. Il calendario dei certificati TLS di 47 giorni dettaglia le tappe intermedie. Questo calendario generale non rinvia il limite di dieci giorni già associato al metodo persistente.

L'interesse dipende dai tuoi vincoli. Un team il cui DNS impone modifiche manuali può evitare interventi ricorrenti se la CA accetta un'autorizzazione duratura. Un team per cui DNS-01 funziona già con permessi limitati dovrà valutare diversamente. In entrambi i casi, il certificato deve comunque raggiungere il servizio corretto prima della scadenza.

Delega CNAME e acme-dns: cosa raccomandano i BR

I BR §3.2.2.4.7 riguardano precisamente il caso in cui una CA, o un'entità affiliata, gestisce una zona che riceve deleghe CNAME di validazione. Questo servizio assomiglia al modello acme-dns. Il testo usa SHOULD NOT per la gestione del servizio e SHOULD per indirizzare gli utenti verso il §3.2.2.4.22. L'aggiunta proviene dalla proposta SC-088v3.

Sono raccomandazioni normative forti, non un divieto assoluto di qualsiasi delega CNAME. Riguardano la CA o la sua affiliata che gestisce il servizio. Non costituiscono un ordine di eliminare subito la tua istanza acme-dns, tanto meno di migrare verso un challenge non disponibile presso Let's Encrypt. Chiedi quale metodo accetta la tua autorità prima di modificare un sistema funzionante.

Client ACME: quali prove di supporto ci sono al 16 settembre 2026?

Le prove disponibili vanno da una versione pubblicata a una richiesta di funzionalità aperta. La matrice seguente descrive questo stato documentale, verificato il 16 settembre 2026; non classifica le autorità in grado di emettere.

Client	Versione o stato della modifica	Fonte primaria esatta	Data della verifica	Ambito e limite lato CA
lego	Implementazione presente da v5.0.0, con adattamento alla bozza -01	Versione v5.0.0, in particolare modifica #2991	16/09/2026	Prova per lego ≥ v5.0.0; verificare la compatibilità della versione scelta con la CA. Nessuna disponibilità LE dedotta.
acme.sh	La versione 3.1.4 annuncia dns-persist-01; modalità documentata	Versione 3.1.4 e wiki della modalità DNS persistente	16/09/2026	Versione che dimostra il supporto, senza pretendere di stabilire la prima versione compatibile. Gli esempi del wiki non provano una disponibilità LE attuale.
Certbot	PR #10633 chiusa il 3 agosto 2026, non integrata; richiesta #10549 aperta	PR #10633 e issue #10549	16/09/2026	La modifica del modulo manuale non viene distribuita da questa PR. Nessun percorso utilizzabile dedotto dal precedente traguardo pianificato.
cert-manager	Richiesta #8373 aperta	Issue #8373	16/09/2026	Una richiesta non dimostra né un'implementazione pubblicata né la compatibilità con una CA.
win-acme	Richiesta #2849 aperta	Issue #2849	16/09/2026	Il trimestre citato nel titolo dell'issue non è una data di consegna. L'accettazione della CA va verificata separatamente.

Per lego, v5.0.0 fornisce già una prova pubblicata: attribuire l'arrivo del challenge a una versione successiva sarebbe fuorviante. Per Certbot, lo stato chiuso della PR non significa che sia stata integrata; l'API GitHub conferma merged: false. Queste differenze cambiano la decisione operativa.

Conserva i riferimenti di versione nella documentazione della valutazione. Un pacchetto fornito da una distribuzione o incorporato in un altro prodotto può differire dall'ultima versione del progetto originale. Verifica poi il metodo effettivamente proposto dalla CA per l'autorizzazione interessata. La presenza di un'opzione nel client non sostituisce questa verifica.

DNSSEC e MPIC: perché la validazione può fallire anche se il TXT è presente

Una risposta TXT leggibile dalla tua postazione non dimostra né la sua validità DNSSEC né la visibilità dalle prospettive della CA.

SC-085 riguarda anche la validazione DNS persistente

SC-085 impone la validazione DNSSEC delle query DCV dalla prospettiva principale della CA. Il metodo persistente non fa eccezione. I BR v2.3.0 consolidano questi requisiti al §4.2.2.2. Una catena firmata non valida può quindi bloccare la validazione anche quando il testo del TXT è corretto.

Questo non rende obbligatoria la firma DNSSEC per tutti i domini. Occorre distinguere una zona non firmata da una zona con una catena di fiducia interrotta. Un cambio di provider DNS con un vecchio DS ancora pubblicato può provocare il secondo caso. Il nostro articolo sulla validazione DNSSEC dei certificati TLS e SC-085 spiega questa diagnosi.

Risposte DNS diverse per area geografica possono far fallire MPIC

MPIC, Multi-Perspective Issuance Corroboration, confronta le osservazioni di più prospettive di rete. Per il metodo persistente, le prospettive che forniscono conferma devono osservare una prova valida contenente lo stesso accounturi della prospettiva principale. Il meccanismo segue le regole di quorum dei BR, non una semplice query DNS locale.

Un DNS con risposte variabili per area geografica può fallire se alcune prospettive ricevono un altro account o non trovano una prova utilizzabile. Questo non esclude ogni GeoDNS: risposte A diverse secondo la regione possono coesistere con un TXT di validazione coerente. La questione riguarda la risposta usata per la validazione e le prospettive richieste, non l'etichetta commerciale del servizio DNS.

Albero decisionale: attendere, valutare o mantenere il metodo attuale?

Inizia dall'autorità, poi esamina il client e la tua capacità di gestire l'autorizzazione. Ogni risposta deve basarsi su una prova datata.

La tua autorità accetta il metodo per il certificato previsto?

Cerca una pratica dichiarata nella CP/CPS e una documentazione del servizio corrispondente al tuo contratto. Una menzione di Managed PKI non equivale all'accesso per tutti gli account o tutti i profili. Verifica anche il caso wildcard se ne dipendi.

Se la risposta è no o non è chiara, mantieni un metodo supportato. Per Let's Encrypt allo stato descritto, la decisione è attendere. Un vecchio annuncio o una schermata di staging non permettono di pianificare un passaggio in produzione.

Il tuo client dispone di un'implementazione pubblicata e compatibile?

Confronta la versione installata con la matrice, poi con la specifica accettata dalla CA. Una PR non integrata o una richiesta aperta lasciano questa fase priva di una prova di rilascio. In base al contesto, attendi o prepara una valutazione fuori produzione con i componenti effettivamente disponibili.

Documenta il risultato atteso: negoziazione del challenge, validazione, emissione e poi rinnovo. Ottenere un primo certificato non dimostra da solo che il rinnovo funzionerà dopo la scadenza della prova della CA.

Il tuo DNS e la gestione delle autorizzazioni sono pronti?

Identifica chi controlla il TXT, chi possiede l'account autorizzato e chi può rimuovere l'autorizzazione. Verifica DNSSEC e la visibilità del nome da più reti. Includi l'uscita di un fornitore o la sostituzione di un account tra le situazioni da gestire.

Se tutte le condizioni sono documentate, una valutazione controllata presso la CA interessata diventa ragionevole. Mantieni il monitoraggio dei rinnovi e un metodo di ripristino collaudato. Il vantaggio atteso è una riduzione delle scritture DNS; si misura senza presumere che scompaia ogni intervento futuro.

Verificare TXT e DNSSEC senza presumere l'accettazione della CA

La query TXT aiuta a osservare il nome _validation-persist effettivamente interessato. Il controllo DNSSEC esamina la catena di fiducia del dominio. Queste due verifiche contribuiscono alla diagnosi DNS; non negoziano il challenge con la tua autorità e non garantiscono l'emissione di un certificato.

DNS watch può completare questo lavoro con un monitoraggio gratuito delle modifiche DNS, trasversale ai diversi metodi. Un avviso aiuta a individuare una rimozione o una modifica; non certifica la compatibilità ACME. La prova finale resta il comportamento documentato della coppia client/CA per il certificato richiesto.

FAQ

dns-persist-01 sostituisce DNS-01 e dns-account-01?

No. Propone un'autorizzazione DNS duratura legata a un account e a un emittente. DNS-01 e dns-account-01 usano altre prove e restano scelte distinte in base al supporto disponibile.

Let's Encrypt permette di usare dns-persist-01 al 16 settembre 2026?

Il rilascio resta congelato in attesa della risoluzione dell'issue IETF #64. La documentazione dei challenge attivi non lo propone. Qui non viene attestata alcuna disponibilità in produzione o in staging.

Perché validare di nuovo il dominio se il TXT resta pubblicato?

L'autorità può basarsi su una lettura del DNS per un massimo di 10 giorni. Poi rilegge lo stesso TXT prima di emettere un certificato; non devi sostituirlo.

dns-persist-01 copre i certificati DV, OV, EV e wildcard?

La validazione persistente riguarda il nome per DV, OV ed EV, senza sostituire i controlli aziendali. I BR permettono la validazione wildcard con questo metodo, nel rispetto delle regole del profilo e dell'accettazione della CA. Let's Encrypt non lo propone allo stato rilevato.

Un client ACME compatibile basta per usare dns-persist-01?

No. La CA deve accettare il metodo per il tuo account e il tuo certificato. Una versione del client dimostra un'implementazione, non la disponibilità del servizio remoto.

Un TXT visibile in una query garantisce una validazione DNSSEC e MPIC riuscita?

No. Il risultato dipende dal resolver e dal punto di osservazione. La CA deve ancora validare DNSSEC e ottenere la conferma richiesta dalle proprie prospettive di rete.