dns-persist-01: estado e árvore de decisão para certificados TLS

⚡TL;DR

• O dns-persist-01 associa um TXT duradouro a uma autoridade de certificação e a uma conta ACME. A sua disponibilidade depende dos dois lados do protocolo.
• O TXT mantém-se publicado. A autoridade só pode basear-se numa leitura durante 10 dias: depois, volta a ler o mesmo TXT antes de emitir um certificado.
• A 16 de setembro de 2026, a implementação do Let's Encrypt continua suspensa. Verifique primeiro a sua autoridade e depois o seu cliente antes de ponderar uma avaliação.

Um TXT que permanece publicado pode reduzir as escritas DNS necessárias à validação de domínios. É esse o interesse do dns-persist-01 para as equipas que precisam de renovar os seus certificados TLS com maior frequência. Isto não elimina as novas verificações da autoridade de certificação (CA) nem a instalação do certificado renovado.

O tema abrange várias realidades: um método admitido pelos Baseline Requirements (BR), um projeto de challenge ACME e programas em diferentes fases de integração. Para decidir, parta da sua cadeia de emissão real. Um cliente preparado não torna o respetivo servidor compatível.

Qual é o estado do dns-persist-01 a 16 de setembro de 2026?

Estado a 16 de setembro de 2026

Os BR TLS v2.3.0 permitem a validação DNS persistente no §3.2.2.4.22. O Datatracker continua a apresentar draft-ietf-acme-dns-persist-01, um documento de trabalho cuja sintaxe TXT pode mudar.

O Let's Encrypt mantém a implementação suspensa até à resolução da issue IETF ACME #64, ainda aberta. A sua documentação descreve HTTP-01, DNS-01 e TLS-ALPN-01 como métodos utilizáveis. Não se confirma aqui qualquer data de entrada em produção nem o funcionamento atual do ambiente de testes.

O bloqueio é explícito. A 25 de junho de 2026, Aaron Gable escreveu: "We will not be deploying dns-persist-01 until [...] is resolved." A passagem omitida refere-se à issue #64, que pede a inclusão de informação calculada pelo cliente na prova. Esta reserva diz respeito à segurança do protocolo, não a um simples atraso na preparação dos pacotes. A mensagem de Aaron Gable continua a ser a referência para esta suspensão.

A página dos tipos de challenge do Let's Encrypt não apresenta o dns-persist-01 entre os métodos ativos. Também mantém uma nota histórica sobre o TLS-SNI-01, entretanto retirado. A expiração do projeto -01 a 25 de setembro de 2026 diz respeito a essa versão do documento IETF. Não é uma data de lançamento nem uma anulação dos BR.

Na SwissSign, as fontes evoluíram. A publicação de 9 de março de 2026 anunciava uma entrada em produção durante o verão. A CP/CPS TLS atual, versão 3.0 de 24 de agosto de 2026, descreve agora o método 22 apenas para Managed PKI. O seu histórico situa esta adição a 17 de agosto. Isto documenta uma prática da CA nesse âmbito; não prova que qualquer cliente ACME consiga negociar dns-persist-01 com o serviço.

O que este artigo não abrange

Esta análise ajuda a decidir se faz sentido realizar uma avaliação para o seu parque de certificados TLS. Não substitui o calendário completo dos certificados de 47 dias nem o guia para automatizar a renovação de certificados TLS. Esses temas também abrangem o planeamento, a instalação e a monitorização dos certificados.

Também não é um guia de CAA ou DNSSEC: as suas funções são distinguidas mais abaixo, com recursos dedicados. Por fim, não é um procedimento de implementação de dns-persist-01. Publicar um TXT não basta para que uma CA aceite o challenge nem para resolver todas as renovações.

O que valida o TXT persistente e durante quanto tempo?

O TXT representa uma autorização de validação de domínio associada a um emissor e a uma conta. O tempo durante o qual permanece publicado difere da validade da prova obtida pela CA.

