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

⚡TL;DR

• O dns-persist-01 vincula um TXT duradouro a uma autoridade certificadora e a uma conta ACME. A disponibilidade depende dos dois lados do protocolo.
• Você deixa o TXT no lugar. A autoridade só pode se basear em uma leitura por 10 dias: depois disso, ela lê novamente o mesmo TXT antes de emitir um certificado.
• Em 16 de setembro de 2026, a implantação no Let's Encrypt continua congelada. Confira primeiro sua autoridade e depois seu cliente antes de considerar uma avaliação.

Um TXT que continua publicado pode reduzir as gravações DNS necessárias para validar domínios. Esse é o interesse do dns-persist-01 para equipes que precisam renovar seus certificados TLS com mais frequência. Ele não elimina novas verificações da autoridade certificadora (CA) nem a instalação do certificado renovado.

O assunto envolve realidades diferentes: um método permitido pelos Baseline Requirements (BR), uma proposta de challenge ACME e programas em estágios distintos de integração. Para decidir, comece pela cadeia de emissão que você usa de fato. Um cliente pronto não torna o servidor compatível.

Qual é a situação do dns-persist-01 em 16 de setembro de 2026?

Situação em 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 ainda apresenta draft-ietf-acme-dns-persist-01, um documento de trabalho cuja sintaxe TXT pode mudar.

O Let's Encrypt mantém a implantação congelada enquanto aguarda a resolução da issue IETF ACME #64, que segue aberta. A documentação descreve HTTP-01, DNS-01 e TLS-ALPN-01 como métodos utilizáveis. Não se confirma aqui nenhuma data de produção nem o funcionamento atual do ambiente de testes.

O bloqueio é explícito. Em 25 de junho de 2026, Aaron Gable escreveu: "We will not be deploying dns-persist-01 until [...] is resolved." O trecho omitido se refere à issue #64, que pede uma informação calculada pelo cliente dentro da prova. Essa ressalva trata da segurança do protocolo, não de um simples atraso no empacotamento. A mensagem de Aaron Gable continua sendo a referência para esse congelamento.

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

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

O que este artigo não cobre

Esta análise ajuda você a decidir se vale a pena avaliar o método para seu conjunto de certificados TLS. Ela não substitui o cronograma completo dos certificados de 47 dias nem o guia para automatizar a renovação de certificados TLS. Esses temas também cobrem planejamento, implantação e monitoramento dos certificados.

Também não é um guia de CAA ou DNSSEC: suas funções são diferenciadas mais adiante, com recursos específicos. Por fim, não é um procedimento de implantaçã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 o TXT persistente valida e por quanto tempo?

O TXT representa uma autorização de validação de domínio vinculada a um emissor e a uma conta. O tempo que ele permanece publicado é diferente da validade da prova obtida pela CA.

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

O método aparece nos BR §3.2.2.4.22, registro DNS TXT com valor persistente. ADN significa Authorization Domain Name, o nome de domínio usado para obter a autorização referente ao nome solicitado. Ele nem sempre designa o domínio raiz. Para um serviço em app.captaindns.com, portanto, não presuma que a CA necessariamente consultará um TXT em captaindns.com.

O nome consultado segue o formato _validation-persist.[ADN]. Seu valor usa a sintaxe issue-value do RFC 8659, seção 4.2: issuer-domain-name; accounturi=URI_DA_CONTA. Essa notação descreve os campos; não é um valor para publicar. issuer-domain-name identifica o emissor conforme sua CP/CPS, e accounturi identifica a conta autorizada junto a ele. Um nome de CA parecido com sua marca não substitui o identificador que ela declara.

O parâmetro opcional persistUntil acrescenta um prazo expresso em segundos Unix. Depois desse prazo, o registro não pode mais servir para uma nova validação. Sem esse parâmetro, o TXT não tem uma expiração própria dessa sintaxe. Como o protocolo ACME ainda está em discussão, guarde a versão da especificação associada a cada avaliação.

A conta merece tanta atenção quanto o DNS. Quando um prestador deixa sua organização, manter o URI dele na zona significa conservar uma autorização que você talvez não queira mais. Planeje a remoção, os prazos de cache e o tratamento das provas já obtidas. Excluir o TXT não revoga certificados que já foram emitidos.

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

O limite de reutilização dos dados de validação é de no máximo 10 dias para esse método, a partir do momento em que ele é utilizado. Não é preciso esperar até 2029 para que o limite se aplique. Quando uma CA não pode mais reutilizar sua prova, ela precisa revalidar o domínio antes de se basear novamente nesse método para emitir.

Quatro durações coexistem: a presença do TXT, seu eventual prazo persistUntil, a atualidade da prova da CA e a validade do certificado. Um TXT publicado por um ano pode servir para várias verificações sucessivas. Isso nunca dá um ano de reutilização à primeira prova. Por outro lado, o limite de dez dias não obriga o titular a trocar o TXT a cada dez dias.

