DANE – Autenticação Baseada em DNS para Nomes de Entidades

Hoje tive minha primeira ocorrência de mensagem não recebida por erro de DANE: uma conta de um domínio hospedado no outlook.com da Miscrosoft nos enviou várias mensagens que nunca chegavam. Sem recebimento do meu lado e sem mensagem de erro do lado deles, as mensagens simplesmente sumiam.

DANE – DNS-based Authentication of Named Entities é um nome longo, mas o conceito é simples: como garantir que o certificado usado para a conexão TLS com seu servidor é, de fato, o certificado correto?

Seguindo a mesma lógica do SPF e DKIM, onde um registro DNS avaliza a autenticidade ou origem do e-mail, o DANE se utiliza desse registro publicado para validar a autinticidade do certificado utilizado na coxão SMTP.

A diferença é que a validação do DANE é utilizada durante o envio da mensagem, ou seja, o servidor de envio, ao conectar no seu servidor avalia se existe um registro DNS do tipo TLSA e se não tiver, ou se for inválido, ele simplesmente não faz estabelece a conexão, e portanto, não há envio.

O sinistro é que ao não estabelecer a conexão, o destino não tem logs do contato e não tem como saber o que está acontecendo. E a origem também fica às cegas, pois na maioria dos casos o erro não é retornado para o emissor.

Sem logs de ambos os lados e com o servidor do emissor sem acusar erros paira a dúvida sobre onde esta o problema e como resolver.

Diagnóstico

Como não tínhamos logs do nosso lado, solicitamos ao domínio hospedado no outlook.com que aciona-se o suporte e pedisse pelos logs de erros de envio. Bingo!

Server at RO1P152MB3787.LAMP152.PROD.OUTLOOK.COM returned ‘550 5.7.323 tlsa-invalid: The domain failed DANE validation(450 4.7.323 tlsa-invalid: The domain failed DANE validation)’
Server at dominio.com.br(111.111.11.11) returned ‘450 4.7.323 tlsa-invalid: The domain failed DANE validation [Message=450 4.7.323 tlsa-invalid: The domain failed DANE validation] [LastAttemptedServerName=dominio.com.br] [LastAttemptedIP=111.111.11.11:25] [BN8NAM12FT054.eop-nam12.prod.protection.outlook.com](450 4.7.323 tlsa-invalid: The domain failed DANE validation)’

Veja as parte em negrito onde o diagnóstico dexa clara a falha na validação DANE.

Como resolver?

O problema se resolve com uma simples entrada TLSA no DNS. Mas esse registro é extraído do seu certificado, portanto, sempre que seu certificado for renovado, esse registro DNS tem que ser gerado de novo e publicado de novo.

Sugerimos publicar dois registros TLSA: um para o dominio puro e outro para o hostname do MX.

Abaixo esta o comando para extrair o registro DAME para o certificado gerado usando Lets Encrypt, supondo que o primeiro domínio de sua lista seja webmail.dominio.com.br e seu MX seja mail.dominio.com.br

printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' mail.dominio.com.br $(openssl x509 -in /etc/letsencrypt/live/webmail.dominio.com.br/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')

printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' dominio.com.br $(openssl x509 -in /etc/letsencrypt/live/webmail.dominio.com.br/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')

Você deverá opter resultados parecidos com estes:

_25._tcp.mail.dominio.com.br. IN TLSA 3 1 1 6713df4659ea22c26d27fe539bffeecc3ece4500e6e992feff2a208af2d9607b

_25._tcp.dominio.com.br. IN TLSA 3 1 1 6713df4659ea22c26d27fe539bffeecc3ece4500e6e992feff2a208af2d9607b

Publique os dois no seu DNS

Validando as configurações

Depois de publicar no DNS é importante testar se esta tudo correto.

Primeiro uso o dig para ter certeza de que a publicação do novo registro TLSA foi feita com os comandos abaixo:

dig _25._tcp.dominio.com.br TLSA

dig _25._tcp.mail.dominio.com.br TLSA

Em seguida use o link abaixo para testar

DANE/TLSA validator for inbound SMTP services

Observações importantes

Ao que tudo parece a exigência do DAME é seletiva. Temos vários servidores e domínios sem DAME que funcionam muito bem recebendo mensagens do hotmail.com e de todos os outros provedores.

Suspeito que o DAME esta sendo exigidi dos dompinios que já tem DNSSEC, incluíndo, portanto todos os órgãos públicos e aqueles domínios comerciais e pessoais que já tenham o DNSSEC ativado.

Acredito que é apenas uma questão de tempo até que o DNSSEC e o DAME façam parte da lista de registros DNS obrigatórios para se ter um servidor de e-mail compatível com os grandes provedores.

Links importantes

Recomendo demais a leitura dos materiais abaixo para ter uma clareza maior sobre o que é o DAME e como ele funciona.

What is DANE – da Infoblox

Como funciona a autenticação baseada em DNS SMTP de entidades nomeadas (DANE) – da Microsoft