DNS: o alicerce que ninguém audita

Toda auditoria de segurança que eu já vi passa horas no firewall, no endpoint, no controle de acesso. Quase nenhuma passa dez minutos no DNS.

É uma inversão curiosa, porque o DNS é a única camada de que absolutamente tudo depende e que quase ninguém trata como sua. O e-mail depende dele. O certificado depende dele. O site depende dele. E quem controla o DNS de uma empresa não precisa invadir servidor nenhum — ele simplesmente passa a ser a empresa.

Vale dizer isso com todas as letras: um domínio sequestrado não é um incidente de site fora do ar. É um incidente de identidade. Enquanto durar, o atacante recebe o e-mail que era seu, emite certificado válido em seu nome, e o navegador do seu cliente mostra o cadeado — porque, do ponto de vista da internet, ele é você.

O ponto de falha não é o DNS. É o registrador.

Começo pela parte que costuma ser esquecida, porque ela não é técnica.

Ninguém "hackeia o DNS" na maioria dos casos reais. O que acontece é mais banal: alguém entra na conta do registrador. Por senha reaproveitada, por engenharia social no suporte, por um funcionário que saiu e continuou com acesso, ou pelo clássico — o domínio estava no nome pessoal de um ex-sócio, ou de uma agência que fechou.

Antes de qualquer registro, três perguntas que valem mais que qualquer configuração:

1. Quem é o titular do domínio? Não quem administra — quem consta como dono. Se for o CPF de alguém em vez do CNPJ da empresa, você tem um problema jurídico fantasiado de problema técnico.
2. Quem tem acesso à conta do registrador, e com que segundo fator? SMS não conta. Se o segundo fator é SMS, o seu domínio vale o quanto vale a operadora de celular do titular.
3. O domínio está travado? O registrar lock impede transferência sem destravar antes. É um clique, é grátis, e é o controle de maior retorno em toda esta lista.

E o mais chato de todos: quando o domínio vence? Uma quantidade indecente de incidentes graves é apenas um boleto que ninguém pagou.

DNSSEC: assinar as respostas

DNS nasceu em 1983, numa internet onde todo mundo se conhecia. Ele não tem, de origem, nenhuma forma de provar que a resposta que você recebeu foi mesmo a que o dono publicou.

DNSSEC resolve isso com assinatura criptográfica: a zona é assinada, e a chave é ancorada na zona pai através de um registro DS. O resolvedor valida a cadeia e, se bater, marca a resposta como autêntica — é o flag AD que você vê numa consulta.

Duas coisas que sempre preciso desfazer sobre DNSSEC:

• Ele não criptografa nada. As suas consultas continuam visíveis. Privacidade de consulta é outro assunto — DoH, DoT. DNSSEC é sobre integridade, não sobre sigilo.
• Ele não protege contra o cenário do capítulo anterior. Se o atacante entrou no seu registrador, ele assina o que quiser. DNSSEC defende o caminho, não a porta da frente.

Ainda assim vale, e vale por um motivo específico: sem DNSSEC, envenenamento de cache e respostas forjadas no caminho são possíveis, e a vítima não tem como perceber. Com DNSSEC, a resposta forjada é descartada antes de chegar ao usuário.

No Brasil não há desculpa: o Registro.br suporta DNSSEC e o processo leva minutos.

CAA: quem pode emitir certificado em seu nome

Este é o registro que menos gente conhece e que resolve um problema desproporcionalmente grande.

Sem CAA, qualquer autoridade certificadora do mundo pode emitir um certificado válido para o seu domínio. São dezenas delas, em dezenas de jurisdições, e basta uma se enganar — ou ser enganada — para existir por aí um certificado legítimo do seu domínio que não é seu.

O registro CAA é uma lista de quem você autoriza:

exemplo.com.br.  CAA  0 issue "letsencrypt.org"
exemplo.com.br.  CAA  0 issue "digicert.com"
exemplo.com.br.  CAA  0 iodef "mailto:seguranca@exemplo.com.br"

As duas primeiras linhas restringem a emissão. A terceira é a que quase todo mundo esquece, e é a melhor: iodef diz para onde a CA deve avisar quando alguém tentar emitir um certificado que a política proíbe. Ou seja, ela transforma o CAA de um controle preventivo num controle de detecção. Você fica sabendo da tentativa.

Combine isso com monitoramento de Certificate Transparency — os logs públicos onde todo certificado emitido é registrado — e você tem visibilidade real sobre quem está tentando se passar por você.