Essa é a mudança operacional pretendida: a CA pode reler um registro estável enquanto o cliente continua solicitando e implantando certificados. Você reduz as alterações na zona relacionadas à validação sem eliminar o trabalho de renovação.

DV, OV, EV e wildcard: qual é o escopo?

Para certificados TLS DV, OV e EV, esse método valida o nome. Ele não verifica a identidade da empresa nem substitui qualquer verificação organizacional exigida para OV ou EV. Aceitar um tipo de certificado continua sendo uma decisão da CA, sujeita às regras do perfil correspondente.

Os BR permitem o método persistente para validar nomes wildcard sem remover as restrições próprias dos perfis de certificados. Na proposta ACME, policy=wildcard é opcional, no sentido normativo de MAY. A publicação técnica do Let's Encrypt descreve essa ampliação de escopo; ela não constitui uma oferta disponível. Na situação considerada aqui, dns-persist-01 não pode ser usado no Let's Encrypt, nem para wildcard. A CP/CPS SwissSign consultada reserva a validação wildcard a outros métodos.

Para IPs, o §3.2.2.5.8 prevê _ip-validation-persist sob o nome da zona reversa correspondente; essa disposição dos BR não prova sua disponibilidade em ACME.

S/MIME continua sendo um ponto pouco claro nos documentos comparados aqui: a menção na publicação da SwissSign não permite concluir que o challenge seja suportado. Assinatura de código e VMCs estão fora do escopo.

DNS-01, dns-account-01 e CAA: três diferenças essenciais

Esses mecanismos atendem a necessidades diferentes, mesmo quando usam o DNS ou um identificador de conta ACME.

DNS-01 usa _acme-challenge, não o TXT persistente

DNS-01 exige um valor vinculado ao challenge em _acme-challenge. O registro participa de uma prova pontual; ele não é a autorização persistente descrita aqui. Seu funcionamento está definido no RFC 8555, seção 8.4.

Com dns-persist-01, mudam o nome consultado e o conteúdo esperado. Deixar um token DNS-01 antigo na zona não o transforma em um TXT persistente. Uma delegação CNAME de _acme-challenge também não faz essa conversão. Para um ambiente já automatizado, DNS-01 continua sendo útil enquanto o par cliente/CA oferecer suporte.

dns-account-01 pertence a outro método dos BR

dns-account-01 separa os nomes de validação por conta ACME. Isso facilita, em especial, a coexistência de vários clientes ou prestadores sem que eles compartilhem exatamente o mesmo nome de challenge. O valor continua vinculado a uma validação, diferentemente da autorização duradoura de dns-persist-01.

Os BR fazem referência a ele no §3.2.2.4.21, com um procedimento associado ao rascunho 00. O Datatracker do projeto dns-account-label mostra a versão -03 na data da análise. Uma referência normativa nos BR, o avanço no IETF e o suporte por uma CA são três informações diferentes. Chamá-lo apenas de rascunho esconderia a primeira.

accounturi em CAA tem outra função

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

Uma política CAA compatível não estabelece sozinha o controle do domínio. Inversamente, um TXT persistente válido não dispensa a CA de verificar CAA. A função dos registros CAA continua, portanto, complementando o método escolhido para a validação.

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

Renovações mais frequentes tornam mais caras as intervenções DNS repetidas, principalmente quando cada mudança 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 certificados TLS públicos será de 47 dias, com dez dias de reutilização dos dados de validação de domínio. O cronograma dos certificados TLS de 47 dias detalha as etapas intermediárias. Esse cronograma geral não adia o limite de dez dias que já se aplica ao método persistente.

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

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

Os BR §3.2.2.4.7 tratam especificamente do caso em que uma CA, ou uma entidade afiliada, opera uma zona que recebe delegações CNAME de validação. Esse serviço se parece com o modelo acme-dns. O texto usa SHOULD NOT para a operação do serviço e SHOULD para direcionar os usuários ao §3.2.2.4.22. A inclusão vem da proposta SC-088v3.

São recomendações normativas fortes, não uma proibição absoluta de qualquer delegação CNAME. Elas se dirigem à CA ou à afiliada que opera o serviço. Não são uma ordem para excluir imediatamente sua instância acme-dns, muito menos para migrar para um challenge indisponível no Let's Encrypt. Pergunte qual método sua autoridade aceita antes de alterar uma configuração que está funcionando.

Clientes ACME: quais provas de suporte existem em 16 de setembro de 2026?

As provas disponíveis vão de uma versão publicada a uma solicitação de funcionalidade aberta. A matriz abaixo descreve essa situação documental, verificada em 16 de setembro de 2026; ela não classifica as autoridades capazes de emitir.

