Resumo

  • O RRL reduz respostas autoritativas semelhantes e repetidas quando consultas UDP falsificadas poderiam transformar o servidor em amplificador de tráfego.
  • A participação de Paul Vixie foi relevante, mas compartilhada: a ISC registra conversas defensivas com ele, e um chamado de desenvolvimento do BIND também cita Vernon Schryver.
  • O mecanismo agrupa classes de resposta e faixas de endereços dos clientes. Isso controla o fluxo; não autentica, atribui ou comprova intenção.

Quando a resposta vira carga de ataque

Em um ataque de reflexão DNS, uma consulta chega a um servidor autoritativo com o endereço da vítima forjado como origem. A resposta do servidor vai parar na vítima. Se for muito maior que a consulta, o atacante convenceu o servidor a enviar mais dados do que enviou diretamente.

A apresentação da ISC em 2014 traz um exemplo: uma consulta ANY de 36 bytes para isc.org poderia receber uma resposta de 3.576 bytes. O exemplo mostra por que a reflexão interessa a atacantes, mas não define uma proporção universal. O tamanho depende da pergunta, dos dados da zona, do DNSSEC, do transporte e da resposta. A questão operacional é mais limitada: quantas respostas repetidas e parecidas um servidor autoritativo deve continuar enviando quando recebe consultas semelhantes?

A ISC afirma que sessões internas de estratégia defensiva com Paul Vixie levaram ao RRL. Um registro de desenvolvimento do BIND identifica Vixie e Vernon Schryver como autores do patch para o BIND 9. As fontes sustentam a participação central de Vixie, não a narrativa de inventor solitário. O RRL nasceu de trabalho operacional compartilhado, virou implementação e seguiu sendo ajustado.

O perfil da Internet Hall of Fame situa esse episódio em uma trajetória mais ampla no DNS. Vixie começou a manter o BIND 4 na Digital Equipment Corporation em 1988 e mais tarde se tornou o principal autor e arquiteto técnico do BIND 8. Também fundou MAPS, PAIX e Internet Software Consortium e fez doutorado na Keio University sobre DNS e DNSSEC. Esses marcos mostram a amplitude do trabalho, mas não alteram o crédito compartilhado pelo patch do RRL, que também cita Schryver.

No BIND 9.9.4, o RRL entrou como recurso opcional de compilação. A página da ISC “BIND 9.10 Significant Changes” informa que o RRL passou a integrar a configuração padrão de compilação. Isso registra a disponibilidade dentro do BIND; não comprova que todos os operadores autoritativos tenham ativado o recurso nem que todos os produtos DNS funcionem da mesma maneira.

O balde conta semelhança, não identidade

O manual atual do BIND 9.20.29 descreve baldes de tokens ou créditos formados por respostas semelhantes e clientes DNS. Cada resposta consome créditos, que se recompõem à taxa configurada durante uma janela de tempo. O operador pode limitar classes como respostas não vazias, NODATA, NXDOMAIN, referências, erros ou todas as respostas UDP. Ao ultrapassar a taxa, o BIND pode descartar ou alterar respostas selecionadas.

A palavra “cliente” embute uma escolha de política. Os padrões documentados do BIND agrupam endereços IPv4 por /24 e IPv6 por /56; endereços dentro do bloco entram na mesma contagem. Um resolvedor, uma empresa, uma universidade ou uma operadora pode atender muitas pessoas sem relação entre si por trás do mesmo prefixo. Se uma delas consumir o balde, outra pode receber uma resposta atrasada, truncada ou nenhuma resposta.

Isso não torna a agregação por prefixo necessariamente errada. Um limite por endereço pode ser contornado quando as consultas são distribuídas entre muitos endereços; durante uma inundação, o servidor também precisa dividir uma capacidade de saída limitada. Prefixo, classe de resposta e taxa têm custo de disponibilidade. São decisões operacionais explícitas, não uma leitura neutra de quem seria o cliente “de verdade”.

A opção slip do BIND deixa a troca mais clara. No slip=2, padrão documentado, a cada segunda solicitação limitada sem cookie de servidor válido é enviada uma resposta menor: BADCOOKIE se o cliente apresentou um cookie; caso contrário, o bit de truncamento pede uma nova tentativa por TCP. Alguns erros não podem ser truncados e passam na frequência definida por slip. O slip=1 envia respostas truncadas para todas as respostas limitadas, priorizando integridade e entrega em vez da supressão máxima da reflexão; o slip=0 descarta todas as respostas que excedem o limite. A possibilidade de tentar de novo também faz parte da defesa.

O papel do servidor muda a fronteira

A ISC recomenda RRL para servidores autoritativos. Sua documentação alerta que aplicá-lo à recursão pode gerar falsos positivos e atrasar clientes que consultam várias vezes os mesmos nomes; fechar a recursão aberta é a medida indicada. A mesma função tem custos diferentes em um serviço autoritativo público e em um resolvedor voltado aos usuários finais.

O BIND oferece log-only para observar limites candidatos antes de aplicá-los. Entre as métricas estão RateDropped, QryDropped, RateSlipped e RespTruncated. Elas mostram o efeito da configuração, não a identidade de um atacante. O endereço de origem observado pode ser falsificado, e a associação a um balde não serve como atribuição.

A Nota 65 de Heng Lu é usada aqui somente como lente editorial: é o comportamento em execução que revela o que uma implementação realmente controla. Ela não é fonte histórica sobre Vixie nem evidência técnica sobre RRL. Para avaliar o recurso, importam a versão do BIND em operação, a configuração, os contadores e a reação dos clientes às novas tentativas — não a mera presença de uma diretiva na documentação.

A conclusão sustentada pelas fontes é limitada. O RRL pode reduzir a contribuição de um servidor autoritativo para uma corrente de respostas semelhantes usada em reflexão. Também pode colocar clientes legítimos no mesmo grupo e impor uma escolha entre entrega e supressão. Não autentica consultas, não determina intenção, não mede adoção universal e não garante que a vítima deixará de receber tráfego refletido. A contribuição de Vixie é mais bem entendida como parte do esforço que transformou uma defesa operacional em um recurso configurável cujos limites podem ser inspecionados pelos operadores.

Fontes