DNS-PERSIST-01: um novo modelo para validação de desafios baseada em DNS

• O DNS-PERSIST-01 do Let's Encrypt é um novo modelo de desafio ACME que substitui a validação repetitiva do método DNS-01 existente por registros de autenticação persistentes
• Esse método comprova o controle do domínio no longo prazo por meio de um registro TXT vinculado a uma conta ACME específica e a uma CA
• Reduz as mudanças no DNS e a carga de distribuição de credenciais de API, reforçando ao mesmo tempo a eficiência operacional e a segurança
• Oferece recursos de controle detalhado, como opção de política (policy=wildcard), momento de expiração (persistUntil) e permissão para múltiplas CAs
• Com staging previsto para o fim do 1º trimestre de 2026 e rollout completo no 2º trimestre, espera-se uma simplificação da gestão de certificados em ambientes de grande escala e altamente automatizados

---

Limitações do método DNS-01

• O desafio DNS-01 tradicional exige gerar um novo token a cada emissão de certificado e adicionar um registro TXT em _acme-challenge.
  • Cada validação requer uma atualização de DNS, o que traz atrasos de propagação e complexidade na automação
• Em implantações de grande escala, as credenciais de API de DNS ficam distribuídas por vários sistemas, aumentando os riscos de segurança
• Alguns assinantes querem evitar essas mudanças repetitivas no DNS

Estrutura e funcionamento do DNS-PERSIST-01

• O novo método introduz o conceito de autorização persistente (persistent authorization)
  • Um registro TXT contendo a CA e a URI da conta ACME é configurado uma única vez em _validation-persist.
  • Depois disso, o mesmo registro pode ser reutilizado em emissões e renovações
• Exemplo:

  _validation-persist.example.com. IN TXT (  
    "letsencrypt.org;"  
    " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"  
  )  
  

• Com isso, as mudanças de DNS são removidas do caminho de emissão, melhorando a eficiência operacional

Equilíbrio entre segurança e operação

• No DNS-01, a permissão de escrita no DNS era o principal ativo; no DNS-PERSIST-01, a proteção da chave da conta ACME passa a ser o ponto central
• Após a configuração inicial, o acesso de escrita ao DNS pode ser restringido, reduzindo a superfície de ataque
• Porém, como se trata de uma estrutura de autenticação persistente, o risco aumenta em caso de vazamento da chave da conta, exigindo reforço na gestão de segurança da conta

Recursos de controle de escopo e duração

• Por padrão, a validação é válida por tempo indeterminado apenas para o FQDN verificado
• Com a opção policy=wildcard, ela pode ser estendida para wildcards e subdomínios

  "policy=wildcard"  
  

• O atributo persistUntil permite definir o momento de expiração (em segundos UTC)
  • É necessário renovar antes do vencimento, e um sistema de monitoramento é essencial

  "persistUntil=1767225600"  
  

• Para permitir várias CAs ao mesmo tempo, é preciso adicionar registros TXT por CA em _validation-persist.

Cronograma de adoção e estado da implementação

• A votação do CA/Browser Forum SC-088v3 foi aprovada por unanimidade em outubro de 2025, e o grupo de trabalho ACME da IETF adotou o rascunho
• Já há suporte no Pebble (uma versão reduzida do Boulder), e a implementação no cliente lego-cli também está em andamento
• O staging está previsto para o fim do 1º trimestre de 2026, com implantação completa no 2º trimestre
• Esse modelo é adequado para áreas em que o método atual é ineficiente, como IoT, multitenancy e ambientes de emissão em massa de certificados

Contexto do Let's Encrypt e da ISRG

• O Let's Encrypt é uma autoridade certificadora (CA) gratuita, automatizada e aberta operada pela organização sem fins lucrativos ISRG
• O relatório anual de 2025 da ISRG divulgou suas atividades relacionadas à segurança da internet

[GN⁺]

Comentários no Hacker News

• Fico realmente muito feliz em ver essa novidade
  Quando uso o bind como servidor de nomes autoritativo, configuro de forma que cada servidor web só possa atualizar os registros TXT correspondentes a ele, restringindo o hmac-secret
  Assim, mesmo que o servidor “bob” seja comprometido, ele só conseguiria emitir certificados para o domínio “bob”
  Um exemplo de configuração é usar update-policy para limitar cada chave a modificar apenas subdomínios de _acme-challenge

  • Se você estiver disposto a operar um servidor DNS separado em vez de bind, o acmedns oferece algo semelhante
    Ao criar uma nova conta, é atribuído um subdomínio único, e se você apontar o domínio do desafio com CNAME para esse subdomínio, só aquela conta poderá atualizar essa zona

