Ballot SC-085v2: as autoridades de certificação agora verificam DNSSEC antes de emitir um certificado TLS

⚡TL;DR

• Desde 15 de março de 2026, as CA devem verificar DNSSEC durante a validação de domínio (DCV) antes de emitir um certificado TLS (Ballot SC-085v2)
• Se o seu domínio publica DNSSEC e a cadeia de confiança está quebrada (BOGUS), nenhum certificado será emitido enquanto o problema persistir
• SC-085v2 complementa MPIC (SC-067): juntos, protegem a DCV contra BGP hijacking e DNS spoofing
• O SC-081v3 também reduz a validade dos certificados TLS para 47 dias até 2029: consulte nosso guia completo SC-081v3

Desde 15 de março de 2026, renovar um certificado TLS pode falhar se o seu domínio publica DNSSEC com uma cadeia de confiança inválida. Isso não é um bug do seu provedor de certificados: é a aplicação do Ballot SC-085v2 do CA/Browser Forum, que exige que as autoridades de certificação (CA) validem as respostas DNSSEC durante a verificação de controle de domínio.

Essa mudança afeta todos os domínios que publicam DNSSEC. Se a sua zona DNS está corretamente assinada, você se beneficia de uma proteção reforçada contra ataques de BGP hijacking e DNS spoofing durante a emissão de certificados. Mas se a sua configuração DNSSEC está quebrada (DS record desatualizado, assinaturas expiradas, algoritmo obsoleto), a CA recusará emitir o certificado.

Este artigo detalha o problema que SC-085v2 resolve, seu funcionamento técnico, sua interação com MPIC (SC-067), o impacto operacional conforme a sua situação e um guia prático para verificar e corrigir a sua configuração antes da próxima renovação.

O problema: a DCV depende de um DNS não autenticado

A validação de controle de domínio (DCV) é o processo pelo qual uma CA verifica que o solicitante de um certificado realmente controla o domínio em questão. Esse processo depende do DNS, um protocolo projetado sem autenticação de respostas.

Como funciona a validação de domínio (DCV)

Antes de emitir um certificado TLS, a CA precisa garantir que você controla o domínio para o qual solicita o certificado. Três métodos de validação são comumente utilizados:

