O que é DNS Amplification? Como funciona o ataque de reflexão DNS

Em março de 2013, o ataque contra a Spamhaus gerou cerca de 300 Gbps de tráfego — um recorde à época — usando servidores DNS públicos como amplificadores. O atacante enviou pequenas queries DNS com o endereço IP da vítima falsificado, e servidores ao redor do mundo entregaram respostas amplificadas diretamente à Spamhaus. Esse é o princípio do DNS Amplification.

Um ataque de Amplificação DNS (DNS Amplification Attack) é um ataque DDoS de reflexão que abusa do protocolo DNS, normalmente transportado por UDP, para gerar tráfego volumétrico contra uma vítima. Embora o protocolo explorado pertença à camada de aplicação, o impacto predominante costuma recair sobre banda, pacotes por segundo e capacidade de rede nas camadas inferiores. O ataque usa IP spoofing para fazer respostas de terceiros convergirem para o alvo.

DNS Amplification vs. DNS Flood — diferença conceitual

Antes de aprofundar o mecanismo, é útil diferenciar dois ataques frequentemente confundidos:

EDNS(0) (RFC 6891) — como viabiliza respostas maiores

A especificação original do protocolo DNS (RFC 1035) limita o tamanho máximo de mensagens UDP a 512 bytes. O EDNS(0) (Extension Mechanisms for DNS, RFC 6891) introduziu um mecanismo de extensão que permite ao cliente anunciar um tamanho máximo de payload UDP maior, por meio de um registro OPT pseudotype na seção adicional da query.

O tamanho efetivamente usado depende do valor anunciado pelo cliente, da configuração do servidor, do caminho de rede e de políticas para evitar fragmentação. Embora valores maiores, como 4.096 bytes, tenham sido comuns em algumas configurações, muitos operadores adotam limites menores — frequentemente próximos de 1.232 bytes — para reduzir problemas de fragmentação.

O EDNS(0) pode aumentar significativamente o potencial de amplificação ao permitir respostas UDP maiores que 512 bytes. Entretanto, a reflexão DNS não depende exclusivamente de EDNS(0): consultas menores ainda podem provocar respostas maiores, e o fator efetivo depende do tipo de consulta, da zona, da configuração do servidor, do uso de DNSSEC e das políticas de tamanho de resposta.

Quando a resposta precisa ser entregue por TCP, o potencial de reflexão é reduzido porque o estabelecimento da conexão exige o three-way handshake. Um atacante que falsifica o IP da vítima não recebe o SYN-ACK e, em condições normais, não consegue concluir a conexão necessária para obter a resposta TCP. O EDNS(0) mantém o vetor operacional sobre UDP ao permitir respostas maiores sem exigir conexão.

Como funciona a reflexão e amplificação DNS

O ataque combina IP spoofing com a assimetria de tamanho entre query e resposta sobre UDP. O mecanismo ocorre em etapas encadeadas:

Na primeira etapa, o atacante envia queries DNS com o IP de origem falsificado — substituindo seu próprio endereço pelo endereço da vítima. A query é pequena e pode declarar suporte a EDNS(0) com um tamanho de payload elevado. O tipo de registro escolhido é aquele que tende a gerar uma resposta maior.

Na segunda etapa, o servidor DNS responde ao endereço IP de origem presente no datagrama UDP. Como UDP não exige handshake e o endereço de origem pode ter sido falsificado, a resposta é enviada à vítima indicada pelo atacante.

Na terceira etapa, a vítima recebe respostas que nunca solicitou. Quando o atacante usa múltiplos servidores DNS em paralelo, as respostas convergem simultaneamente para a vítima, gerando tráfego volumétrico que pode pressionar sua capacidade de rede.

Potencial de amplificação por tipo de consulta

O fator de amplificação varia consideravelmente com o tipo de consulta, o servidor, a zona, o uso de DNSSEC, configurações de resposta, limites UDP e o caminho de rede. Os valores abaixo são descritivos, não universais.

RFC 8482 — respostas mínimas para queries ANY

