DNS Seguro: DNSSEC e DNS sobre HTTPS (DoH)

O Sistema de Nomes de Domínio (DNS) traduz nomes de domínio legíveis por humanos em endereços IP. Projetado na década de 1980, o DNS foi criado sem segurança — as consultas e respostas trafegam pelas portas 53 UDP/TCP em texto claro, sem autenticação. Isso cria duas vulnerabilidades principais: envenenamento de cache DNS (injetar respostas DNS falsificadas para redirecionar usuários a servidores maliciosos) e interceptação de DNS (observar quais domínios um usuário consulta revela sua atividade de navegação). Dois padrões tratam desses problemas: o DNSSEC impede falsificações, e o DNS sobre HTTPS (DoH) impede a interceptação.

O envenenamento de cache DNS (ataque de Kaminsky) explora a falta de autenticação do protocolo DNS. Um Resolver envia uma consulta a um servidor DNS autoritativo e armazena a resposta em cache durante o período do TTL. Um invasor que consiga adivinhar o ID da transação (16 bits, previsível) e a porta de origem (usada como entropia adicional desde a RFC 5452) pode enviar respostas falsificadas que o Resolver armazena em cache, redirecionando todos os usuários que consultarem esse Resolver para o servidor do invasor. Depois que o cache é envenenado, os usuários são direcionados a servidores falsos, mesmo tendo digitado o domínio correto. O DNSSEC impede isso assinando digitalmente as respostas DNS.

O DNSSEC adiciona assinaturas criptográficas aos registros DNS, permitindo que os Resolvers verifiquem se as respostas vieram da autoridade legítima da zona e não foram adulteradas. O DNSSEC introduz novos tipos de registro: RRSIG (assinatura de registro de recurso, a assinatura propriamente dita sobre um conjunto de registros), DNSKEY (a chave pública usada para verificar assinaturas), DS (assinante de delegação, vincula as chaves das zonas pai e filha) e NSEC/NSEC3 (negação autenticada de existência — prova que um nome não existe). O DNSSEC cria uma cadeia de confiança da zona raiz (assinada pela ICANN) até as zonas TLD e autoritativas.

O DNSSEC usa dois tipos de chaves de assinatura. A chave de assinatura de zona (ZSK) assina os conjuntos de registros DNS individuais (RRSIGs) e é alternada com frequência (mensal ou trimestralmente) para proporcionar agilidade operacional. A chave de assinatura de chave (KSK) assina o conjunto de registros DNSKEY, fornecendo a âncora de confiança da zona. A KSK é alternada com menos frequência (anualmente), pois a zona pai precisa ser atualizada com o novo registro DS sempre que a KSK muda — um processo que exige coordenação. A KSK verifica a ZSK; a ZSK assina os dados. Essa estrutura em duas camadas equilibra a segurança (alternância frequente da ZSK) e a carga operacional (alternância infrequente da KSK).

O DNSSEC tem limitações importantes. Ele não criptografa consultas DNS — apenas assina respostas para garantir a integridade. Um interceptador ainda pode ver todas as consultas DNS, mas não pode falsificar respostas. Enumeração de zona: os registros NSEC (que comprovam a não existência) permitem que invasores percorram a zona e enumerem todos os nomes de domínio nela; o NSEC3 reduz esse problema usando nomes com hash, mas não é perfeito. Complexidade operacional: o gerenciamento de chaves, a expiração de assinaturas e a coordenação com a zona pai criam uma sobrecarga operacional significativa. A adoção do DNSSEC continua incompleta — muitos TLDs e registradores são compatíveis com ele, mas muitas organizações ainda não o implantaram.

DNS sobre HTTPS (DoH) criptografa as consultas DNS dentro do HTTPS (RFC 8484), ocultando o conteúdo das consultas dos observadores da rede. As consultas são enviadas a um resolvedor compatível com DoH por meio de uma URL HTTPS padrão, tornando o tráfego DNS indistinguível de outros tráfegos HTTPS. Isso impede que provedores de internet, empregadores e invasores no caminho vejam quais domínios um usuário consulta — solucionando a lacuna de privacidade deixada pelo DNSSEC. No entanto, o DoH transfere a confiança do resolvedor DNS da rede para o provedor de DoH (normalmente Google 8.8.8.8, Cloudflare 1.1.1.1 ou o próprio resolvedor DoH da organização). Atualmente, o DoH é compatível nativamente com a maioria dos principais navegadores.