• DNS-01: a CA solicita a publicação de um registro TXT específico em _acme-challenge.captaindns.com. Em seguida, consulta o DNS para verificar se o registro está presente e contém o valor esperado. É o método mais utilizado por sistemas automatizados.
• HTTP-01: a CA solicita que um arquivo seja colocado em uma URL específica no servidor web do domínio (por exemplo, http://captaindns.com/.well-known/acme-challenge/TOKEN). Em seguida, verifica se o arquivo está acessível e contém o valor correto.
• Email: a CA envia um email de validação para um endereço administrativo do domínio (admin@, postmaster@, etc.) e aguarda uma confirmação.

O protocolo ACME (Automatic Certificate Management Environment, RFC 8555) automatiza essas trocas. Ele padroniza o diálogo entre o cliente (certbot, acme.sh, etc.) e a CA. O método DNS-01 é o mais utilizado em ambientes automatizados porque permite validar certificados wildcard e não exige a exposição de um servidor web.

Em todos os casos, a CA realiza consultas DNS: para resolver o TXT de validação (DNS-01), para resolver o endereço IP do servidor web (HTTP-01), ou para resolver o MX do domínio (email). O DNS é, portanto, a base da DCV.

O DNS sem DNSSEC é falsificável

O protocolo DNS, projetado em 1983, não inclui nenhuma autenticação de respostas. Um resolvedor DNS não consegue distinguir uma resposta legítima de uma resposta forjada. Essa fraqueza estrutural abre caminho para vários vetores de ataque:

Cache poisoning. Um atacante injeta respostas falsas no cache de um resolvedor DNS. As consultas subsequentes para o mesmo domínio retornam o endereço IP do atacante em vez do servidor legítimo.

BGP hijacking. Um atacante anuncia rotas BGP fraudulentas para desviar o tráfego de rede para seus próprios servidores. Combinado com uma consulta DCV, ele pode interceptar a validação e obter um certificado para um domínio que não controla.

Ataque man-in-the-middle na rede. Um atacante posicionado no caminho de rede entre a CA e o servidor DNS autoritativo modifica as respostas DNS em trânsito.

Esses ataques não são teóricos. Vários incidentes graves demonstraram sua viabilidade:

• KLAYswap (fevereiro de 2022): atacantes desviaram o tráfego BGP de um registro de domínio coreano, obtiveram um certificado TLS fraudulento por BGP hijack e roubaram o equivalente a 2 milhões de dólares em criptomoeda por meio de um site falso.
• Celer Bridge (agosto de 2022): um ataque semelhante explorou o BGP hijacking para desviar o tráfego DNS de uma bridge DeFi. Os atacantes obtiveram um certificado fraudulento e roubaram 235.000 dólares.
• MyEtherWallet (abril de 2018): atacantes desviaram os prefixos BGP do Route 53 da Amazon para redirecionar as consultas DNS para um servidor fraudulento, obtiveram um certificado TLS e interceptaram as credenciais dos usuários da carteira cripto.

A pesquisa acadêmica formalizou esses riscos. O estudo "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018, Princeton University) demonstrou que um atacante podia obter certificados TLS fraudulentos das cinco maiores CA desviando consultas DNS via BGP, com uma taxa de sucesso superior a 60% em seus experimentos.

A conclusão é clara: enquanto a DCV depender de um DNS não autenticado, a emissão de certificados TLS permanece vulnerável.

Ballot SC-085v2: o que muda na prática

O Ballot SC-085v2, intitulado "Require Validation of DNSSEC when Present for CAA and DCV Lookups", foi proposto por Clint Wilson (Apple) e endossado pelo Chrome Root Program (Google), Fastly e HARICA. Ele modifica os Baseline Requirements (BR) do CA/Browser Forum, o documento normativo que todas as CA publicamente aprovadas devem respeitar.

A votação

A votação foi concluída com aprovação unânime do lado dos navegadores e quase unânime do lado das CA:

• 25 votos a favor (incluindo DigiCert, Sectigo, GlobalSign, Entrust, HARICA, SwissSign)
• 0 votos contra
• 1 abstenção (Entrust, que votou a favor no aspecto técnico, mas se absteve em questões de cronograma)
• Navegadores: Apple e Mozilla votaram a favor

O que o ballot exige

Desde 15 de março de 2026, as CA devem realizar uma validação DNSSEC completa nas consultas DNS utilizadas para:

1. A validação de controle de domínio (DCV): todas as consultas DNS relacionadas à verificação de controle (TXT para DNS-01, A/AAAA para HTTP-01, MX para email)
2. As verificações CAA (Certification Authority Authorization): os registros CAA determinam quais CA estão autorizadas a emitir certificados para um domínio

A validação DNSSEC deve ser realizada até o trust anchor IANA (a KSK raiz) na Primary Network Perspective, ou seja, o ponto de resolução principal da CA. A exigência cobre a cadeia completa: da raiz DNS ao domínio alvo, cada assinatura RRSIG deve ser verificada.

O que o ballot não muda

Domínios sem DNSSEC não são afetados. Se o seu domínio não publica um DS record no TLD, a CA continua a DCV exatamente como antes. SC-085v2 não torna DNSSEC obrigatório para obter um certificado. Ele simplesmente exige que as CA respeitem DNSSEC quando está implantado.

Timeline de implantação

As principais CA anteciparam o prazo:

• DigiCert: validação DNSSEC ativa desde 3 de março de 2026, com o código de erro dns_sec_validation_error para domínios em falha
• Sectigo: implantação concluída em 5 de março de 2026
• Prazo oficial: 15 de março de 2026, todas as CA devem estar em conformidade

A exceção para a validação por email (SC-094v2)

O Ballot SC-094v2, adotado separadamente, concede uma exceção temporária para a DCV por email. Os métodos de validação por email (BR seções 3.2.2.4.2 e 3.2.2.4.4) estão em processo de descontinuação e recebem um prazo adicional antes que a validação DNSSEC lhes seja imposta. Essa exceção reconhece que esses métodos históricos serão progressivamente abandonados.

Como o DNSSEC protege a emissão de certificados

O DNSSEC adiciona uma camada de autenticação criptográfica ao DNS. Cada registro DNS é acompanhado por uma assinatura digital (RRSIG) verificável pelo resolvedor. A confiança se propaga do trust anchor IANA (a KSK raiz) até o domínio alvo por meio de uma cadeia de DS records e DNSKEY. Para uma explicação detalhada desse mecanismo, consulte o nosso guia sobre a cadeia de confiança DNSSEC.

Aplicação concreta à DCV

Vamos a um cenário concreto. Um sistema automatizado solicita um certificado para captaindns.com via ACME (DNS-01). O cliente ACME publica um registro TXT em _acme-challenge.captaindns.com com um token único.

A CA consulta o DNS para recuperar esse TXT. Com SC-085v2, o resolvedor da CA agora realiza uma validação DNSSEC completa:

1. Ele verifica que a zona captaindns.com publica um DS record no TLD .com
2. Ele recupera as DNSKEY da zona captaindns.com e verifica que o DS corresponde ao hash da KSK
3. Ele verifica que o RRSIG do TXT _acme-challenge.captaindns.com está assinado por uma ZSK cuja DNSKEY está ela mesma assinada pela KSK
4. Ele percorre a cadeia até a raiz IANA para validar cada elo

Se todas as assinaturas forem válidas, o resolvedor retorna a resposta com o flag AD (Authenticated Data). A CA pode então prosseguir com a DCV com a garantia de que a resposta DNS não foi falsificada.

Os três cenários após SC-085v2

Cenário 1: domínio sem DNSSEC. O seu domínio não publica um DS record no TLD. O resolvedor da CA constata a ausência de DNSSEC e prossegue com a DCV clássica, sem validação criptográfica. Nenhuma mudança em relação a antes do SC-085v2.

Cenário 2: DNSSEC válido (SECURE). O seu domínio publica DNSSEC e a cadeia de confiança está intacta. O resolvedor valida cada assinatura, obtém o flag AD, e a CA prossegue com a DCV com a certeza de que a resposta é autêntica. É o comportamento ideal: você se beneficia de uma proteção completa contra spoofing DNS durante a emissão do seu certificado.

Cenário 3: DNSSEC quebrado (BOGUS). O seu domínio publica um DS record no TLD, mas a validação falha. O DS não corresponde à DNSKEY, os RRSIG estão expirados, ou um algoritmo não suportado é utilizado. O resolvedor marca a resposta como BOGUS e retorna um SERVFAIL. A CA não consegue obter uma resposta DNS válida e recusa emitir o certificado.

O RFC 4035 seção 5 define o algoritmo de validação que os resolvedores (e portanto as CA) devem implementar. As CA em conformidade com SC-085v2 aplicam esse algoritmo na sua Primary Network Perspective para toda consulta DCV e CAA.

MPIC e DNSSEC: a defesa em profundidade

SC-085v2 não funciona isoladamente. Ele faz parte de uma estratégia de defesa em profundidade iniciada pelo CA/Browser Forum, cujo primeiro pilar é MPIC (Multi-Perspective Issuance Corroboration).

MPIC: a proteção de rede

O Ballot SC-067v3, em vigor desde março de 2025, exige que as CA validem a DCV a partir de pelo menos duas perspectivas de rede geograficamente separadas (mínimo de 500 km). Na prática, quando você solicita um certificado, a CA lança a verificação DNS a partir de vários pontos de presença ao redor do mundo.

O objetivo: combater ataques BGP localizados. Se um atacante desvia o tráfego BGP em uma região, as perspectivas de rede situadas em outras regiões receberão a resposta DNS legítima. A CA detecta a inconsistência e recusa emitir o certificado.

DNSSEC: a proteção no nível do protocolo

SC-085v2 adiciona uma segunda camada de proteção, desta vez no nível do próprio protocolo DNS. O DNSSEC garante a autenticidade das respostas DNS por meio de assinaturas criptográficas. Mesmo que o atacante controle o caminho de rede, ele não pode forjar uma resposta DNS válida sem possuir as chaves privadas da zona.

Por que ambos são necessários

MPIC e DNSSEC abordam vetores de ataque diferentes e se complementam:

• MPIC sozinho não protege se o servidor DNS autoritativo for comprometido ou se o atacante envenenou os caches DNS de forma global. Todas as perspectivas de rede receberiam a mesma resposta falsa.
• DNSSEC sozinho não protege se o resolvedor da CA não validar DNSSEC (o que não é mais possível com SC-085v2 quando DNSSEC está publicado), ou se o ataque visa o caminho de rede sem modificar as respostas DNS.
• Juntos: MPIC cobre o vetor de rede (BGP hijacking localizado), DNSSEC cobre o vetor DNS (spoofing, cache poisoning). Um atacante precisaria simultaneamente comprometer a cadeia DNSSEC e desviar o tráfego de todas as perspectivas de rede da CA para obter um certificado fraudulento.

Impacto operacional: quem é afetado?

O impacto do SC-085v2 depende diretamente da sua situação DNSSEC. Aqui estão os quatro perfis típicos e suas consequências.

DNSSEC ativo e corretamente configurado

Se o seu domínio publica DNSSEC com uma cadeia de confiança intacta, SC-085v2 não muda nada no seu fluxo operacional. Suas renovações de certificados continuam funcionando normalmente. A única diferença: a CA agora valida criptograficamente as respostas DNS, o que reforça a segurança da emissão. Você está protegido contra ataques de BGP hijacking e DNS spoofing direcionados à DCV.

É o cenário ideal. O seu investimento em DNSSEC compensa duplamente: proteção DNS clássica e proteção da emissão de certificados.

DNSSEC ativo, mas mal configurado

Este é o cenário de risco. O seu domínio publica um DS record no TLD, o que indica aos resolvedores que a zona está assinada. Mas a configuração DNSSEC é inválida. Várias causas frequentes:

• DS record desatualizado após uma migração DNS. Você mudou de provedor DNS, o novo provedor gerou novas chaves DNSSEC, mas o DS record no registrar ainda aponta para as chaves antigas. A cadeia está quebrada.
• RRSIG expirados. As assinaturas DNSSEC têm uma duração limitada (tipicamente 7 a 30 dias). Se o processo de reassinatura automática falhar silenciosamente, os RRSIG expiram e a zona se torna BOGUS.
• Rotação de KSK/ZSK incorreta. Uma rotação de chave mal sequenciada (nova chave publicada antes da propagação do DS, ou antigo DS removido antes da propagação da nova chave) quebra temporariamente a cadeia.
• Algoritmo não suportado. Alguns algoritmos antigos (RSA-SHA1, DSA) estão descontinuados. Se a sua zona utiliza um algoritmo que o resolvedor da CA não suporta, a validação falha.

Antes do SC-085v2, uma configuração DNSSEC quebrada provocava SERVFAIL para resolvedores validadores (1.1.1.1, 8.8.8.8, 9.9.9.9), mas não impedia a emissão de certificados, pois os resolvedores das CA não validavam sistematicamente DNSSEC. Agora, um DNSSEC BOGUS bloqueia a DCV e o certificado é recusado.

Sem DNSSEC implantado

Se o seu domínio não publica um DS record no TLD, SC-085v2 não tem nenhum impacto imediato. A CA constata a ausência de DNSSEC e prossegue com a DCV clássica. Suas renovações continuam funcionando exatamente como antes.

No entanto, a adoção de DNSSEC se torna cada vez mais estratégica. SC-085v2 cria um incentivo forte: domínios com DNSSEC válido se beneficiam de uma DCV protegida contra spoofing. Domínios sem DNSSEC permanecem vulneráveis aos mesmos ataques descritos na seção anterior. A migração do Microsoft 365 para o domínio mx.microsoft com DNSSEC automático, a chegada do DMARCbis que recomenda DNSSEC para a proteção dos registros MX, e o SC-085v2 convergem para um ecossistema em que DNSSEC se torna o padrão esperado.

Certificados automatizados via ACME

Este perfil merece atenção especial. O método DNS-01 é amplamente utilizado por sistemas ACME para validar certificados, em particular para certificados wildcard. Se a sua infraestrutura automatiza a renovação via certbot, acme.sh ou um operador Kubernetes como cert-manager, o fluxo é inteiramente não interativo.

O risco: um DNSSEC quebrado provoca uma falha silenciosa. A renovação ACME falha, o certificado expira, e o seu site se torna inacessível via HTTPS. Nenhuma intervenção humana está no circuito para detectar o problema antes da expiração.

A DigiCert introduziu o código de erro dns_sec_validation_error para sinalizar especificamente uma falha de validação DNSSEC durante a DCV. Se você receber esse erro, o problema está na sua configuração DNSSEC, não no seu registro de validação.

Adoção DNSSEC: panorama em março de 2026

Entender o nível de adoção atual permite medir a amplitude da mudança introduzida pelo SC-085v2.

Validação global

Aproximadamente 35% das consultas DNS mundiais passam por resolvedores que validam DNSSEC. Esse número reflete a adoção do lado dos resolvedores: os grandes resolvedores públicos (1.1.1.1, 8.8.8.8, 9.9.9.9) todos validam DNSSEC. Os resolvedores de ISP são mais heterogêneos, mas a tendência é de alta.

Taxa de assinatura por TLD

A adoção de DNSSEC pelos domínios (do lado da zona, não do lado do resolvedor) varia consideravelmente conforme os TLD:

• .nl (Países Baixos): cerca de 60% dos domínios assinados. Líder mundial graças ao incentivo ativo do SIDN (registro do .nl).
• TLD nórdicos (.se, .dk, .no): mais de 50% de adoção, impulsionada por registros proativos.
• .com: cerca de 4 a 5% dos domínios assinados. O volume é enorme em valor absoluto, mas a porcentagem permanece baixa.
• 92% dos TLD possuem um DS record na zona raiz, o que significa que a infraestrutura de assinatura existe no nível do TLD.

A assimetria entre infraestrutura e adoção

A infraestrutura de validação DNSSEC está amplamente implantada. Os resolvedores estão prontos. Os TLD estão assinados. Mas a assinatura das zonas individuais permanece minoritária. Essa assimetria se explica pela complexidade percebida da implantação DNSSEC e pela ausência, até agora, de consequências visíveis para domínios não assinados.

SC-085v2 muda essa dinâmica. Pela primeira vez, há uma consequência concreta em publicar DNSSEC com uma configuração inválida. E há um benefício mensurável em publicar DNSSEC corretamente: a proteção da DCV.

O efeito dominó é previsível. SC-085v2, combinado com a migração do Microsoft 365 para mx.microsoft com DNSSEC automático e as recomendações do DMARCbis, vai acelerar a adoção de DNSSEC nos próximos trimestres.

Guia prático: verificar e corrigir a sua configuração DNSSEC

Antes da sua próxima renovação de certificado, verifique se a sua configuração DNSSEC está intacta. Aqui estão os comandos e etapas essenciais.

Verificação rápida com dig

Verificar o flag AD (Authenticated Data):

dig +dnssec SOA captaindns.com

Na seção flags:, procure por ad. Sua presença significa que o resolvedor validou a cadeia DNSSEC com sucesso. Sua ausência indica que o DNSSEC não está implantado ou que a validação falhou.

Verificar os DS records no TLD:

dig DS captaindns.com +short

Este comando retorna o(s) DS record(s) publicado(s) pelo registrar no TLD. Se a resposta estiver vazia, o seu domínio não publica DNSSEC. Se houver DS records presentes, verifique se correspondem às chaves atuais da sua zona.

Verificar as chaves DNSKEY:

dig DNSKEY captaindns.com +short

Você deve ver no mínimo duas chaves: uma com o flag 256 (ZSK) e uma com o flag 257 (KSK). O hash da KSK (flag 257) deve corresponder ao DS record publicado no TLD.

Distinguir um problema DNSSEC de outro problema DNS:

dig captaindns.com +cd

O flag +cd (Checking Disabled) desativa a validação DNSSEC. Se a consulta funcionar com +cd, mas falhar sem ele (SERVFAIL), o problema é DNSSEC.

O que fazer se o DNSSEC estiver quebrado

Se as suas verificações revelarem um problema, aqui estão as ações corretivas por ordem de prioridade:

Verificar o DS record no registrar. Acesse a interface do seu registrar e compare o DS record publicado com a DNSKEY (flag 257) da sua zona. Se você migrou de provedor DNS, o DS deve apontar para a KSK do novo provedor.

Verificar os RRSIG na zona. As assinaturas têm uma data de expiração. Se o seu provedor DNS tiver um problema de reassinatura, os RRSIG podem estar expirados. Entre em contato com o seu provedor DNS ou verifique os logs de assinatura se você gerencia DNSSEC internamente.

Verificar o algoritmo. Os algoritmos RSA-SHA1 e DSA estão descontinuados. Prefira ECDSAP256SHA256 (algoritmo 13) ou ECDSAP384SHA384 (algoritmo 14).

Para um diagnóstico detalhado dos erros SERVFAIL relacionados ao DNSSEC, consulte o nosso guia dedicado: resolver SERVFAIL após DNSSEC. Se você precisa ativar DNSSEC pela primeira vez, siga o nosso guia de ativação DNSSEC passo a passo.

Checklist pré-renovação de certificado

Antes de cada renovação de certificado em um domínio com DNSSEC:

• O DS record no registrar corresponde à KSK ativa da zona
• Os RRSIG não estão expirados (verificar o inception e a expiração com dig +dnssec)
• O algoritmo utilizado é suportado (ECDSAP256SHA256 recomendado)
• O resolvedor retorna o flag AD para o seu domínio
• O monitoramento DNSSEC está em vigor e envia alertas em caso de ruptura de cadeia
• Um dry-run ACME foi executado com sucesso no domínio em questão

SC-081 e a aceleração das renovações

O Ballot SC-081, adotado pelo CA/Browser Forum, reduz progressivamente a duração máxima dos certificados TLS:

Data de aplicação	Duração máxima
Março de 2026	200 dias
Março de 2027	100 dias
Março de 2029	47 dias

Essa redução tem um impacto direto na criticidade do SC-085v2. Quanto menor a duração dos certificados, mais frequentes são as renovações. E quanto mais frequentes as renovações, mais rápido um DNSSEC quebrado será detectado, mas também mais bloqueante ele será.

Com certificados de 200 dias, um problema DNSSEC que dura uma semana atrasa uma renovação. Com certificados de 47 dias, um problema DNSSEC de alguns dias pode provocar a expiração do certificado antes que a renovação seja bem-sucedida. A margem de erro se reduz drasticamente.

Com 47 dias, a automação ACME se torna indispensável. Nenhuma organização consegue gerenciar manualmente renovações a cada seis semanas em um parque de domínios. E um pipeline ACME automatizado que falha silenciosamente por causa de um DNSSEC quebrado é um cenário de incidente grave.

A recomendação é clara: implante um monitoramento DNSSEC contínuo em todos os seus domínios com certificados TLS. Configure alertas sobre a expiração dos RRSIG (pelo menos 7 dias antes da expiração) e sobre a correspondência DS/DNSKEY. Integre a verificação DNSSEC no seu pipeline de renovação ACME, antes da solicitação de certificado.

Plano de ação: preparar a sua infraestrutura

1. Verificar o estado DNSSEC de todos os seus domínios com o DNSSEC Checker do CaptainDNS
2. Corrigir as cadeias quebradas: DS record ausente, assinatura expirada, algoritmo incompatível
3. Auditar os certificados ativos: listar os domínios DNSSEC com certificados a renovar nos próximos 90 dias
4. Configurar o monitoramento: alertas sobre expiração de RRSIG e expiração de certificado
5. Testar a renovação: executar um dry-run ACME nos domínios DNSSEC
6. Documentar: adicionar a verificação DNSSEC ao seu runbook de renovação

FAQ

O Ballot SC-085v2 torna DNSSEC obrigatório para obter um certificado TLS?

Não. SC-085v2 exige que as CA validem DNSSEC quando presente, mas não torna DNSSEC obrigatório. Se o seu domínio não publica um DS record no TLD, a CA prossegue com a DCV clássica sem validação DNSSEC. Você pode obter um certificado TLS sem DNSSEC, exatamente como antes.

O que acontece se o meu DNSSEC estiver quebrado durante a renovação automática?

A renovação falha. A CA retorna um erro do tipo dns_sec_validation_error (na DigiCert) ou um SERVFAIL. O cliente ACME não consegue completar a validação DNS-01 e o certificado não é renovado. Se o problema persistir até a expiração do certificado atual, o seu site se torna inacessível via HTTPS. Por isso, um monitoramento DNSSEC com alertas é indispensável.

Quais CA são afetadas pelo SC-085v2?

Todas as CA publicamente aprovadas (ou seja, cujo certificado raiz está incluído nos armazéns de confiança dos navegadores). Isso inclui DigiCert, Sectigo, Let's Encrypt, GlobalSign, Entrust, HARICA, SwissSign e todas as outras CA em conformidade com os Baseline Requirements do CA/Browser Forum. As CA privadas (internas a uma organização) não são afetadas.

O Let's Encrypt já validava DNSSEC?

O Let's Encrypt já utilizava resolvedores validadores DNSSEC (Unbound) na sua infraestrutura. Na prática, um domínio com DNSSEC BOGUS já podia falhar a validação no Let's Encrypt. SC-085v2 formaliza essa exigência nos Baseline Requirements e a estende a todas as CA, não apenas aquelas que haviam escolhido validar DNSSEC.

Qual é a diferença entre MPIC (SC-067) e SC-085v2?

MPIC (SC-067) protege a DCV no nível de rede, verificando a partir de vários pontos geográficos. Ele detecta ataques BGP localizados. SC-085v2 protege a DCV no nível DNS, verificando as assinaturas DNSSEC. Ele detecta respostas DNS falsificadas. Os dois são complementares: MPIC cobre o vetor BGP, DNSSEC cobre o vetor DNS.

O meu certificado atual será revogado se o DNSSEC quebrar após a emissão?

Não. SC-085v2 diz respeito apenas à validação no momento da emissão. Um certificado já emitido permanece válido até a sua expiração, mesmo que o DNSSEC quebre após a emissão. No entanto, a próxima renovação falhará enquanto o DNSSEC estiver BOGUS.

Como saber se o meu domínio publica DNSSEC?

Execute dig DS captaindns.com +short (substitua pelo seu domínio). Se o comando retornar um ou mais registros DS, o seu domínio publica DNSSEC. Se a resposta estiver vazia, o DNSSEC não está ativado. Você também pode usar o DNSSEC Checker do CaptainDNS para um diagnóstico completo incluindo a validação da cadeia de confiança.

O SC-085v2 afeta certificados wildcard?

Sim. Os certificados wildcard são validados via DNS-01 (o único método ACME compatível com wildcard). A CA consulta o DNS para verificar o TXT _acme-challenge e aplica a validação DNSSEC nessa consulta. Se o DNSSEC estiver BOGUS para o seu domínio, o certificado wildcard não será emitido.

Qual é a relação com o Ballot SC-081 sobre a redução da duração dos certificados?

SC-081 reduz a duração máxima dos certificados TLS (200 dias em 2026, 100 dias em 2027, 47 dias em 2029). Certificados mais curtos implicam renovações mais frequentes. Cada renovação aciona uma DCV, e cada DCV agora inclui a validação DNSSEC (SC-085v2). Um DNSSEC quebrado bloqueia, portanto, mais frequentemente a renovação, com menos margem antes da expiração.

Devo ativar DNSSEC para me beneficiar da proteção do SC-085v2?

Sim. SC-085v2 protege apenas domínios que publicam DNSSEC. Sem DNSSEC, a CA não pode verificar a autenticidade das respostas DNS e a DCV permanece vulnerável a spoofing. Ativar DNSSEC no seu domínio é a única forma de se beneficiar dessa proteção reforçada durante a emissão de certificados.

Glossário

• CA (Certificate Authority): autoridade de certificação habilitada a emitir certificados TLS. As CA públicas estão incluídas nos armazéns de confiança dos navegadores e sujeitas aos Baseline Requirements do CA/Browser Forum.
• DCV (Domain Control Validation): processo pelo qual uma CA verifica que o solicitante de um certificado realmente controla o domínio. Métodos comuns: DNS-01, HTTP-01, email.
• CA/Browser Forum: consórcio que reúne as CA e os editores de navegadores. Ele define os Baseline Requirements, o marco normativo que todas as CA públicas devem respeitar.
• MPIC (Multi-Perspective Issuance Corroboration): mecanismo imposto pelo Ballot SC-067, obrigando as CA a validar a DCV a partir de pelo menos duas perspectivas de rede geograficamente distantes para combater o BGP hijacking.
• BOGUS: estado interno do resolvedor DNSSEC quando a validação criptográfica falha. Um domínio BOGUS provoca um SERVFAIL para o cliente. Após SC-085v2, um domínio BOGUS também bloqueia a emissão de certificados.
• ACME (Automatic Certificate Management Environment): protocolo padronizado (RFC 8555) para a automação da emissão e renovação de certificados TLS. Utilizado por Let's Encrypt, certbot, acme.sh e cert-manager.
• Baseline Requirements (BR): documento normativo do CA/Browser Forum que define as exigências mínimas para a emissão de certificados TLS pelas CA públicas. SC-085v2 modifica os BR para exigir a validação DNSSEC.

Fontes

1. Ballot SC-085v2: Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
2. Ballot SC-067v3: Require Multi-Perspective Issuance Corroboration (CA/Browser Forum)
3. DigiCert: Validating DNSSEC for Domain Control and CAA Checks
4. RFC 4035: Protocol Modifications for DNS Security Extensions (IETF)
5. DNSSEC Deployment Statistics (APNIC)