Política de cache DNS em muitos registros

Question

Todos sabemos que quando eu solicito algum nome de host eu me conecto ao meu servidor DNS, que verifica se ele tem seu registro correspondente no cache, e se não ele se repetir, se necessário, até o DNS autoritativo para esse hostname. / p>

Agora, em princípio, um DNS autoritativo pode representar uma enorme quantidade de registros. Tome este exemplo nodeJS:

var dnsd = require('dnsd')
dnsd.createServer(function(req, res) {
  res.end('1.2.3.4')
}).listen(53, '')

Se eu usar isso como um servidor autoritativo para meu domínio, qualquer solicitação para qualquer subdomínio resultará em um registro A apontando para 1.2.3.4 . Isso significa que, se um grupo de usuários começar a solicitar subdomínios aleatórios de meu domínio, o servidor DNS deles continuará pedindo novos registros para o meu e armazenando-os em cache.

Mas meu senso comum diz que, por exemplo, o 4.4.4.4 do Google não estará disposto a armazenar gigabytes de registros apenas porque algum nerd entediado jogou com duas linhas de nó.

Então, o que acontece então? O que acontece quando algum DNS já armazenou muitos registros em algum domínio e não quer armazenar mais? O domínio será bloqueado ou banido? Os registros antigos serão descartados antes que o TTL expire? Existe alguma política oficial para isso?

    

Answer 1

Como diz Calle, sua implementação é específica. Eu vou entrar em um pouco mais de detalhes.

A abordagem mais comum que os servidores de nomes usam é uma abordagem baseada em memória . Um teto de memória é definido (como padrão ou na configuração pelo usuário) e, em dados de operação normal, é armazenado em cache até expirar. Quando o limite máximo de memória é atingido, o software começa a descartar menos registros usados para liberar memória para registros mais recentes, geralmente começando com os dados mais antigos no cache e possivelmente considerando também os dados menos solicitados.

Muitas implementações de servidores de nomes não implementam qualquer tipo de lista negra de consultas baseadas em IP. Isso se deve principalmente ao fato de ser fácil falsificar endereços IP no UDP, o que tornaria muito mais fácil executar uma negação de serviço do DNS em relação a um IP legítimo que precisa dos dados. Eu poderia fingir ser seu IP, martelar os servidores de nomes do Google até que eles ignorem o seu IP, e então você não pode acessar o Google.com. Isso seria ruim, já que sem o Google Runbook, a maioria das pessoas da sua empresa perderia a capacidade de fingir que sabe como fazer o trabalho. Uma vez que você considere o fato de que o invasor pode simplesmente alterar o endereço IP que está falsificando se estiver bloqueado, a lista negra de IPs se torna uma opção muito pouco atraente para a maioria dos operadores de servidor.

Devido à crescente popularidade dos ataques de ciclagem de rótulos / nomes de host direcionados a servidores DNS recursivos (que não entro aqui), mais e mais pacotes de software estão começando a ativar opções para limitar a taxa consultas recebidas com base em vários critérios. A ideia aqui não é bloquear totalmente os IPs (porque o IP provavelmente é falsificado e é fácil falsificar um IP diferente), mas torná-lo menos eficiente e, portanto, pouco atrativo para usar o servidor DNS nesses tipos de ataques.

De qualquer forma, a versão curta é que você geralmente não precisa se preocupar com alguém recebendo seu domínio ou até mesmo seu IP "banido" de um servidor DNS recursivo. É certamente possível se as partes em questão não estão sendo aproveitadas em ataques com muita frequência e, portanto, não sabem por que é geralmente uma má ideia banir domínios ou IPs, mas é incomum. Os experientes só banirão seu domínio (temporariamente) se a plataforma deles estiver sendo aproveitada para atacar os servidores de nomes do seu domínio. Nesse caso, eles acreditam que estão fazendo um favor por não enviar-lhe consultas.

    

Answer 2

Comportamento de cache é totalmente a implementação. O único requisito é que as informações em cache devem estar corretas (naturalmente) e não devem ser mais antigas do que o TTL diz. Assim, o servidor em seu exemplo está livre para descartar registros com a maior rapidez e frequência possíveis.