O sistema de autoridade certificadora tem um problema fundamental: qualquer uma dentre centenas de CAs pode emitir um certificado para qualquer domínio. Se uma CA for comprometida, hackeada ou coagida por um governo, ela pode emitir certificados fraudulentos que navegadores e servidores de email irão confiar. Isso já aconteceu — DigiNotar, Comodo, WoSign — e vai acontecer de novo.
Para navegação na web, desenvolvemos mitigações: logs de Certificate Transparency, CAA records, supervisão de vendors de navegador. Mas o email historicamente é mais vulnerável. Servidores de email que se conectam entre si não têm o mesmo ecossistema de proteções.
DANE—DNS-based Authentication of Named Entities—oferece uma abordagem totalmente diferente. Em vez de confiar em autoridades certificadoras, você publica suas informações de certificado diretamente no DNS, protegido por DNSSEC. O servidor remetente não precisa confiar em nenhuma CA; ele só precisa confiar no DNS, o que já faz para todo o resto.
O problema que o DANE resolve
Quando seu servidor de email se conecta a outro servidor para entregar mensagens, ele precisa verificar que está falando com o servidor certo. Sem verificação, um atacante poderia interceptar a conexão e se passar pelo destino.
A verificação TLS tradicional usa autoridades certificadoras. O servidor de destino apresenta um certificado, seu servidor verifica se ele foi assinado por uma CA confiável e, se sim, prossegue. Mas esse modelo de confiança tem fraquezas.
Primeiro, há CAs demais confiadas. Seu servidor provavelmente confia em centenas de autoridades certificadoras por padrão. Qualquer uma delas poderia emitir um certificado para qualquer domínio. Uma CA comprometida em um país poderia emitir certificados usados para interceptar email no mundo todo.
Segundo, a criptografia oportunista é vulnerável a ataques de downgrade. Se um atacante puder interceptar a conexão inicial, ele pode remover a oferta de TLS e forçar comunicação em texto claro. Os servidores não sabem que deveriam exigir criptografia.
DANE resolve ambos os problemas. Ele permite que os donos de domínios especifiquem exatamente quais certificados são válidos para seus servidores, publicados em registros DNS assinados criptograficamente. Não é necessário confiar em CAs. E como a política está no DNS, servidores remetentes sabem que devem exigir criptografia antes mesmo de se conectar.
Como o DANE funciona
DANE usa um tipo especial de registro DNS chamado TLSA (Transport Layer Security Authentication). Esse registro especifica qual certificado o servidor deve apresentar, publicado em um local específico no DNS.
O nome DNS segue um padrão: _port._protocol.hostname. Para um servidor de email em mail.example.com usando SMTP (porta 25), o registro TLSA ficaria em _25._tcp.mail.example.com. Essa precisão permite especificar certificados diferentes para serviços diferentes no mesmo host.
O registro TLSA contém vários campos. O campo usage especifica como validar o certificado — se deve checá-lo contra uma CA, usá-lo diretamente ou usá-lo como âncora de confiança. O campo selector indica se você está especificando o certificado completo ou apenas a chave pública. O campo matching type especifica se você está incluindo os dados completos ou um hash.
A maioria das implantações de DANE para email usa o tipo de usage 3 (DANE-EE), que significa "este é o certificado ou a chave pública exata que o servidor apresentará, confie diretamente". Isso contorna completamente o sistema de CA — você está dizendo aos remetentes exatamente o que esperar.
DNSSEC: a base
DANE só funciona com DNSSEC. Sem DNSSEC, um atacante que consiga manipular respostas DNS poderia publicar registros TLSA falsos apontando para seus próprios certificados. DNSSEC fornece a autenticação criptográfica que torna o DANE confiável.
DNSSEC adiciona assinaturas digitais aos registros DNS. Cada registro é assinado pela chave da zona, que por sua vez é autenticada pela chave da zona pai, até a raiz. Um servidor remetente pode verificar toda a cadeia, garantindo que o registro TLSA que recebeu é autêntico.
Isso é ao mesmo tempo a força e a limitação do DANE. DNSSEC fornece autenticação forte sem confiar em CAs de terceiros. Mas a implantação de DNSSEC ainda é incompleta. Muitos domínios não têm DNSSEC, e muitos resolvedores DNS não validam. Se seu domínio não tem DNSSEC, você não pode usar DANE.
Configurando o DANE para email
Implementar DANE requer várias etapas, e a ordem importa.
Primeiro, garanta que seu domínio tenha DNSSEC. Isso normalmente significa trabalhar com seu provedor de DNS para ativar a assinatura e publicar registros DS na zona pai. Muitos provedores de DNS hoje suportam DNSSEC, mas a configuração varia.
Segundo, obtenha ou identifique o certificado que seu servidor de email usa. Você precisa do certificado completo ou de sua chave pública, dependendo do tipo de selector escolhido. Usar a chave pública (selector 1) costuma ser preferível porque sobrevive a renovações de certificado enquanto você mantiver a mesma chave.
Terceiro, gere o registro TLSA. Você fará o hash do certificado ou da chave pública usando SHA-256 (matching type 1) e formatará isso como um registro TLSA. Existem ferramentas para automatizar isso — você não precisa fazer o hashing manualmente.
Quarto, publique o registro TLSA no DNS. Lembre-se da convenção de nomenclatura: _25._tcp.yourmailserver.example.com para SMTP. O registro precisa estar no lugar e assinado por DNSSEC antes que os remetentes o utilizem.
Por fim, teste minuciosamente. Falhas de DANE podem causar falhas de entrega de email, então verifique se tudo funciona antes de depender disso. Várias ferramentas online conseguem checar sua configuração DANE e apontar problemas.
DANE vs MTA-STS
DANE e MTA-STS resolvem problemas semelhantes — ambos previnem ataques de downgrade de TLS e substituição de certificados. Mas funcionam de maneira diferente e têm diferentes trade-offs.
DANE requer DNSSEC, mas fornece garantias de segurança mais fortes. A autenticação de certificado é criptográfica e não depende de terceiros além da hierarquia do DNS. Se o DNSSEC for comprometido, você tem problemas maiores do que segurança de email.
MTA-STS não requer DNSSEC, mas exige hospedar um arquivo de política via HTTPS. Ele depende da Web PKI (certificate authorities) para autenticar o arquivo de política. Isso é, arguivelmente, mais fraco que DNSSEC, mas é mais implantável hoje.
Na prática, MTA-STS teve adoção mais ampla porque a implantação de DNSSEC ainda é limitada. Google, Microsoft e a maioria dos grandes provedores de email suportam MTA-STS. O suporte a DANE é menos universal, embora esteja crescendo.
Se você tem DNSSEC, implementar DANE oferece a proteção mais forte. Se você não tem DNSSEC e não consegue obtê-lo facilmente, MTA-STS é a escolha prática. Implementar ambos oferece defesa em profundidade — remetentes que suportam DANE irão usá-lo, outros recorrerão ao MTA-STS.
Erros comuns com DANE
O problema de DANE mais frequente são registros TLSA que não correspondem ao certificado real. Isso acontece quando certificados são renovados sem atualizar o DNS, ou quando os dados de certificado errados são publicados inicialmente. O resultado são falhas de entrega — servidores remetentes veem uma incompatibilidade e se recusam a entregar.
Automação ajuda aqui. Se você usa Let's Encrypt ou outro sistema automatizado de certificados, integre as atualizações de registros TLSA ao seu processo de renovação. Algumas ferramentas fazem isso automaticamente; outras exigem scripts.
Outro problema comum são configurações de DNSSEC com erro. DANE requer DNSSEC válido por toda a cadeia. Se suas assinaturas DNSSEC expirarem, ou se houver erro de configuração, a validação do DANE falha. Monitore continuamente o status do DNSSEC.
Publicar registros TLSA antes de o DNSSEC estar totalmente implantado também causa problemas. Remetentes que suportam DANE tentarão validar, falharão porque o DNSSEC não está funcionando, e podem rejeitar o email. Faça o DNSSEC funcionar primeiro, verifique minuciosamente, depois adicione os registros TLSA.
Vale a pena implementar DANE?
Para organizações com requisitos de segurança elevados e infraestrutura de DNSSEC existente, DANE é o padrão ouro para segurança de transporte de email. Ele fornece autenticação criptográfica sem confiar em autoridades certificadoras, o que importa se você está preocupado com atacantes de Estado-nação ou comprometimento de CA.
Para a maioria das organizações, a resposta prática depende do DNSSEC. Se você já tem DNSSEC (talvez por outros motivos), adicionar DANE é relativamente simples e fornece benefícios reais de segurança. Se você não tem DNSSEC, o esforço para implementá-lo apenas por causa do DANE pode não se justificar — MTA-STS fornece proteção semelhante com menos infraestrutura.
O ecossistema de email está gradualmente caminhando para exigir criptografia de transporte. Seja via DANE, MTA-STS ou ambos, a direção é clara. Implementar um ou ambos agora coloca você à frente da curva e protege seu email contra interceptação.
Frequently asked questions
Posso usar DANE sem DNSSEC?
Não. O DANE depende fundamentalmente do DNSSEC para autenticação. Sem DNSSEC, um atacante poderia forjar registros TLSA, derrotando todo o propósito. DNSSEC é pré-requisito, não opcional.
O que acontece se meu registro TLSA estiver errado?
Servidores remetentes que suportam DANE não conseguirão entregar email para você. Eles verão uma incompatibilidade entre o registro TLSA e seu certificado real e se recusarão a conectar. Por isso testes são críticos antes da implantação.
Os principais provedores de email suportam DANE?
O suporte está crescendo, mas não é universal. Alguns provedores europeus e organizações focadas em segurança suportam DANE. O Google indicou suporte em alguns contextos. Verifique a compatibilidade atual antes de depender de DANE para caminhos de email críticos.
Devo usar DANE ou MTA-STS?
Se você tem DNSSEC, use DANE — é mais seguro. Se você não tem DNSSEC, use MTA-STS. Se você tem DNSSEC e quer proteção máxima, implemente ambos. Eles são complementares, não concorrentes.