Conflito entre CNAME e TXT causa problema na solicitação de certificado

Tags:
Categories:

CNAME e TXT com o mesmo prefixo não podem coexistir

Quem já mexeu com domínios provavelmente sabe que registros (A, AAAA) não podem coexistir com CNAME, mas talvez não tenha encontrado o caso de conflito entre TXT e CNAME.

Em que situação TXT e CNAME seriam usados simultaneamente com o mesmo prefixo?

Um cenário é na solicitação de certificados LetsEncrypt, quando se usa o desafio DNS-01 para validar a propriedade do domínio.

  1. O Certbot cria um registro TXT em _acme-challenge.example.com usando ackey e acsecret ou token
  2. O Letsencrypt consulta o registro TXT, confirmando que o solicitante tem autoridade para criar registros DNS, provando a propriedade do domínio
  3. O Letsencrypt emite o certificado
  4. O Certbot limpa o registro TXT em _acme-challenge.example.com

Se, ao criar o registro TXT, já existir um registro CNAME em _acme-challenge.example.com, o registro TXT pode falhar, causando falha na validação do desafio de domínio.

Por que surgiria um registro CNAME em _acme-challenge.example.com?

A Alibaba Cloud lançou recentemente o ESA (Edge Security Acceleration), semelhante ao Cloudflare, uma versão aprimorada do antigo DCDN (Full Site Acceleration). No início, não suportava solicitação autônoma de domínios curinga, então eu usava scripts para periodicamente transferir certificados curinga que eu mesmo obtinha, o que era um pouco inconveniente. Mais tarde, surgiu o DCV托管 (Managed DCV), permitindo solicitar e atualizar certificados curinga de forma autônoma. Seguindo as instruções, realmente é possível gerenciar certificados curinga, mas um risco oculto só foi descoberto meses depois. Esse registro CNAME persistente impede a criação de registros TXT com o mesmo prefixo, impedindo que eu prove a propriedade do domínio em outro lugar.

Soluções

Solução 1: Não usar DCV托管

O DCV托管 exige definir um valor específico em _acme-challenge.example.com, essencialmente declarando que o domínio pertence a terceiros, renunciando ao controle próprio sobre esse domínio.

Para domínios curinga, pode-se usar scripts de tarefa que chamem a API ESA para enviar periodicamente certificados curinga para o ESA.

Solução 2: Não usar verificação DNS-01 para validar propriedade de domínio

O Certbot oferece vários métodos de verificação (challenge) de propriedade de domínio. Além da verificação de domínio raiz (DNS-01), também há métodos como HTTP-01 e TLS-ALPN-01.

Os métodos HTTP-01 e TLS-ALPN-01 exigem um serviço já em funcionamento, validando sua acessibilidade antes de emitir o certificado.

O DNS-01 permite obter certificados antes mesmo de montar o serviço.

Solução 3: Quebrar a barreira entre ESA e DNS da Cloud解析

Esses dois serviços pertencem à Alibaba Cloud, mas cada um implementa sua própria API DNS. Se o ESA pudesse definir registros CNAME ou TXT no DNS da Cloud解析 de forma autônoma, obtendo o certificado e depois removendo o registro, não afetaria o uso do desafio DNS-01 em outro lugar.

Solução 4: Não usar ESA da Alibaba

No Cloudflare não há esse problema, os certificados são fornecidos livremente.