_validation-persist.[ADN]: nome DNS, emissor e conta autorizada

O método consta dos BR §3.2.2.4.22, registo DNS TXT com valor persistente. ADN significa Authorization Domain Name, o nome de domínio utilizado para obter a autorização relativa ao nome pedido. Não designa sempre o domínio raiz. Para um serviço em app.captaindns.com, não presuma, por isso, que a CA consultará necessariamente um TXT em captaindns.com.

O nome consultado segue a forma _validation-persist.[ADN]. O seu valor utiliza a sintaxe issue-value do RFC 8659, secção 4.2: issuer-domain-name; accounturi=URI_DA_CONTA. Esta notação descreve os campos; não é um valor a publicar. issuer-domain-name identifica o emissor segundo a sua CP/CPS, e accounturi designa a conta autorizada junto dele. Um nome de CA semelhante à sua marca não substitui o identificador que ela declara.

O parâmetro opcional persistUntil acrescenta um prazo expresso em segundos Unix. Após esse prazo, o registo deixa de poder servir para uma nova validação. Sem este parâmetro, o TXT não tem uma expiração própria desta sintaxe. Como o protocolo ACME continua em discussão, guarde a versão da especificação associada a cada avaliação.

A conta merece tanta atenção como o DNS. Quando um prestador deixa a sua organização, manter o URI dele na zona equivale a conservar uma autorização que talvez já não pretenda. Preveja a sua remoção, os prazos de cache e a gestão das provas já obtidas. Eliminar o TXT não revoga os certificados já emitidos.

Um TXT duradouro e uma prova da CA reutilizável durante 10 dias, no máximo

O limite de reutilização dos dados de validação é de 10 dias, no máximo, para este método, a partir do momento em que é utilizado. Não espera por 2029. Quando uma CA já não pode reutilizar a sua prova, tem de revalidar o domínio antes de voltar a basear-se neste método para emitir.

Coexistem quatro durações: a presença do TXT, o seu eventual prazo persistUntil, a atualidade da prova da CA e a validade do certificado. Um TXT publicado durante um ano pode servir para várias verificações sucessivas. Isso nunca confere um ano de reutilização à primeira prova. Inversamente, o limite de dez dias não obriga o titular a substituir o TXT a cada dez dias.

É esta a mudança operacional pretendida: a CA pode voltar a ler um registo estável, enquanto o cliente continua a pedir e a instalar certificados. Reduzem-se as alterações à zona associadas à validação sem eliminar o trabalho de renovação.

DV, OV, EV e wildcard: qual é o âmbito?

Nos certificados TLS DV, OV e EV, este método diz respeito à validação do nome. Não verifica a identidade da empresa nem substitui qualquer verificação organizacional exigida para OV ou EV. A aceitação de um tipo de certificado continua a ser uma decisão da CA, sujeita às regras do perfil em causa.

Os BR admitem o método persistente para validar nomes wildcard, sem levantar as restrições próprias dos perfis de certificados. No projeto ACME, policy=wildcard é opcional, no sentido normativo de MAY. A publicação técnica do Let's Encrypt descreve esta extensão do âmbito; não constitui uma oferta disponível. No estado considerado aqui, o dns-persist-01 não é utilizável no Let's Encrypt, incluindo para wildcard. A CP/CPS SwissSign consultada reserva a validação wildcard a outros métodos.

Para os IP, o §3.2.2.5.8 prevê _ip-validation-persist sob o nome da zona inversa correspondente; esta disposição dos BR não prova a sua disponibilidade em ACME.

O S/MIME continua a ser uma área pouco clara nos documentos comparados aqui: a sua menção na publicação da SwissSign não permite concluir que o challenge seja suportado. A assinatura de código e os VMC ficam fora do âmbito.

DNS-01, dns-account-01 e CAA: três distinções essenciais

Estes mecanismos respondem a necessidades diferentes, mesmo quando utilizam o DNS ou um identificador de conta ACME.

