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. Desde o rascunho -02, a conta aparece nele como um URI com hash.
• 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 11 de outubro de 2026, a issue #64, que o Let's Encrypt aguardava, está resolvida pelo rascunho -02, mas nenhuma data foi anunciada. O Google Trust Services está em produção com o formato do rascunho -01: publique o formato documentado pela sua CA.

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 11 de outubro de 2026?

Situação em 11 de outubro de 2026

Os BR TLS v2.3.0 permitem a validação DNS persistente no §3.2.2.4.22. O Datatracker apresenta draft-ietf-acme-dns-persist-02, publicado em 20 de setembro de 2026. É um documento de trabalho do grupo ACME do IETF: sua sintaxe TXT ainda pode mudar.

As comunicações do Let's Encrypt consultadas não anunciam nem data de implantação nem suporte ao rascunho -02. O Google Trust Services anuncia suporte ao dns-persist-01 desde 28 de setembro de 2026, com base no rascunho -01.

Em 25 de junho de 2026, Aaron Gable tinha imposto uma condição: "We will not be deploying dns-persist-01 until [...] is resolved." O trecho omitido se refere à issue #64, que pedia uma informação calculada pelo cliente dentro da prova. Essa ressalva tratava da segurança do protocolo, não de um simples atraso no empacotamento. A issue foi fechada em 23 de setembro de 2026 com este comentário: "Resolved in PR #67 and published in draft-ietf-acme-dns-persist-02". A issue visada pela mensagem de Aaron Gable foi, portanto, resolvida do lado do IETF. Mesmo assim, em 11 de outubro de 2026, as comunicações do Let's Encrypt consultadas não anunciam nenhuma data de implantação.

A página de tipos de challenge do Let's Encrypt continua sem listar dns-persist-01 entre os métodos ativos. O rascunho -01 expiraria em 25 de setembro de 2026; o rascunho -02 o substituiu em 20 de setembro. O challenge mantém o nome: -02 designa a versão do documento, não um novo challenge. Essa mudança de versão não é uma data de lançamento nem um cancelamento dos BR.

O Google Trust Services (GTS) publicou em 28 de setembro de 2026 uma página dedicada ao dns-persist-01. Ela informa: "Google Trust Services now supports the dns-persist-01 challenge type". A mesma página especifica a versão seguida: "Defined in the IETF Internet-Draft draft-ietf-acme-dns-persist-01". O exemplo dela coloca uma URL de conta em texto claro em accounturi, o que corresponde ao formato -01. O rascunho atual exige um URI com hash, e os dois formatos são incompatíveis. Um TXT, portanto, só vale para a CA e para o formato que ela documenta.

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 versão 3.0 de 24 de agosto de 2026, ainda vigente em 11 de outubro de 2026, 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_HASH. 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 rascunho -02 muda o formato de accounturi (§4.1). O parâmetro precisa ser um URI com hash no formato <accountHashPrefix><hash-alg>/<valor base64url>. A CA publica o prefixo nos metadados do seu diretório ACME. O SHA-256 é obrigatório tanto para o cliente quanto para a CA. O hash cobre quatro elementos: o comprimento do domínio, o domínio onde o TXT é publicado (sem _validation-persist), a impressão digital SHA-256 (RFC 7638) da chave pública da conta ACME em formato JSON (JWK) e a URL da conta. Depois de uma rotação de chave, a CA precisa aceitar um hash calculado com a chave atual ou com uma chave anterior que ela tenha guardado.

O hash traz duas proteções. Primeiro, o canal que envia a URL da conta para você pode estar comprometido e trocá-la pela de outra conta. O TXT gerado fica então inutilizável, porque o hash também depende da chave da conta legítima. Segundo, uma mesma conta gera um valor diferente para cada domínio. Quem observa o DNS não consegue mais, portanto, relacionar os domínios de uma conta só pela leitura dos TXT. O hash não esconde a conta da CA: ela recalcula o valor e assim encontra a URL da conta (§7.2.3). O cliente também pode substituir o domínio por *. O mesmo valor aparece então em cada TXT, e esses domínios voltam a poder ser relacionados.