• Acho que esse recurso resolve um grande incômodo operacional do mundo real
  Ainda assim, me preocupa a exposição do identificador da conta de administração
  Nomes de usuário não são protegidos no mesmo nível que credenciais, mas podem servir de pista para um invasor identificar alvos
  Há uma boa chance de serviços como o Shodan indexarem esses IDs e oferecerem busca reversa

  • O accounturi do registro CAA já expõe identificadores de conta, então em certo sentido isso já é público
    Na verdade, acho melhor que o formato do CAA e o do registro persist sejam consistentes entre si
  • Seria bom fornecer ao usuário um ID aleatório, como um UUID, em vez da conta real, para uso no accounturi
  • Como é a mesma conta criada pelo cliente ACME, não vejo um grande risco de busca reversa

• Surpreende que isso não exija DNSSEC
  Antigamente eu achava o DNSSEC trabalhoso, mas agora há muitos registros que influenciam a confiança raiz, como CAA, CERT, SSHFP e TXT, o que os torna vulneráveis a ataques MITM
  Especialmente porque até grandes empresas muitas vezes não aplicam DNSSEC corretamente, acho que isso deveria ao menos ser explicitado como recomendação

  • O rascunho da RFC também recomenda o uso de DNSSEC como “SHOULD” (link)
  • O DNS sempre foi um ponto único de falha para a emissão de certificados TLS
    Se um atacante controlar o DNS, poderá forjar certificados usando HTTP-01, TLS-ALPN-01 ou DNS-01
  • Pessoalmente, acho TLSA uma abordagem melhor que DNSSEC, mas é uma pena que quase não haja suporte nos navegadores

• Com esse recurso, parece que vai ficar muito mais fácil emitir certificados para servidores LAN que não estão expostos à internet
  Daqui para frente, imagino que a maioria das UIs administrativas poderá gerar automaticamente uma string para colar no registro DNS e obter imediatamente um certificado da Let's Encrypt

  • Também tentei algo parecido em um ambiente semelhante, mas a configuração do headscale magic DNS era mais complexa do que eu esperava, então acabei voltando para renovação manual

• Se você usa certbot, pode acompanhar o status de suporte a esse recurso nesta issue no GitHub

• Antes eu era cético quanto à emissão de certificados de curta duração, mas mudei de ideia depois de ver certificados para endereço IP e a validação HTTP-01
  Agora não armazeno mais os certificados em disco; uma thread em segundo plano verifica novos certificados a cada 24 horas
  Isso permite criar uma solução self-hosted em que o usuário implanta o software na VM e ela fica operacional em 5 minutos
  Combinando isso com um serviço como checkip.amazonaws.com, dá para ter uma implantação totalmente automatizada

  • Mas os limites de emissão da Let's Encrypt não são negociáveis, então há o risco de ter de esperar se você fizer solicitações com muita frequência
  • Se você não armazenar certificado nenhum, a disponibilidade passará a depender do uptime da LE, então algum armazenamento mínimo ainda é necessário

• Finalmente parece que ficou mais fácil automatizar certificados para serviços web de uso exclusivamente interno
  É ótimo ver isso, porque parece resolver o maior problema operacional que existia até agora

• O ponto que falta aqui é a verificação de posse da conta ACME
  A maioria das ferramentas de automação cria a conta automaticamente, então o usuário não costuma lidar com isso diretamente, mas agora será preciso entregar ao provedor ACME uma credencial que comprove a posse da conta
  Se a Let's Encrypt não puder criar tokens restritos por domínio, talvez seja necessário usar uma conta separada para cada domínio

  • Mas as contas ACME já têm credenciais de autenticação e a propriedade do domínio é verificada por desafios DNS ou HTTP, então
    se essas credenciais ou endpoints forem comprometidos, o problema já será muito maior de qualquer forma

• Para usuários de Dynamic DNS, isso é realmente uma ótima notícia
  Por exemplo, em casos como o Namecheap, onde as solicitações de alteração só eram possíveis a partir de um IP fixo, agora bastará configurar uma vez para permitir renovação automática
  Pretendo testar isso com certeza enquanto modernizo meu homelab

• A menos que eu tenha entendido errado, fico com a dúvida se alguém que controla o servidor DNS do meu domínio, ou alguém que intercepte o tráfego entre a Let's Encrypt e esse servidor DNS, não poderia emitir um certificado TLS para o meu domínio
  O DNS-01 também tem esse problema, mas neste caso parece ainda mais fácil, porque bastaria o atacante colocar a própria conta LE na resposta DNS
  Talvez não fosse melhor colocar meu próprio certificado público diretamente no DNS?

  • Se você não pode confiar no provedor DNS, então a própria relação com ele já é o problema
    Se alguém consegue fazer MITM no tráfego entre a LE e o servidor DNS, então a situação já é muito mais grave
  • Quem controla o DNS pode emitir certificados por qualquer CA
    Se alguém pode alterar o DNS, não há como impedir a emissão de certificados
  • Se alguém controla o DNS, também pode cumprir desafios HTTP, então na prática esse domínio já é dessa pessoa
  • As CAs consultam o DNS a partir de vários pontos para mitigar ataques de rede
    A Let's Encrypt já opera assim há anos, e desde 2024 isso é obrigatório para todas as CAs
    Link para a norma do CAB Forum
  • Na verdade, essa abordagem é a que o DANE adota
    Material relacionado