Historicamente, queries do tipo ANY eram um vetor relevante de amplificação DNS por poderem retornar múltiplos conjuntos de registros associados ao nome consultado, gerando respostas maiores. A RFC 8482, publicada em 2019, define respostas mínimas para consultas DNS do tipo ANY, reduzindo a prática histórica de responder com todos os RRsets disponíveis para o nome consultado. Uma implementação pode responder com um registro HINFO sintetizado ou outro conjunto mínimo de dados, conforme a política adotada.

Esse comportamento reduz o potencial de amplificação associado a consultas ANY em implementações que o adotam. Não elimina outros tipos de consultas ou fontes de respostas DNS grandes, como consultas a registros DNSSEC, DNSKEY ou TXT, dependendo da configuração e da zona consultada. A adoção não é universal e o comportamento efetivo depende da implementação e da política do operador.

Open resolvers e servidores autoritativos como refletores

Um open resolver DNS é um servidor DNS configurado para responder queries recursivas de qualquer endereço IP na internet — não apenas de clientes autorizados. Essa configuração transforma o servidor em um amplificador potencial para DNS Amplification.

Historicamente, open resolvers foram uma fonte importante de amplificação porque aceitam consultas recursivas de qualquer origem. Entretanto, servidores autoritativos publicamente acessíveis também podem ser usados como refletores quando respondem a consultas com IP de origem falsificado. A exposição e as medidas de defesa variam entre serviços recursivos e autoritativos.

A quantidade de resolvers expostos e permissivos varia ao longo do tempo e depende da metodologia de medição. Projetos de varredura e operadores de DNS identificam continuamente servidores recursivos abertos na internet, mas números globais devem ser apresentados apenas com fonte, data e metodologia verificáveis.

Variações: outros protocolos UDP usados em reflexão

O DNS Amplification é o caso mais documentado, mas o princípio de reflexão e amplificação sobre UDP se aplica a outros protocolos:

NTP Amplification: explora o protocolo NTP. O comando monlist (associado a servidores legados ou mal configurados) historicamente retornava grandes listas de clientes como resposta a uma requisição pequena. Menos prevalente hoje porque servidores NTP modernos e atualizados geralmente desabilitam esse comportamento por padrão.

SSDP Amplification: usa o protocolo UPnP/SSDP presente em dispositivos IoT domésticos. Dispositivos que expõem SSDP na internet podem ser abusados como refletores. O vetor persiste pelo grande número de dispositivos IoT expostos desnecessariamente.

CLDAP Amplification: usa o protocolo CLDAP (Connectionless LDAP). Servidores LDAP expostos podem ser abusados como refletores. Vetor menos documentado mas possível em redes com servidores LDAP acessíveis publicamente.

Técnicas de mitigação

BCP 38 — filtragem de IP spoofing na origem

O RFC 2827 (BCP 38) orienta ISPs a filtrarem pacotes com endereços de origem inválidos ou impossíveis saindo de suas redes. Se um cliente envia um pacote com IP de origem que não pertence à rede alocada a ele, o ISP pode descartar esse pacote antes de encaminhá-lo para a internet.

A adoção ampla e correta de filtragem de origem reduziria drasticamente ataques de reflexão que dependem de IP spoofing na internet pública. Ela não elimina ataques DDoS realizados por botnets com IPs reais nem substitui outras camadas de defesa.

A adoção de filtragem de origem permanece incompleta e desigual entre redes. Projetos como o CAIDA Spoofer Project fornecem evidências de que o IP spoofing ainda é possível a partir de parte da internet, mas seus resultados devem ser interpretados conforme a cobertura e a metodologia de medição — não generalizados como percentuais globais definitivos.

Response Rate Limiting (RRL) em servidores DNS

O RRL limita a emissão de respostas DNS repetitivas ou semelhantes conforme critérios definidos pela implementação e pela política do operador. Ele é especialmente útil em servidores autoritativos para reduzir o potencial de abuso em reflexão e amplificação.

RRL não substitui a desativação de recursão aberta, a filtragem anti-spoofing ou o dimensionamento da infraestrutura. Seus parâmetros precisam ser testados para evitar impacto em clientes legítimos e em cenários de alta demanda real.

