Porque usar um validador offline
Um registo TLSA mal formado é ignorado sem aviso pelos MTAs conformes. Acredita que o seu deploy DANE protege o seu fluxo SMTP de entrada; na prática, nenhum servidor emissor verifica nada. A falha é silenciosa até à próxima auditoria, ou até um incidente de entrega que exponha a brecha.
O validador de sintaxe DANE TLSA analisa o seu registo sem publicar nem consultar o DNS. A validação corre nos servidores da CaptainDNS: o registo que cola é enviado para análise. Nada é publicado, não é emitida qualquer consulta DNS e nenhum resolver externo chega a ver o seu rascunho. Esta abordagem a montante cobre quatro casos de uso que a auditoria em tempo real não consegue tratar.
Casos de uso típicos:
- Antes do deploy: validar um rascunho antes da publicação no DNS, para evitar um registo silenciosamente ignorado.
- Saída de gerador: verificar a sintaxe de um registo produzido por uma ferramenta de terceiros, um wiki interno ou um modelo partilhado.
- Depuração offline: reproduzir e corrigir um erro sem mexer no DNS público, por exemplo em pré-produção.
- Revisão de configuração: examinar um registo recebido de um parceiro ou exportado de uma infraestrutura cliente antes de aplicá-lo.
O validador aplica a especificação RFC 6698 sobre a estrutura e a RFC 7671 sobre as restrições operacionais. Nenhuma consulta DNS, nenhum ficheiro remoto descarregado.
Como usar este validador em 3 passos
Passo 1: colar o registo TLSA
Copie o valor do seu registo no campo previsto:
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
Também pode colar a linha completa com o owner name:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
O validador extrai os quatro campos e analisa cada um de forma independente. A análise decorre do lado do servidor, sem qualquer consulta DNS.
Passo 2: ler o veredicto
Os resultados são classificados por gravidade:
- Erro: problema bloqueante, o registo será ignorado ou rejeitado pelos MTAs conformes
- Aviso: combinação não recomendada, funcional mas que expõe a riscos operacionais
- Válido: sintaxe conforme as RFC 6698 e 7671
Cada mensagem inclui o campo afetado, o valor inválido e a correção esperada.
Passo 3: corrigir antes da publicação
Ajuste o seu registo conforme as recomendações. Quando a sintaxe estiver limpa, publique o registo TLSA em _25._tcp.<host-mx> na zona assinada por DNSSEC do host MX, aguarde a propagação e confirme em tempo real com o DANE TLSA Checker.
Validador ou verificador: quando usar cada ferramenta
As duas ferramentas são complementares. Atuam em momentos diferentes do ciclo de vida de um registo TLSA.
| Dimensão | Validador (esta ferramenta) | Verificador |
|---|---|---|
| Momento de uso | Antes da publicação no DNS | Após a publicação |
| Resolução DNS | Nenhuma | Resolução _25._tcp.<mx> em tempo real |
| Verificação DNSSEC | Não | Sim, cadeia completa |
| Comparação do certificado em tempo real | Não | Sim, via STARTTLS na porta 25 |
| Origem do registo | Manual (colado) | DNS público |
| Dados enviados ao servidor | O registo colado | Domínio analisado |
Fluxo de trabalho recomendado:
- Projete ou gere o registo e use o validador para verificar a sintaxe
- Publique o registo TLSA na zona DNSSEC do host MX e aguarde a propagação
- Lance o verificador para confirmar DNSSEC e a correspondência do certificado em tempo real
O validador deteta erros de entrada antes da publicação. O verificador deteta desvios e confirma que o DNS público servido corresponde ao certificado atualmente apresentado via STARTTLS.
Anatomia de um registo TLSA
O registo TLSA contém quatro campos rigorosamente especificados.
Estrutura geral
_25._tcp.mail.captaindns.com. IN TLSA <usage> <selector> <matching> <dados>
| Campo | Valores | Descrição |
|---|---|---|
| Usage | 0-3 | Ancoragem de confiança |
| Selector | 0-1 | Parte do certificado hasheada |
| Matching type | 0-2 | Algoritmo de comparação |
| Dados | hex | Hash ou bloco binário |
Usage (campo 1)
| Valor | Nome | Descrição |
|---|---|---|
| 0 | PKIX-TA | Restrição CA: o certificado deve ser assinado por esta CA E passar na validação PKIX |
| 1 | PKIX-EE | Restrição de certificado: correspondência exata + validação PKIX |
| 2 | DANE-TA | Ancoragem de confiança: qualquer certificado assinado por esta CA é aceite |
| 3 | DANE-EE | Certificado de domínio: correspondência exata, sem validação PKIX |
Recomendação para SMTP: DANE-EE (3). A ancoragem está na sua chave, independentemente de qualquer autoridade externa.
Selector (campo 2)
| Valor | Nome | Descrição |
|---|---|---|
| 0 | Cert | Certificado completo (DER) |
| 1 | SPKI | SubjectPublicKeyInfo (somente chave pública) |
Recomendação: SPKI (1). O registo continua válido enquanto a chave pública for preservada, independentemente das renovações de certificado.
Matching type (campo 3)
| Valor | Nome | Comprimento hex esperado |
|---|---|---|
| 0 | Full | Variável (certificado ou chave brutos) |
| 1 | SHA-256 | 64 caracteres (32 bytes) |
| 2 | SHA-512 | 128 caracteres (64 bytes) |
Recomendação: SHA-256 (1). Suportado universalmente, suficientemente robusto, compacto.
A combinação recomendada para SMTP
3 1 1 é a norma de facto para SMTP DANE.
3 1 1 <sha256-da-spki>
- Usage 3 (DANE-EE): sem dependência de uma CA, ancoragem direta na sua chave
- Selector 1 (SPKI): invariante à renovação de certificado enquanto a chave for preservada
- Matching type 1 (SHA-256): 32 bytes, perfeitamente adequado
As outras combinações são possíveis, mas desaconselhadas:
| Combinação | Estado | Porquê |
|---|---|---|
| 3 1 1 | Recomendada | Padrão SMTP, robusto, invariante às renovações |
| 3 0 1 | Tolerada | Hash sobre o certificado completo, muda a cada renovação |
| 2 0 1 | Aceitável | DANE-TA sobre CA, sem atualização DNS na renovação; o certificado fixado tem de constar da cadeia TLS servida, pelo que convém fixar o intermediário (R10/R11) e não a raiz |
| 2 1 1 | Aceitável | DANE-TA sobre SPKI da CA; a mesma restrição de cadeia, fixando o intermediário efetivamente enviado |
| 3 1 0 | Recusada | Matching type 0 expõe o certificado bruto, tamanho DNS enorme |
| 1 x x | Recusada em SMTP | PKIX-EE raramente implantável em MTAs |
| 0 x x | Recusada em SMTP | PKIX-TA inadequada para SMTP |
O validador sinaliza explicitamente as combinações fora de recomendação e propõe a combinação padrão.
Erros de sintaxe comuns e correções
Usage fora do intervalo
Causa: valor de usage maior que 3.
Correção:
- 4 1 1 2bb183af...
+ 3 1 1 2bb183af...
Selector inválido
Causa: selector diferente de 0 ou 1.
Correção:
- 3 2 1 2bb183af...
+ 3 1 1 2bb183af...
Matching type fora do intervalo
Causa: matching type maior que 2.
Correção:
- 3 1 3 2bb183af...
+ 3 1 1 2bb183af...
Dados hexadecimais inválidos
Causa: caracteres fora do intervalo hex (0-9, a-f, A-F).
Correção:
- 3 1 1 2bg183zf...
+ 3 1 1 2bb183af...
Comprimento de hash incorreto
Causa: o comprimento dos dados não corresponde ao matching type.
Correção SHA-256:
- 3 1 1 2bb183
+ 3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
SHA-256 (matching type 1) exige exatamente 64 caracteres hex. SHA-512 (matching type 2) exige exatamente 128 caracteres.
Combinação usage/selector frágil
Causa: DANE-EE (3) + Cert completo (0) gera um hash que muda a cada renovação de certificado.
Correção recomendada: passar para SPKI (1) para tornar o registo invariante às renovações (com a opção --reuse-key do lado ACME).
- 3 0 1 <hash-do-certificado-completo>
+ 3 1 1 <hash-da-chave-publica>
Owner name incorreto
Causa: registo publicado no apex do domínio em vez do host MX, ou na porta errada.
Correção: _25._tcp.<host-mx> exatamente. Para um MX mail.captaindns.com, é _25._tcp.mail.captaindns.com.
Preparar uma rotação de chave
Vários registos TLSA na mesma zona não são um erro: é até o padrão recomendado para uma rotação de chave sem interrupção.
Procedimento de rotação limpa
- D-7: gere a próxima chave, calcule o seu hash SPKI e publique-o em duplicidade:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-chave-atual>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-chave-seguinte>
-
D-0: execute a rotação de certificado com a nova chave. Os MTAs conformes aceitam a ligação se pelo menos um dos dois registos corresponder ao certificado apresentado.
-
D+7 (ou o dobro do TTL): remova o registo antigo. A rotação está concluída.
O que o validador verifica
O validador trata cada registo de forma independente e confirma que:
- Cada hash respeita o comprimento esperado pelo seu matching type
- Nenhum campo sai dos intervalos válidos
- As combinações permanecem dentro das recomendações
Um registo em duplicidade nunca é sinalizado como erro quando os dois são sintaticamente corretos.
DANE e MTA-STS: abordagens complementares
| Critério | DANE | MTA-STS |
|---|---|---|
| Mecanismo | DNSSEC + registo TLSA | HTTPS + política em texto |
| Dependência | DNSSEC necessário | HTTPS necessário |
| Confiança | Criptográfica (DNS assinado) | PKI (CA HTTPS) |
| Suporte Postfix / Exim | Excelente | Bom |
| Suporte Microsoft 365 / Google Workspace | Parcial a inexistente | Completo |
| Deploy | Complexo (DNSSEC) | Mais simples |
Recomendação: não escolha, implante os dois. Valide o seu registo TLSA aqui e publique também uma política MTA-STS. A cobertura máxima impõe a combinação.
Ferramentas complementares e recursos
| Ferramenta | Quando usar |
|---|---|
| DANE TLSA Checker | Auditoria em tempo real do registo publicado no DNS, com validação DNSSEC e correspondência de certificado |
| Gerador DANE TLSA | Criar um registo TLSA a partir de um certificado ou de uma chave pública |
| Validador sintaxe MTA-STS | Validar a política MTA-STS associada offline |
| Validador sintaxe TLS-RPT | Validar o registo TLS-RPT associado offline |
| Auditoria email-authentication | Visão geral das ferramentas de autenticação de e-mail |
Guias relacionados
- DANE TLSA: o guia completo - Entender DANE de ponta a ponta, do DNSSEC ao deploy SMTP.
- DANE TLSA em Postfix, BIND e Let's Encrypt - Instalação passo a passo com rotação de chave.
- DANE TLSA e Microsoft 365 Exchange Online - Suporte de DANE de entrada e saída no Exchange Online.
- DANE TLSA, troubleshooting: 12 casos práticos - Diagnóstico e resolução de incidentes DANE.
- MTA-STS vs DANE: comparativo detalhado - Escolher ou combinar os dois protocolos.
Especificações
- RFC 6698 - DANE TLSA (especificação original)
- RFC 7671 - Updates to DANE (esclarecimentos operacionais)
- RFC 7672 - SMTP Security via DANE (DANE para SMTP)