O formato do rascunho -01, uma URL de conta em texto claro sem vínculo criptográfico, "is no longer accepted" segundo o registro de alterações do -02. Ele não está mais, portanto, em conformidade com o rascunho atual. Mesmo assim, é o formato que o Google Trust Services documenta em 11 de outubro de 2026.

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. A proposta ACME continua sendo um documento de trabalho: anote a versão do rascunho e o formato de TXT associados a cada avaliação.

A conta merece tanta atenção quanto o DNS. Com hash ou em texto claro, accounturi sempre designa uma conta específica. Quando um prestador deixa sua organização, manter na zona o TXT da conta dele 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. Em 11 de outubro de 2026, o Let's Encrypt não lista dns-persist-01 entre seus challenges ativos, nem para wildcard. O Google Trust Services documenta policy=wildcard para cobrir o domínio, seus subdomínios e o wildcard; essa constatação vale apenas para essa CA. 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 ainda mostra a versão -03 em 11 de outubro de 2026. 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 11 de outubro 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 11 de outubro de 2026; ela não classifica as autoridades capazes de emitir. Ela distingue o rascunho -01 (URL de conta em texto claro) do rascunho -02 (URI com hash).

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; notas da v5.5.0, v5.5.1 e v5.5.2 sem menção ao rascunho -02	Versão v5.0.0, incluindo a alteração #2991, e versões do lego	11/10/2026	Prova para o formato -01 no lego ≥ v5.0.0; nenhuma prova de suporte ao -02. Verifique o formato esperado pela CA. Não se deduz disponibilidade no LE.
acme.sh	A versão 3.1.4 anuncia dns-persist-01; modo documentado; 3.1.5 e 3.1.6 sem menção ao rascunho -02, e a 3.1.6 indica "No functional change since 3.1.5"	Versão 3.1.4, wiki do modo DNS persistente e versões do acme.sh	11/10/2026	Versão que comprova o suporte, sem pretender identificar a primeira versão compatível; nenhuma prova de suporte ao -02. 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; PRs #10794 (em modo draft), #10799 e #10800 (plugin e documentação) abertas, sem integração	PR #10633, issue #10549, PR #10794, PR #10799 e PR #10800	11/10/2026	Nenhuma dessas PRs foi entregue em uma versão. O rascunho visado não está estabelecido aqui. Não se deduz nenhum fluxo utilizável.
cert-manager	Solicitação #8373 aberta	Issue #8373	11/10/2026	Uma solicitação não comprova uma implementação publicada nem compatibilidade com uma CA.
win-acme	Solicitação #2849 aberta	Issue #2849	11/10/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 para o rascunho -01: atribuir a chegada do challenge a uma versão posterior seria enganoso. Para Certbot, o fechamento da PR #10633 não significa que ela foi integrada; a API do GitHub confirma merged: false. As PRs abertas em outubro de 2026 continuam sendo trabalhos em andamento enquanto não forem integradas nem publicadas. Essas diferenças mudam a decisão operacional.

Guarde as referências de versão na documentação da sua avaliação, junto com o rascunho seguido por cada componente. 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. Por fim, anote o rascunho e o formato de TXT que a CA documenta: URL de conta em texto claro (-01) ou URI com hash (-02).

Se a resposta for não ou estiver indefinida, mantenha um método suportado. Para o Let's Encrypt, a decisão continua sendo esperar: nenhuma data foi anunciada até 11 de outubro de 2026. 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 o rascunho aceito pela CA, -01 ou -02. Um cliente que gera o formato -01 não serve para uma CA que exige o URI com hash, e vice-versa. 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. Planeje também republicar o TXT se sua CA passar do formato -01 para o formato com hash.

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 11 de outubro de 2026?

Não nessa data. A issue IETF #64, cuja resolução o Let's Encrypt aguardava em junho, está fechada desde 23 de setembro de 2026: o rascunho -02 a resolve. Mesmo assim, as comunicações consultadas não anunciam nenhuma data de implantação, e a documentação dos challenges ativos não oferece o método.

Um TXT no formato do rascunho -01 ainda funciona?

No Google Trust Services, sim: é o formato que ele documenta em 11 de outubro de 2026. Por outro lado, esse formato não está mais em conformidade com o rascunho -02, que exige um URI de conta com hash. Publique o formato documentado pela sua CA e planeje republicar o TXT se ela adotar o formato com hash.

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. Essa opção é documentada pelo Google Trust Services com policy=wildcard. O Let's Encrypt não a oferece em 11 de outubro de 2026.

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.