Desativar open recursion em resolvers

Resolvers DNS devem ser configurados para responder apenas a clientes autorizados por meio de ACLs baseadas em IP. Um exemplo de configuração em BIND para restringir a recursão:

options {
    allow-recursion { trusted-clients; };
    allow-query-cache { trusted-clients; };
};

O exemplo pressupõe que a ACL trusted-clients já esteja definida e que o servidor seja destinado apenas à resolução para redes autorizadas. Antes de aplicar mudanças em produção, valide a configuração conforme a versão do BIND em uso, a separação entre serviços recursivos e autoritativos e as necessidades de clientes legítimos. Resolvers públicos legítimos têm um modelo operacional diferente e não devem aplicar simplesmente essa restrição sem planejamento adequado.

Anycast para distribuição e absorção do tráfego

Com Anycast, o mesmo prefixo IP é anunciado via BGP a partir de múltiplos pontos de presença. As políticas BGP podem direcionar diferentes fontes para pontos distintos, ajudando a distribuir tráfego e aproximar a mitigação de parte das origens.

A distribuição real não é necessariamente uniforme nem baseada apenas em proximidade geográfica: ela depende de políticas de roteamento, peering, capacidade e topologia. Por isso, Anycast deve ser combinado com capacidade adequada, telemetria e mecanismos de mitigação em cada ponto de presença.

Scrubbing centers e filtragem upstream

Scrubbing centers são infraestruturas especializadas em inspeção e filtragem de tráfego volumétrico. Em pontos da rede que observam consultas e respostas, controles podem correlacionar respostas DNS recebidas com consultas previamente observadas e reduzir tráfego não solicitado.

Essa correlação depende de visibilidade bidirecional, assimetria de rota, NATs, arquitetura de resolução DNS e políticas de timeout. A porta UDP 53 isoladamente não é evidência suficiente de ataque — ela também carrega tráfego DNS legítimo.

Detecção com NetFlow, sFlow e telemetria de rede

A detecção de DNS Amplification requer análise de telemetria de rede. NetFlow e sFlow normalmente fornecem metadados de fluxo — endereços, portas, volume, PPS, duração — mas não conteúdo de payload DNS. Para identificar EDNS(0), QTYPE, OPT record ou conteúdo DNS específico, é necessário DPI, captura de pacotes, sensor DNS ou telemetria de appliance especializado.

Em redes onde consultas e respostas UDP/53 são observadas bidirecionalmente, tráfego DNS legítimo tende a apresentar correlação temporal entre queries enviadas e respostas recebidas. A proporção não é necessariamente 1:1, pois cache, retransmissões, timeouts, DNSSEC, NATs, múltiplos resolvers e outros fatores podem alterar o padrão. O sinal mais indicativo de amplificação é alto volume de respostas UDP com porta de origem 53 sem queries correspondentes visíveis na rede.

Sinais operacionais de detecção

Erros comuns e orientações

Bloquear todo o tráfego UDP na porta 53 de entrada: isso bloqueia também respostas DNS legítimas de resolvers externos. Use controles que correlacionem respostas a queries enviadas pela rede para distinguir tráfego solicitado de respostas não solicitadas.

Depender apenas de blackhole routing para mitigar o ataque: blackhole routing descarta todo o tráfego para o IP da vítima, incluindo o legítimo — completando o objetivo do atacante. Use scrubbing seletivo quando possível.

Não configurar RRL no servidor DNS autoritativo próprio: mesmo não sendo um open resolver, um servidor DNS autoritativo pode ser usado em ataques de reflexão se aceitar queries de qualquer fonte. RRL pode limitar o volume de respostas repetitivas ou semelhantes conforme critérios definidos pela implementação e pela política do operador, reduzendo o potencial de reflexão. A configuração exige tuning para não afetar clientes legítimos.

Ignorar dispositivos IoT como potenciais amplificadores SSDP: segmente dispositivos IoT em VLANs isoladas e avalie bloquear tráfego SSDP de saída para a internet pública. Dispositivos com UPnP ativado e expostos podem ser recrutados como amplificadores.