O DNS-01 utiliza _acme-challenge, não o TXT persistente

O DNS-01 exige um valor associado ao challenge em _acme-challenge. O registo contribui para uma prova pontual; não constitui a autorização persistente aqui descrita. O seu funcionamento está definido no RFC 8555, secção 8.4.

Com o dns-persist-01, mudam o nome consultado e o conteúdo esperado. Deixar um token DNS-01 antigo na zona não o transforma num TXT persistente. Uma delegação CNAME de _acme-challenge também não faz essa conversão. Num parque já automatizado, o DNS-01 mantém o seu interesse enquanto o par cliente/CA o suportar.

O dns-account-01 corresponde a outro método dos BR

O dns-account-01 separa os nomes de validação por conta ACME. Isto facilita, em particular, a coexistência de vários clientes ou prestadores sem lhes exigir a partilha exata do mesmo nome de challenge. O valor continua associado a uma validação, ao contrário da autorização duradoura do dns-persist-01.

Os BR referem-no no §3.2.2.4.21, com um procedimento associado ao projeto 00. O Datatracker do projeto dns-account-label apresenta a versão -03 à data da análise. Uma referência normativa nos BR, o progresso no IETF e o suporte por uma CA são três informações distintas. Classificá-lo apenas como rascunho ocultaria a primeira.

O accounturi em CAA não tem a mesma função

O CAA expressa uma política de emissão: determina quais as autoridades que podem emitir e pode restringir essa permissão a uma conta. A extensão accounturi está definida no RFC 8657. Partilhar o nome com o parâmetro do TXT persistente não faz dela a mesma prova.

Uma política CAA compatível não demonstra, por si só, o controlo do domínio. Inversamente, um TXT persistente válido não dispensa a CA de verificar o CAA. A função dos registos CAA continua, portanto, a complementar o método de validação escolhido.

Porque é que os certificados de 47 dias mudam a situação?

Renovações mais frequentes tornam as intervenções DNS repetidas mais dispendiosas, sobretudo quando cada alteração exige aprovação humana.

Em 2029, certificados de 47 dias e 10 dias de reutilização DCV

A partir de 15 de março de 2029, o limite previsto para os certificados TLS públicos será de 47 dias, com dez dias de reutilização dos dados de validação de domínio. O calendário dos certificados TLS de 47 dias detalha as etapas intermédias. Este calendário geral não adia o limite de dez dias já associado ao método persistente.

O interesse depende das suas restrições. Uma equipa cujo DNS exige alterações manuais pode evitar intervenções recorrentes se a sua CA aceitar uma autorização duradoura. Uma equipa para a qual o DNS-01 já funciona com permissões restritas terá de ponderar outros fatores. Nos dois casos, o certificado tem sempre de chegar ao serviço certo antes de expirar.

Delegação CNAME e acme-dns: o que recomendam os BR

Os BR §3.2.2.4.7 visam precisamente o caso em que uma CA, ou uma entidade afiliada, opera uma zona que recebe delegações CNAME de validação. Este serviço assemelha-se ao modelo acme-dns. O texto diz SHOULD NOT quanto à sua operação e SHOULD quanto ao encaminhamento dos utilizadores para o §3.2.2.4.22. A adição provém da proposta SC-088v3.

São recomendações normativas fortes, não uma proibição absoluta de toda a delegação CNAME. Dirigem-se à CA ou à sua afiliada que opera o serviço. Não constituem uma ordem para eliminar imediatamente a sua instância acme-dns, muito menos para migrar para um challenge indisponível no Let's Encrypt. Pergunte qual o método aceite pela sua autoridade antes de alterar um sistema em funcionamento.

Clientes ACME: que provas de suporte existem a 16 de setembro de 2026?

As provas disponíveis vão desde uma versão publicada até um pedido de funcionalidade em aberto. A matriz seguinte descreve esse estado documental, verificado a 16 de setembro de 2026; não classifica as autoridades capazes de emitir.

