RFC 8482
|
Getting your Trinity Audio player ready...
|
 |
Com as opções de serviço de nuvem “bombando” freneticamente para quase tudo que temos em TI, e outros serviços, fica fácil de escolher um serviço qualquer e simplesmente clicar em START e começar a usar.
Como bons profissionais, sabemos que por trás desse “START” roda uma imensidão de coisas para fazer esse simples deploy começar a funcionar, mas um recurso que é extremamente utilizado, ainda mais hoje, acaba ficando de lado porque é tão simples que alguns esquecem, o serviço de resolução de nomes, também conhecido como DNS.
Provavelmente 99% do que você usa tanto na internet quanto “em casa” é resolvido por nome, esse blog por exemplo, você chegou aqui pelo endereço de nome, não da pra acessá-lo por IP, seu serviço de email, um site qualquer, aquele endereço no listener do SQL, etc.
Mesmo sendo uma requisição simples em UDP na porta 53, essa requisição gera um trafego de internet, para cada vez que alguém consulta algum endereço, toda uma mágica tem que acontecer, basicamente é assim:
- A requisição da aplicação é encaminhada para para o SO
- Essa solicitação passa para o mini-driver de rede e procura no cache para saber se tem alguma coisa em cache para adiantar o serviço, caso não tenha ele…
- pega a lista dos endereços de DNS cadastrados na interface
- requisita ao DNS cadastrado a resolução de nome para o endereço solicitado
- se os servidores cadastrados tiverem em cache o endereço ele devolve a ao requisitante caso não,,,
- Vão para os ROOT´s cadastrados para iniciar a consulta pública,
- tudo começa no “.” depois o sufixo que pode ser “com”, “net”, “br”, “ca”, etc…
- Depois localiza o nome intermediário do domínio, que é o nome em si, e resolve o DNS master e slave
- conecta no DNS master e slave e resolve o SOA
- pergunta sobre o RR do endereço em questão e aí a resposta pode variar para um A, MX, AAA, TXT, CNAME, etc.
- volta com o resultado para o servidor de DNS lá cadastrado na interface, faz o cache pelo TTL, e devolve a resolução do nome para a interface solicitante com o TTL do registro
Basicamente, porque é um pouco mais complexo que isso, esse é o processo feito para cada vez que é requisitada uma resolução de nome, tudo isso em UDP e o mais rápido possível.
E o que a RFC 8482 tem a ver com isso?
Por padrão, quando é feita uma consulta de DNS esse método é direto, um RR para um domínio e apenas isso, mas existe um método de consulta que é o ANY que significa basicamente um traga todas as informações disponíveis do domínio requisitado.
Essas “todas as informações” são compostas de:
- Nomes do servidores DNS
- serial
- refresh da zona
- retry
- expiração
- TTL da zona
- email do responsável
- nome do servidor de resposta primário
- MX
- text
- e o IP de resposta para o root
Certo, mas qual o problema?
O volume trafegado é maior, o tempo de conexão com o DNS é maior e o volume de requisições pode afetar o desempenho na experiência, para dar time out de requisição de DNS o serviço pode demorar até 2 segundos para resolver o endereço, imagina isso para uma aplicação onde do total do tempo gasto 2 segundos foram apenas para resolver nome, onde ela vai ter que tentar novamente por houve time-out.
Existe um método de ataque que é o de amplificação de DNS, onde uma onda de requisição ANY sobrecarrega o serviço causando um DDoS e sem DNS sem aplicação.
Na ponta do lápis estamos falando em uma requisição direta requisitar alguma coisa em torno de 44 bytes, enquanto uma requisição ANY (pode variar) mas para uma média dica em 890 bytes.
Não parece muita coisa certo? agora imagina isso para um servidor de DNS respondendo para não apenas suas requisições mas para todos os domínios cadastrados nele, mais replicar para um secundário, mais atualizações vindas de aplicações.
Como evitar requisições ANY?
Basicamente, adicione um RR no DNS do tipo HINFO com alguma informação.
Ex. HINFO RFC8482
quem faz isso?
WikiPedia, CloudFront
Filed under: TI - @ 2021-11-11 1:17 am