Perguntas frequentes

Por que o UDP é usado em vez do TCP no DNS Amplification? O UDP não requer handshake, então o atacante pode enviar queries com IP falsificado sem estabelecer uma conexão real. O EDNS(0) permite respostas UDP maiores que 512 bytes, aumentando a assimetria disponível. Com TCP, o three-way handshake tornaria o IP spoofing muito mais difícil: o servidor enviaria o SYN-ACK ao IP da vítima, que nunca completaria o handshake, e o atacante não receberia a resposta.

Qual é o papel do EDNS(0) no ataque? EDNS(0) pode aumentar o potencial de amplificação ao permitir respostas UDP maiores que 512 bytes. O fator real depende da consulta, do servidor, do tamanho anunciado, de DNSSEC, da configuração de resposta e do caminho de rede. A reflexão DNS existia antes do EDNS(0) — consultas menores ainda podem provocar respostas maiores em determinados cenários.

A RFC 8482 elimina completamente o vetor de queries ANY? Em implementações que aplicam respostas mínimas a consultas ANY, a utilidade desse tipo de consulta como vetor de amplificação é significativamente reduzida. Isso não elimina outros tipos de consultas ou fontes de respostas DNS grandes. O comportamento efetivo depende da implementação e da política do operador.

O DNS Amplification afeta apenas open resolvers? Não. Servidores autoritativos publicamente acessíveis também podem ser usados como refletores quando respondem a consultas com IP de origem falsificado. O alvo final do ataque é a vítima cujo link é saturado — os servidores DNS são usados como intermediários, não como alvos.

BCP 38 resolve completamente o problema? A adoção ampla e correta de filtragem de origem reduziria drasticamente ataques de reflexão que dependem de IP spoofing na internet pública. Ela não elimina ataques DDoS realizados por botnets com IPs reais nem substitui outras camadas de defesa. A adoção permanece incompleta e desigual, o que mantém o vetor operacional e torna necessárias medidas complementares como RRL, Anycast e scrubbing.

Como distinguir um pico de tráfego DNS legítimo de um ataque refletido? A distinção é feita pelo padrão de fluxo. Em redes com visibilidade bidirecional, tráfego DNS legítimo tende a apresentar correlação entre queries enviadas e respostas recebidas. Um ataque refletido pode gerar alto volume de respostas UDP com porta de origem 53 sem consultas DNS de saída previamente observadas que correspondam ao fluxo esperado. Essa correlação depende de visibilidade bidirecional, NAT, assimetria de rota e timeouts de estado. A confirmação de EDNS(0), QTYPE e tamanho efetivo da resposta requer captura de pacotes ou DPI.

Como implementar na Azion

A Azion pode compor uma estratégia de mitigação contra ataques de reflexão e amplificação DNS, conforme os produtos contratados, os protocolos publicados e as políticas configuradas.

1. Controles distribuídos de rede: uma arquitetura distribuída pode ajudar a absorver e filtrar tráfego UDP anômalo antes que ele alcance a origem. O comportamento efetivo depende da topologia, da capacidade, das rotas e das políticas aplicadas.

2. Mitigação de tráfego volumétrico: recursos de proteção DDoS e políticas de rede podem ajudar a detectar aumentos de PPS e banda associados a ataques de reflexão, aplicando controles conforme o perfil de tráfego observado.

3. Proteção de serviços DNS: para serviços DNS publicados, controles de configuração, limitação de respostas e políticas de acesso podem reduzir o risco de que resolvers ou servidores autoritativos sejam abusados como refletores, conforme os recursos habilitados.

4. Observabilidade: logs, métricas e telemetria de rede podem ajudar a identificar tráfego UDP anômalo, alterações de volume, distribuição de origens e pressão sobre links durante um incidente.

A cobertura efetiva depende da arquitetura de DNS, dos serviços publicados, dos produtos habilitados, das políticas configuradas e do perfil do ataque.

Saiba mais na documentação de DDoS Protection da Azion.