DNS sobre TLS (DoT) (RFC 7858) criptografa as consultas DNS usando TLS por meio de uma porta TCP dedicada, a 853, em vez de encapsulá-las pelo HTTPS. O DoT oferece os mesmos benefícios de privacidade que o DoH — ocultando o conteúdo das consultas de quem as intercepta —, mas é mais fácil de identificar e filtrar para os administradores de rede (porta 853 em comparação com a porta 443). Isso é uma faca de dois gumes: o DoT é visível e pode ser bloqueado por firewalls corporativos, enquanto o DoH é mais difícil de bloquear sem afetar o tráfego HTTPS geral. Os resolvedores stub (no nível do OS) usam DoT com mais frequência; os navegadores usam DoH com mais frequência.

O DNS criptografado cria um desafio para ambientes empresariais que dependem de filtragem baseada em DNS e de sinkholes. Quando os navegadores usam resolvedores DoH externos, os controles internos de DNS são contornados. Contramedidas empresariais: implantar um resolvedor DoH/DoT interno (Cisco Umbrella, Pi-hole com DoH) e configurar todos os dispositivos para usá-lo; bloquear os IPs de resolvedores DoH externos no firewall (Google 8.8.8.8, Cloudflare 1.1.1.1) na porta 443; usar a Group Policy para desabilitar o DoH no nível do navegador em endpoints gerenciados; e aplicar regras de proxy transparente que interceptem o DNS sobre TLS na porta 853. O objetivo é encaminhar todo o DNS pelo resolvedor controlado sem bloquear completamente o DNS criptografado.

Uma estratégia completa de segurança de DNS combina vários controles. O DNSSEC nas suas zonas autoritativas impede o envenenamento de cache do seu domínio. A filtragem baseada em DNS (Cisco Umbrella, Cloudflare Gateway) bloqueia domínios maliciosos no nível do resolvedor. O DoH/DoT para um resolvedor controlado fornece privacidade às consultas sem perder a visibilidade da filtragem. O registro de DNS no SIEM captura todas as consultas para a busca proativa de ameaças — os registros DNS revelam tráfego de C2, exfiltração de dados por tunelamento DNS e atividade de algoritmo de geração de domínios (DGA) causada por malware. A telemetria de DNS é uma das fontes de dados de segurança mais valiosas disponíveis.

O tunelamento DNS codifica dados dentro de consultas e respostas DNS para exfiltrar dados ou estabelecer canais de C2 por redes nas quais outros tráfegos de saída estão bloqueados. Ferramentas como iodine, DNScat e dnscat2 codificam cargas úteis em rótulos de subdomínios (consulta por EXFILTRATEDDATA.evil.com) ou em registros TXT. Detecção: nomes de consultas DNS excepcionalmente longos (>100 caracteres), alto volume de consultas de um único host, consultas por domínios-pai inexistentes, tipos de registro incomuns (TXT, NULL) e análise de entropia dos rótulos de domínio (dados codificados têm alta entropia de Shannon). Plataformas de análise de segurança DNS sinalizam automaticamente padrões de tunelamento.

As zonas de política de resposta DNS (RPZ) permitem que os resolvedores DNS apliquem políticas locais de substituição às respostas DNS — criando, essencialmente, um sinkhole local no nível do resolvedor sem modificar a infraestrutura DNS global. Quando um cliente consulta um domínio conhecido por ser malicioso, a política RPZ retorna NXDOMAIN, um redirecionamento para um IP de sinkhole ou uma resposta de passagem. Feeds de RPZ estão disponíveis com provedores de inteligência contra ameaças (Spamhaus, SURBL) e podem ser importados diretamente para resolvedores BIND ou Unbound. A RPZ é uma ferramenta defensiva poderosa porque aplica a filtragem na camada DNS para todos os dispositivos da rede sem qualquer configuração no lado do cliente.

Test sua compreensão dos conceitos do CompTIA Security+ (SY0-701) abordados nesta lição.

Nesta lição, você aprendeu: o DNSSEC adiciona assinaturas criptográficas aos registros DNS usando pares de chaves KSK/ZSK para impedir o envenenamento de cache, mas não criptografa as consultas; o DNS sobre HTTPS (DoH) criptografa as consultas DNS dentro do HTTPS para impedir a interceptação, mas cria riscos de contorno da filtragem empresarial; e o tunelamento DNS codifica dados em consultas DNS e pode ser detectado por meio da análise do comprimento, do volume e da entropia das consultas. Em seguida, exploraremos IPsec, protocolos de VPN e segurança do acesso remoto.