Cliente	Versão ou estado da alteração	Fonte primária exata	Data da análise	Âmbito e limite do lado da CA
lego	Implementação presente desde v5.0.0, com adaptação ao projeto -01	Versão v5.0.0, nomeadamente alteração #2991	16/09/2026	Prova para lego ≥ v5.0.0; verificar a compatibilidade da versão escolhida com a CA. Não se deduz disponibilidade no LE.
acme.sh	A versão 3.1.4 anuncia dns-persist-01; modo documentado	Versão 3.1.4 e wiki do modo DNS persistente	16/09/2026	Versão que comprova o suporte, sem pretender identificar a primeira versão compatível. Os exemplos do wiki não provam uma disponibilidade atual no LE.
Certbot	PR #10633 fechada a 3 de agosto de 2026, não integrada; pedido #10549 aberto	PR #10633 e issue #10549	16/09/2026	A alteração do módulo manual não é disponibilizada por esta PR. Não se deduz um procedimento utilizável a partir do seu antigo marco de planeamento.
cert-manager	Pedido #8373 aberto	Issue #8373	16/09/2026	Um pedido não demonstra uma implementação publicada nem compatibilidade com uma CA.
win-acme	Pedido #2849 aberto	Issue #2849	16/09/2026	O trimestre citado no título da issue não constitui uma data de entrega. A aceitação pela CA deve ser verificada separadamente.

Para o lego, a v5.0.0 já fornece uma prova publicada: atribuir a chegada do challenge a uma versão posterior seria enganador. Para o Certbot, o estado fechado da PR não significa que tenha sido integrada; a API do GitHub confirma merged: false. Estas diferenças alteram a decisão operacional.

Guarde as referências de versão na documentação da sua avaliação. Um pacote fornecido por uma distribuição ou integrado noutro produto pode diferir da última versão do projeto original. Verifique depois o método efetivamente proposto pela CA para a autorização em causa. A presença de uma opção no cliente não substitui essa verificação.

DNSSEC e MPIC: porque pode a validação falhar mesmo com o TXT presente

Uma resposta TXT legível a partir do seu computador não prova a sua validade DNSSEC nem a sua visibilidade a partir das perspetivas da CA.

O SC-085 também se aplica à validação DNS persistente

O SC-085 exige a validação DNSSEC das consultas DCV pela perspetiva principal da CA. O método persistente não é uma exceção. Os BR v2.3.0 consolidam estes requisitos no §4.2.2.2. Uma cadeia assinada inválida pode, por isso, bloquear uma validação mesmo que o texto do TXT esteja correto.

Isto não torna a assinatura DNSSEC obrigatória para todos os domínios. É preciso distinguir uma zona não assinada de uma zona cuja cadeia de confiança está quebrada. Uma mudança de prestador DNS com um DS antigo ainda publicado pode provocar o segundo caso. O nosso artigo sobre a validação DNSSEC de certificados TLS e o SC-085 explica este diagnóstico.

Respostas DNS variáveis por região podem fazer falhar o MPIC

O MPIC, Multi-Perspective Issuance Corroboration, compara observações de várias perspetivas de rede. Para o método persistente, as perspetivas que corroboram têm de observar uma prova válida com o mesmo accounturi da perspetiva principal. O mecanismo segue as regras de quórum dos BR, não uma simples consulta DNS local.

Um DNS com respostas geograficamente variáveis pode falhar se algumas perspetivas receberem outra conta ou não encontrarem uma prova utilizável. Isto não exclui todo o GeoDNS: respostas A diferentes consoante a região podem coexistir com um TXT de validação coerente. A questão diz respeito à resposta utilizada para validar e às perspetivas exigidas, não à designação comercial do serviço DNS.

Árvore de decisão: aguardar, avaliar ou manter o método atual?

Comece pela autoridade, depois examine o cliente e a sua capacidade de gerir a autorização. Cada resposta tem de assentar numa prova datada.

A sua autoridade aceita o método para o certificado pretendido?