SPF, DKIM e DMARC: o trio que quase sempre está pela metade

Aqui mora o erro mais comum que eu encontro, e ele é sutil: as três coisas estão configuradas, e mesmo assim não protegem nada.

SPF diz quais servidores podem enviar e-mail pelo seu domínio. O detalhe que muda tudo é o final do registro:

• ~all — soft fail. "Não deveria, mas aceite e marque."
• -all — hard fail. "Não é meu. Rejeite."

Quase todo mundo publica ~all e para por aí, porque tem medo de quebrar algum sistema legado que envia em nome do domínio. É um medo legítimo, mas ~all permanente não é uma configuração — é uma migração que nunca terminou.

DKIM assina a mensagem, provando que ela não foi alterada em trânsito e que saiu de quem diz ter saído.

DMARC amarra os dois e — a parte que importa — diz ao mundo o que fazer quando falham:

• p=none — não faça nada, só me mande relatório.
• p=quarantine — mande para spam.
• p=reject — recuse.

p=none não é proteção. É observação. É o degrau certo para começar, porque os relatórios mostram quem envia legitimamente em seu nome antes de você cortar. O problema é que a enorme maioria dos domínios que eu audito parou nesse degrau anos atrás e considera o assunto resolvido. Com p=none, qualquer um pode mandar e-mail se passando pelo seu domínio, e o destinatário entrega na caixa de entrada.

Some ainda o alinhamento: adkim=s e aspf=s exigem correspondência estrita entre o domínio que assina e o que aparece para o usuário. Sem isso, um subdomínio comprometido fala em nome do domínio principal.

O caminho honesto é: p=none para medir, ler os relatórios por algumas semanas, corrigir os remetentes legítimos, e então subir para quarantine e reject. Quem não sobe nunca, não implementou DMARC — implementou um relatório.

Registros órfãos: o risco de quem faz as coisas certas

Este é o mais traiçoeiro, porque ele nasce justamente de uma boa prática: desativar o que não se usa mais.

A sequência é sempre a mesma. Você criou app.suaempresa.com.br apontando por CNAME para um serviço em nuvem. O projeto acabou. Você cancelou o serviço — corretamente. Mas o CNAME continuou lá, apontando para um nome que agora está livre no provedor.

Aí alguém registra aquele nome no mesmo provedor e passa a responder pelo seu subdomínio. Com HTTPS válido, porque o certificado é emitido para quem controla o nome. É o subdomain takeover, e ele é usado para phishing convincente justamente por acontecer num domínio legítimo, seu, que passa em qualquer verificação superficial.

A regra prática: em toda desativação de serviço, o registro DNS sai antes do serviço, não depois. E toda migração de provedor precisa terminar com uma varredura dos registros que sobraram apontando para o provedor antigo.

TTL: um parâmetro de resposta a incidente

Fecho com o controle mais invisível de todos.

O TTL define por quanto tempo os resolvedores do mundo guardam a sua resposta em cache. Todo mundo o trata como parâmetro de desempenho. Ele é, também, o seu tempo de recuperação.

Se o seu registro tem TTL de 24 horas e você precisa mudá-lo às pressas — porque o provedor caiu, porque houve comprometimento, porque é preciso desviar tráfego —, boa parte da internet continuará usando a resposta antiga por até um dia inteiro. Você já corrigiu, e o mundo ainda não sabe.

Antes de qualquer mudança planejada, baixe o TTL com antecedência suficiente para o valor antigo expirar. Depois, suba de volta. É trivial, é grátis, e é a diferença entre um cutover de minutos e um de um dia.

O que eu levo

Nenhum dos controles deste texto é caro. Nenhum é difícil. Vários são um clique.

E é exatamente por isso que eles ficam de fora: segurança tem um viés de atenção para o que é visível e caro. Compra-se a ferramenta que aparece no orçamento, e não se trava o domínio que sustenta a empresa inteira.

Passei a vida na diferença entre risco aceitável e risco esquecido. O risco aceitável é aquele que você mediu, entendeu e decidiu correr. O esquecido é o que você nunca olhou — e o DNS é onde ele mora com mais frequência, porque funciona tão bem, e há tanto tempo, que ninguém lembra que ele está lá.

Se você for fazer uma coisa só depois de ler isto, faça esta: abra a conta do seu registrador e veja quem tem acesso. Não é a mais técnica da lista. É a que mais tem chance de estar errada.