Cliente	Versão ou situação da alteração	Fonte primária exata	Data da verificação	Escopo e limite do lado da CA
lego	Implementação presente desde v5.0.0, adaptada ao rascunho -01	Versão v5.0.0, incluindo a alteração #2991	16/09/2026	Prova para lego ≥ v5.0.0; verifique 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 disponibilidade atual no LE.
Certbot	PR #10633 fechada em 3 de agosto de 2026, sem integração; solicitação #10549 aberta	PR #10633 e issue #10549	16/09/2026	A alteração do módulo manual não é entregue por essa PR. Seu antigo marco de planejamento não permite deduzir um fluxo utilizável.
cert-manager	Solicitação #8373 aberta	Issue #8373	16/09/2026	Uma solicitação não comprova uma implementação publicada nem compatibilidade com uma CA.
win-acme	Solicitação #2849 aberta	Issue #2849	16/09/2026	O trimestre mencionado no título da issue não é uma data de entrega. A aceitação pela CA precisa ser verificada separadamente.

Para lego, a v5.0.0 já fornece uma prova publicada: atribuir a chegada do challenge a uma versão posterior seria enganoso. Para Certbot, uma PR fechada não significa uma PR integrada; a API do GitHub confirma merged: false. Essas diferenças mudam 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 incorporado em outro produto pode ser diferente da versão mais recente do projeto original. Depois, verifique o método que a CA realmente oferece para a autorização em questão. A presença de uma opção no cliente não substitui essa verificação.

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

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

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

SC-085 exige que a perspectiva principal da CA valide DNSSEC nas consultas DCV. O método persistente não é uma exceção. Os BR v2.3.0 consolidam esses requisitos no §4.2.2.2. Uma cadeia assinada inválida pode, portanto, bloquear a validação mesmo quando o texto do TXT está correto.

Isso 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 troca de provedor DNS com um DS antigo ainda publicado pode provocar o segundo caso. Nosso artigo sobre validação DNSSEC de certificados TLS e SC-085 explica esse diagnóstico.

Respostas DNS que variam por região podem fazer o MPIC falhar

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

Um DNS que varia geograficamente pode falhar se algumas perspectivas receberem outra conta ou não encontrarem uma prova utilizável. Isso não descarta todo GeoDNS: respostas A diferentes conforme a região podem coexistir com um TXT de validação consistente. A questão é a resposta usada para validar e as perspectivas exigidas, não o rótulo comercial do serviço DNS.

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

Comece pela autoridade e depois examine o cliente e sua capacidade de gerenciar a autorização. Cada resposta precisa se basear em uma prova datada.

Sua autoridade aceita o método para o certificado desejado?

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 significa acesso para todas as contas nem para todos os perfis. Confira também o caso wildcard se você depende dele.

Se a resposta for não ou estiver indefinida, mantenha um método suportado. Para o Let's Encrypt na situação descrita, a decisão é esperar. Um anúncio antigo ou uma captura de tela do ambiente de testes não permite planejar uma migração em produção.

Seu cliente tem uma implementação publicada e compatível?

Compare a versão instalada com a matriz e depois com a especificação aceita pela CA. Uma PR não integrada ou uma solicitação aberta deixa essa etapa sem prova de entrega. Dependendo do seu contexto, espere ou prepare uma avaliação fora de produção com os componentes que estão efetivamente disponíveis.

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

Seu DNS e seu gerenciamento de autorizações estão prontos?

Identifique quem controla o TXT, quem é dono da conta autorizada e quem pode remover essa autorização. Verifique 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 que você precisa tratar.

Se todas as condições estiverem documentadas, uma avaliação controlada junto à CA em questão passa a ser razoável. Mantenha o monitoramento das renovações e um método de recuperação já testado. O ganho esperado é reduzir as gravações DNS; você pode medi-lo sem presumir que toda intervenção futura vai desaparecer.

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

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

O DNS watch pode complementar esse trabalho com monitoramento gratuito de mudanças DNS, independentemente do método. Um alerta ajuda a identificar uma remoção ou alteração; ele não certifica a compatibilidade ACME. A prova final continua sendo o comportamento documentado do par cliente/CA para o certificado solicitado.

FAQ

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

Não. Ele propõe uma autorização DNS duradoura vinculada a uma conta e a um emissor. DNS-01 e dns-account-01 usam outras provas e continuam sendo escolhas distintas conforme o suporte disponível.

O Let's Encrypt permite usar dns-persist-01 em 16 de setembro de 2026?

A implantação continua congelada enquanto aguarda a resolução da issue IETF #64. A documentação dos challenges ativos não oferece o método. Nenhuma disponibilidade em produção ou no ambiente de testes é estabelecida aqui.

Por que revalidar o domínio se o TXT continua publicado?

A autoridade só pode se basear em uma leitura do DNS por no máximo 10 dias. Depois, ela lê novamente o mesmo TXT antes de emitir um certificado; você não precisa substituí-lo.

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

A validação persistente trata do nome para DV, OV e EV, sem substituir as verificações da empresa. Os BR permitem a validação wildcard por esse método, sujeita às regras do perfil e à aceitação da CA. O Let's Encrypt não o oferece na situação verificada.

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

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

Um TXT visível em uma 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 precisa validar DNSSEC e obter a corroboração exigida a partir de suas perspectivas de rede.