Procure uma prática declarada na CP/CPS e documentação do serviço correspondente ao seu contrato. Uma menção a Managed PKI não equivale à abertura a todas as contas ou a todos os perfis. Verifique também o caso wildcard, se depender dele.

Se a resposta for negativa ou indeterminada, mantenha um método suportado. Para o Let's Encrypt no estado descrito, a decisão é aguardar. Um anúncio antigo ou uma captura de ecrã do ambiente de testes não permitem planear uma transição em produção.

O seu cliente dispõe de uma implementação publicada e compatível?

Compare a versão instalada com a matriz e depois com a especificação aceite pela CA. Uma PR não integrada ou um pedido em aberto deixam esta etapa sem prova de disponibilização. Consoante o seu contexto, aguarde ou prepare uma avaliação fora de produção com os componentes efetivamente disponíveis.

Documente o resultado esperado: negociação do challenge, validação, emissão e depois renovação. A obtenção de um primeiro certificado não demonstra, por si só, que a renovação funcionará após a expiração da prova da CA.

O seu DNS e a sua gestão de autorizações estão preparados?

Identifique quem controla o TXT, quem detém a conta autorizada e quem pode retirar essa autorização. Verifique o DNSSEC e a visibilidade do nome a partir de várias redes. Inclua a saída de um prestador ou a substituição de uma conta entre as situações a tratar.

Se todas as condições estiverem documentadas, torna-se razoável uma avaliação controlada junto da CA em causa. Mantenha a monitorização das renovações e um método de recuperação comprovado. O benefício esperado é uma redução das escritas DNS; pode ser medido sem presumir que toda a intervenção futura desaparece.

Verificar o TXT e o DNSSEC sem presumir a aceitação pela CA

A consulta TXT ajuda a observar o nome _validation-persist efetivamente em causa. A verificação DNSSEC examina a cadeia de confiança do domínio. Estas duas verificações contribuem para o diagnóstico DNS; não negoceiam o challenge com a sua autoridade nem garantem a emissão de um certificado.

O DNS watch pode complementar este trabalho com uma monitorização transversal e gratuita das alterações DNS. Um alerta ajuda a detetar uma remoção ou modificação; não certifica a compatibilidade ACME. A prova final continua a ser o comportamento documentado do par cliente/CA para o certificado pedido.

FAQ

O dns-persist-01 substitui o DNS-01 e o dns-account-01?

Não. Propõe uma autorização DNS duradoura associada a uma conta e a um emissor. O DNS-01 e o dns-account-01 utilizam outras provas e continuam a ser opções distintas, consoante o suporte disponível.

O Let's Encrypt permite utilizar dns-persist-01 a 16 de setembro de 2026?

A implementação continua suspensa até à resolução da issue IETF #64. A documentação dos challenges ativos não o propõe. Não se estabelece aqui qualquer disponibilidade em produção ou no ambiente de testes.

Porquê revalidar o domínio se o TXT continua publicado?

A autoridade só pode basear-se numa leitura do DNS durante 10 dias, no máximo. Depois, volta a ler o mesmo TXT antes de emitir um certificado; não é necessário substituí-lo.

O dns-persist-01 abrange certificados DV, OV, EV e wildcard?

A validação persistente diz respeito ao nome para DV, OV e EV, sem substituir as verificações da empresa. Os BR permitem a validação wildcard por este método, sujeita às regras do perfil e à aceitação da CA. O Let's Encrypt não o disponibiliza no estado verificado.

Um cliente ACME compatível basta para utilizar dns-persist-01?

Não. A CA tem de aceitar o método para a sua conta e o seu certificado. Uma versão do cliente prova uma implementação, não a disponibilidade do serviço remoto.

Um TXT visível numa consulta garante uma validação DNSSEC e MPIC bem-sucedida?

Não. O resultado depende do resolvedor e do ponto de observação. A CA ainda tem de validar o DNSSEC e obter a corroboração exigida a partir das suas perspetivas de rede.