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
Links para Testar sua configuração DANE
Analisador de Conectividade Remota da MS
DANE/TLSA validator for inbound SMTP services
Mantendo a mesma chave ou renovar sempre?
Se nenhuma alteração for feita a chave DANE será sempre diferente depois de renovar o certificado. Faz sentido, uma vez que o certificado é novo, portanto a chave DANE baseada no novo certificado também será renovada.
Mas em alguns casos a renovação permanente da chave DANE poder ser um problema. Se você quiser manter o DANE sempre igual, basta configurar o lets encrypt para usar sempre a mesma chave privada para renovar o certificado.
Tenha me mente que podem haver considerações de segurança por renovar o certificado mantendo sempre a mesma chave privada.
A alteração deve ser feita dentro dos arquivos de configuração de renovação para cada domínio em:
/etc/letsencrypt/renewal/dominio.conf
Edite o arquivo e adicione a linha abaixo na sessão [renewalparams]
reuse_key = True
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
