O DNS é a fundação invisível de toda presença digital. Quando um servidor DNS autoritativo falha ou fica sobrecarregado, nenhum usuário consegue acessar o domínio — não importa quão robustos sejam os servidores de aplicação. Atacantes sabem disso. DNS Flood e ataques PRSD exploram exatamente essa dependência: em vez de atacar o serviço diretamente, atacam a infraestrutura que o torna localizável.
DNS Flood é um ataque DDoS volumétrico que exaure a largura de banda e a capacidade de processamento de um servidor DNS com um volume massivo de queries UDP na porta 53. Ataques PRSD (Pseudo Random Subdomain, também chamados de DNS Water Torture ou NXDOMAIN Flood) são uma variante distinta e mais sofisticada: em vez de saturar banda, esgotam CPU por meio de cache miss compulsório — cada query aponta para um subdomínio aleatório e inexistente, forçando o servidor autoritativo a realizar trabalho computacional real sem qualquer possibilidade de reutilizar resultados cacheados.
DNS Flood volumétrico — exaustão de banda na porta UDP 53
O DNS Flood básico envia queries em volume massivo para o mesmo domínio ou para domínios válidos. Como o DNS opera sobre UDP sem handshake, o atacante pode gerar e enviar centenas de milhares de queries por segundo a custo computacional mínimo — e, com IP spoofing, sem revelar sua origem real.
O impacto é direto: os buffers de recepção UDP do servidor transbordam, a fila de queries aguardando processamento satura e o servidor passa a descartar queries por timeout. Usuários legítimos recebem SERVFAIL ou não obtêm resposta.
A tabela abaixo resume as características operacionais do DNS Flood volumétrico:
| Parâmetro | Comportamento no DNS Flood |
|---|---|
| Protocolo de transporte | UDP, porta 53 |
| IP de origem | Frequentemente falsificado (IP spoofing) |
| Tipo de query | Qualquer tipo válido (A, AAAA, MX, ANY) |
| Domínio consultado | Geralmente o mesmo domínio repetidamente |
| Resposta do servidor | NOERROR com dados, ou SERVFAIL se sobrecarregado |
| Recurso esgotado | Largura de banda de rede e capacidade de I/O UDP |
| Detectabilidade | Alta — pico volumétrico visível em métricas de rede |
| Eficácia do cache | Parcial — resolver cacheia respostas e reduz carga no autoritativo |
Ataque PRSD — exaustão de CPU por cache miss compulsório
O ataque PRSD opera com lógica radicalmente diferente. Em vez de sobrecarregar a rede com volume, elimina o cache como mecanismo de proteção e força o servidor autoritativo a processar cada query individualmente.
O mecanismo funciona assim: o atacante gera queries para subdomínios aleatórios do domínio alvo — por exemplo, a7x9k2m.alvo.com, depois b3p8q1n.alvo.com, depois c5w7r4s.alvo.com. Cada subdomínio é único e não existe no DNS. O resolver recursivo consulta seu cache, não encontra a resposta (cache miss), e encaminha a query ao servidor autoritativo. O autoritativo verifica sua zona, não encontra o subdomínio, e responde com NXDOMAIN. O resultado nunca é cacheado de forma útil para a próxima query, porque a próxima query usará um subdomínio diferente.
O contraste com o DNS Flood é decisivo:
| Característica | DNS Flood volumétrico | PRSD (Water Torture / NXDOMAIN Flood) |
|---|---|---|
| Alvo primário | Largura de banda e I/O do servidor | CPU do servidor autoritativo |
| Domínio consultado | Fixo ou limitado | Subdomínios aleatórios únicos a cada query |
| Cache como defesa | Parcialmente eficaz | Ineficaz — cada query é única |
| Volume necessário | Alto (centenas de Gbps) | Moderado (dezenas de milhares de queries/s) |
| Resposta típica | NOERROR ou SERVFAIL | NXDOMAIN (subdomínio inexistente) |
| Detectabilidade | Alta — pico volumétrico visível | Moderada — misturado com tráfego legítimo |
| Custo por query para o servidor | Baixo (resposta cacheada) | Alto (lookup de zona completo a cada query) |
Impacto do PRSD nos resolvers recursivos intermediários
Um aspecto frequentemente subestimado do ataque PRSD é seu impacto nos resolvers recursivos intermediários — os servidores DNS de ISPs, empresas e provedores de nuvem que recebem as queries dos clientes finais antes de encaminhá-las ao autoritativo.
Cada query PRSD que passa pelo resolver recursivo gera os seguintes efeitos acumulativos:
Esgotamento de sockets UDP: o resolver recursivo abre um socket UDP para cada query pendente encaminhada ao autoritativo. Com dezenas de milhares de queries PRSD por segundo, o pool de sockets disponíveis no resolver pode saturar, impedindo que novas queries — inclusive para outros domínios — sejam processadas.
Acúmulo de queries pendentes: o resolver mantém um estado de query pendente enquanto aguarda a resposta do autoritativo. Em um ataque PRSD intenso, a tabela de queries pendentes cresce mais rápido do que é drenada pelas respostas NXDOMAIN, consumindo memória e CPU do resolver.
Risco de lame server marking: quando um servidor autoritativo não responde dentro do timeout configurado (geralmente 1,5 a 5 segundos), o resolver recursivo pode marcá-lo como “lame server” — um servidor com problemas de autoridade. Um server marcado como lame é temporariamente removido da lista de autoritativos consultados, acelerando a propagação da indisponibilidade para usuários que sequer estão sendo atacados diretamente.
Esses três efeitos em cascata no resolver recursivo explicam por que o PRSD pode derrubar a resolução DNS de um domínio mesmo que o volume de tráfego seja insuficiente para saturar o link de rede do autoritativo.
DNSSEC e o custo computacional do NSEC3 durante ataques PRSD
Se o domínio alvo usa DNSSEC, o ataque PRSD torna-se significativamente mais custoso para o servidor autoritativo em termos de CPU.
Quando um resolver recursivo com validação DNSSEC recebe uma resposta NXDOMAIN, ele precisa de uma prova criptográfica de inexistência — evidência de que o subdomínio genuinamente não existe na zona e que a ausência de registro é autêntica. Dois mecanismos DNSSEC foram projetados para fornecer essa prova:
NSEC (Next Secure): enumera os nomes adjacentes na zona ordenada. Uma resposta NXDOMAIN com NSEC contém dois registros que provam: “o nome a7x9k2m.alvo.com não existe, e os nomes mais próximos que existem são x.alvo.com e z.alvo.com”. O NSEC tem uma limitação crítica: permite a enumeração completa da zona DNS, o que é considerado um problema de privacidade.
NSEC3 (RFC 5155): resolve o problema de enumeração usando hashes criptográficos (SHA-1 com salt e número de iterações configurável) dos nomes de zona, em vez dos nomes em texto claro. Uma resposta NXDOMAIN com NSEC3 contém os hashes dos nomes adjacentes ordenados, provando a inexistência sem revelar os nomes reais da zona.
O custo computacional do NSEC3 durante um ataque PRSD é substancial por dois motivos:
-
Para cada query PRSD, o servidor autoritativo deve calcular o hash NSEC3 do subdomínio inexistente para determinar quais registros NSEC3 adjacentes incluir na resposta. Com dezenas de milhares de subdomínios únicos por segundo, isso representa um volume massivo de operações de hash SHA-1.
-
O número de iterações de hash é configurável (campo
iterationsdo NSEC3PARAM). Configurações com iterações elevadas aumentam a resistência a ataques de enumeração offline, mas amplificam o custo de CPU por query NXDOMAIN durante ataques PRSD.
Em termos práticos, um servidor autoritativo com DNSSEC e NSEC3 configurado pode saturar sua CPU com um volume de queries PRSD muito menor do que um servidor sem DNSSEC. A recomendação atual (RFC 9276) é usar iterations=0 — sem iterações extras além do hash base — para minimizar o custo computacional sem comprometer a segurança.
Impacto cascata de uma interrupção DNS
A indisponibilidade do DNS afeta simultaneamente todos os serviços que dependem daquele domínio:
| Serviço afetado | Impacto observado |
|---|---|
| Website | Timeout — usuários não conseguem resolver o domínio |
| APIs e integrações | Falha nas chamadas — endpoints inacessíveis |
| Bounces — registros MX não resolvidos | |
| CDN | Conteúdo estático inacessível — CNAME não resolve |
| Certificados TLS | Renovação Let’s Encrypt falha — validação DNS-01 bloqueada |
| Serviços de terceiros | Webhooks, SSO e integrações param de funcionar |
Técnicas de mitigação
Response Rate Limiting (RRL) — mecanismo de slip com flag TC=1
O RRL limita a taxa de respostas idênticas ou similares enviadas ao mesmo endereço IP de destino dentro de uma janela de tempo deslizante. Implementado em BIND (desde 9.9), Knot DNS e PowerDNS, é a principal defesa específica de protocolo contra DNS Flood e ataques de reflexão.
O mecanismo central do RRL é a política de slip: em vez de simplesmente descartar respostas que excedem o limite (o que poderia penalizar resolvers legítimos de ISPs que servem a muitos clientes), o servidor responde com uma taxa reduzida usando a flag de truncamento TC=1.
O funcionamento é o seguinte: quando uma resposta excederia o limite de taxa configurado, o servidor envia periodicamente uma resposta truncada com TC=1 em vez de descartar silenciosamente. Um cliente legítimo que recebe TC=1 entende que a resposta está incompleta e retenta a query via TCP, que oferece conexão confiável e é muito mais difícil de falsificar (IP spoofing em TCP é praticamente inviável). Ferramentas de ataque e amplificadores que usam UDP puro não implementam esse fallback para TCP, e portanto ficam sujeitos ao descarte sem receber a resposta completa.
A configuração típica inclui os parâmetros responses-per-second (limite de respostas idênticas por janela), window (duração da janela de tempo, geralmente 15 segundos) e slip (frequência de respostas TC=1 em vez de descarte, geralmente 2 — uma em cada duas respostas limitadas recebe TC=1).
Cache negativo (NCACHE) e o papel do SOA MINIMUM TTL
Para ataques PRSD, cada query resulta em NXDOMAIN. O RFC 2308 define o mecanismo de cache negativo (NCACHE): resolvers recursivos podem armazenar respostas NXDOMAIN em cache pelo tempo definido no campo MINIMUM do registro SOA da zona, até o máximo de 10.800 segundos (3 horas).
O SOA MINIMUM TTL funciona como o TTL de cache negativo da zona. Quando o autoritativo responde NXDOMAIN para a7x9k2m.alvo.com, o resolver cacheia essa resposta por até SOA MINIMUM segundos. Se o mesmo subdomínio for consultado novamente dentro desse período, o resolver responde a partir do cache sem contatar o autoritativo.
A limitação crítica para ataques PRSD é que esse mecanismo só funciona para subdomínios repetidos. O PRSD gera subdomínios completamente aleatórios e únicos a cada query — a7x9k2m, b3p8q1n, c5w7r4s, e assim por diante — garantindo que o resolver nunca encontre o mesmo subdomínio duas vezes. O cache negativo, portanto, oferece proteção mínima contra PRSD quando os subdomínios não se repetem.
Wildcards DNS (*.alvo.com) podem ajudar parcialmente: se o autoritativo tiver um wildcard, a resposta para qualquer subdomínio será um registro válido (não NXDOMAIN), permitindo caching normal. No entanto, o primeiro cache miss para cada subdomínio único ainda gera uma query ao autoritativo.
BGP Anycast — pulverização de carga em múltiplos PoPs
O BGP Anycast é a arquitetura mais eficaz para resistir a DNS Flood e PRSD em escala. O princípio é simples: o mesmo bloco de endereços IP do servidor DNS é anunciado via BGP a partir de múltiplos Pontos de Presença (PoPs) geograficamente distribuídos.
O roteamento BGP direciona automaticamente cada query ao PoP mais próximo da origem, sem configuração adicional no cliente. O resultado para ataques volumétricos é que o tráfego malicioso é dividido entre todos os PoPs, reduzindo proporcionalmente a carga em cada um:
| Configuração | Capacidade por nó | Carga por ataque de 500K queries/s |
|---|---|---|
| 1 servidor centralizado | 500K queries/s | 100% — sobrecarga total |
| 10 PoPs Anycast | 500K queries/s | ~10% por PoP — absorvido sem impacto |
| 100 PoPs Anycast | 500K queries/s | ~1% por PoP — praticamente imperceptível |
Para ataques PRSD, o Anycast distribui não apenas o volume de queries mas também o custo de CPU do processamento NXDOMAIN (e cálculo NSEC3 em zonas DNSSEC) entre os PoPs. Um PoP na Europa absorve as queries de botnets europeias; um PoP na Ásia absorve queries asiáticas. O servidor de origem fica completamente isolado da carga de ataque.
Filtragem de IP spoofing (BCP38)
DNS sobre UDP é especialmente vulnerável a IP spoofing. A implementação de BCP38 nos ISPs — que descarta pacotes com endereços de origem impossíveis ou inválidos — impede que atacantes enviem queries com IPs falsificados, eliminando uma classe inteira de ataques refletidos e dificultando a distribuição de ataques PRSD a partir de uma única origem.
Limitação de taxa por IP de origem (ACLs)
Configurar limites de queries por IP de origem no servidor autoritativo bloqueia botnets de endereços concentrados sem impactar resolvers recursivos legítimos. Um resolver recursivo de ISP tipicamente envia queries em nome de milhares de usuários, então o limite deve ser calibrado para não bloquear resolvers legítimos que naturalmente geram alto volume.
DNS autoritativo no edge vs. DNS centralizado
| Aspecto | DNS centralizado | DNS autoritativo no edge (BGP Anycast) |
|---|---|---|
| Resiliência a DNS Flood | Baixa — único ponto de ataque | Alta — carga distribuída entre PoPs |
| Resiliência a PRSD | Baixa — CPU esgotada por cache miss | Alta — cada PoP absorve sua região geográfica |
| Isolamento do servidor de origem | Nenhum — origem exposta diretamente | Total — queries chegam ao PoP, não à origem |
| Latência de resolução | Alta para usuários distantes | Baixa — resolução no PoP mais próximo |
| Failover automático | Requer configuração manual | Transparente via convergência BGP |
| Capacidade total de queries/s | Limitada por hardware único | Escalável horizontalmente com cada PoP adicionado |
| Custo NSEC3 sob PRSD | Concentrado em 1 servidor | Distribuído entre 100+ servidores |
Sinais de detecção
| Indicador | O que observar | Ataque provável |
|---|---|---|
| Taxa de NXDOMAIN acima de 30% | Proporção de respostas NXDOMAIN vs. NOERROR | PRSD |
| Alto volume de subdomínios únicos por segundo | Logs mostrando padrão [random].dominio.com | PRSD |
| CPU do servidor DNS elevada sem pico de banda | Alto processamento sem aumento proporcional de tráfego | PRSD com DNSSEC |
| Queries/segundo em pico sem evento de marketing | Aumento súbito sem causa conhecida | DNS Flood ou PRSD |
| Resolvers recursivos reportando timeouts | Lame server marking em curso | PRSD severo |
| Taxa de lame delegation aumentando | Logs de resolver mostrando autoritativo marcado como lame | PRSD em estágio avançado |
Erros comuns e soluções
Erro: Depender apenas de um servidor DNS autoritativo centralizado, sem redundância geográfica. Solução: Um único servidor autoritativo é um ponto único de falha para toda a presença digital e um alvo concentrado para ataques. Use pelo menos dois servidores em localizações diferentes — idealmente com BGP Anycast para distribuição automática de carga.
Erro: Não configurar RRL no servidor DNS autoritativo.
Solução: Por padrão, servidores como BIND não limitam respostas. Configure RRL com slip (TC=1) para proteger contra amplificação reflexiva sem penalizar resolvers legítimos. Ajuste responses-per-second de acordo com o perfil de tráfego normal da zona.
Erro: Confiar em NCACHE como proteção completa contra PRSD. Solução: O cache negativo só protege contra queries repetidas ao mesmo subdomínio. O PRSD gera subdomínios únicos a cada query, tornando o NCACHE ineficaz para as queries ativas do ataque. Combine NCACHE com Anycast e RRL.
Erro: Ignorar o PRSD porque a proteção volumétrica está ativa.
Solução: O PRSD pode operar abaixo dos limiares volumétricos enquanto satura a CPU do autoritativo. Use defesas específicas de protocolo DNS (RRL, Anycast, NSEC3 com iterations=0) além de proteção volumétrica.
Erro: Configurar NSEC3 com alto número de iterações em zonas sob risco de PRSD.
Solução: Iterações elevadas aumentam o custo de CPU por query NXDOMAIN. Siga a recomendação do RFC 9276 e use iterations=0 para minimizar a superfície de ataque sem comprometer a segurança da zona.
Perguntas frequentes
Qual é a diferença fundamental entre DNS Flood e PRSD? O DNS Flood visa esgotar a largura de banda e o I/O UDP do servidor com volume massivo de queries. O PRSD visa esgotar a CPU do servidor por meio de cache miss compulsório — cada query gera trabalho computacional novo e não reutilizável, porque aponta para um subdomínio único e inexistente. O DNS Flood é detectável por pico volumétrico; o PRSD pode operar abaixo dos limiares de volume enquanto satura o processador.
Como o PRSD afeta os resolvers recursivos intermediários? O PRSD sobrecarrega os resolvers recursivos de três formas simultâneas: esgota o pool de sockets UDP disponíveis para queries pendentes; acumula uma tabela de queries pendentes que consome memória e CPU; e pode causar lame server marking do autoritativo se os timeouts forem excedidos, acelerando a propagação da indisponibilidade para usuários que nem mesmo estão sendo atacados diretamente.
Por que o DNSSEC agrava o impacto do PRSD?
Com DNSSEC ativado e NSEC3 configurado, cada resposta NXDOMAIN requer o cálculo de hashes SHA-1 para gerar as provas criptográficas de inexistência (RFC 5155). Com dezenas de milhares de subdomínios aleatórios por segundo, esse custo de hashing multiplica o uso de CPU do servidor autoritativo. Use iterations=0 no NSEC3PARAM para minimizar o custo sem comprometer a segurança.
O que é o mecanismo de slip do RRL e como ele protege resolvers legítimos? O slip é a política do RRL de responder periodicamente com TC=1 (resposta truncada) em vez de descartar silenciosamente. Um cliente legítimo que recebe TC=1 retenta via TCP — um canal confiável e resistente a IP spoofing. Ferramentas de ataque que usam UDP puro não implementam esse fallback e ficam efetivamente bloqueadas. O slip garante que o RRL não penalize resolvers de ISPs que genuinamente precisam de alta taxa de respostas.
O DNS Flood é o mesmo que DNS Amplification? Não. O DNS Flood sobrecarrega o servidor DNS alvo com um volume massivo de queries — o alvo é o próprio servidor DNS. A DNS Amplification usa servidores DNS abertos como reflexores para amplificar tráfego UDP contra uma vítima diferente. São vetores distintos com alvos e mecanismos diferentes.
Por que o PRSD é chamado de “Water Torture”? O nome vem da tortura da gota d’água — cada query individualmente causa trabalho real mas limitado no servidor, acumulando-se até gerar indisponibilidade por sobrecarga gradual de CPU. É mais insidioso que o flood volumétrico bruto porque pode operar em volume de rede modesto e difícil de distinguir de tráfego legítimo.
Um TTL de DNS baixo ajuda ou prejudica durante um ataque PRSD? Prejudica. TTLs baixos forçam resolvers a consultar o autoritativo com mais frequência mesmo para registros existentes, aumentando a carga base. Durante ataques PRSD, TTLs mais altos nos registros existentes são benéficos — resolvers cacheiam respostas por mais tempo, reduzindo a pressão sobre o autoritativo para o tráfego legítimo.
Como implementar na Azion
A Azion protege contra DNS Flood e PRSD com arquitetura de Edge DNS autoritativo distribuído via BGP Anycast global:
- Edge DNS com BGP Anycast em 100+ PoPs: O DNS autoritativo da Azion opera com o mesmo IP anunciado em mais de 100 data centers via BGP Anycast. O tráfego de ataque é automaticamente distribuído pelo roteamento BGP entre os PoPs mais próximos da fonte, sem configuração manual. Nenhum PoP individual recebe uma fração significativa do ataque total. O servidor de origem fica completamente isolado — queries chegam aos PoPs da Azion, nunca ao backend de origem.
- Response Rate Limiting nativo com slip: O Edge DNS da Azion implementa RRL por padrão com o mecanismo de slip (TC=1), protegendo contra ataques de reflexão e amplificação sem penalizar resolvers recursivos legítimos.
- Proteção contra NSEC3 flood em zonas DNSSEC: A infraestrutura distribuída distribui o custo de cálculo NSEC3 entre os PoPs, evitando que um único servidor autoritativo sature sua CPU com operações de hashing durante um ataque PRSD intenso contra zonas DNSSEC.
- Proteção contra IP spoofing: A rede da Azion implementa filtragem de pacotes que descarta queries com endereços de origem impossíveis, reduzindo o impacto de ataques DNS Flood baseados em IP spoofing.
Saiba mais na documentação do Edge DNS da Azion.