Vamos apresentar o que é o DNS, seu funcionamento básico e como funciona uma consulta DNS.
Esse é a primeira parte de um conjunto de posts que vai detalhar o funcionamento do protocolo DNS.
- Motivação para usar o DNS
- Como começou o DNS
- O DNS
- Como funciona o DNS
- Exemplo de consulta DNS recursiva
- Por que o DNS local faz consulta recursiva?
- Somente o DNS local faz consulta recursiva?
- Por que o servidor raiz não faz a consulta recursiva?
- O que o DNS local faz com as consultas que chegam?
- Por quanto tempo um nome deve ficar armazenado no cache DNS?
- O que acontece quando uma consulta DNS não é respondida?
- Como evitar ficar sem acesso à Internet por falha de DNS no provedor?
- Exemplo de consulta DNS recursiva
- Como é uma consulta DNS?
Motivação para usar o DNS
Nomes são mais fáceis de serem gravados por humanos.
Portanto, ao invés de decorar vários números de IPs nós podemos aprender a lembrar dos nomes dos sites.
IPs podem mudar, mas se você tem um nome você pode atrelar esse nome ao seu novo IP .
Na figura abaixo, estamos supondo que o primeiro servidor WEB falhou.
Figura: ServerWEB fica no IP do computador :(203.0.113.1)
Agora vamos supor que o computador (203.0.113.1) falhou ou desligou.
No entanto, o usuário pode acessar o conteúdo depois que atrelamos o nome ao novo IP.
Agora vamos apontar o ServerWEB para o computador (203.0.113.5)
Podemos ter vários IPs associados a um mesmo nome, criando um balanceamento de carga.
Na figura acima, o primeiro usuário vai para o computador (203.0.113.1).
O Segundo usuário vai para o computador (203.0.113.2) e o terceiro usuário vai para o computador (203.0.113.3).
Dessa forma, a medida em que novos usuários vão acessando o mesmo nome o DNS vai criando um balanceamento de carga.
Isso porque o DNS divide o acesso para diferentes servidores WEB.
Livros Indicados:
E-Books de Redes e Segurança
Como começou o DNS
“Na ARPANET era usado o arquivo hosts.txt. Esse arquivo continha a lista de nomes de hosts e seus endereços IP.
Diariamente esse arquivo era usado para identificar o IP dos hosts pelo nome.
Problema do uso do arquivo hosts
Se estivermos em uma rede pequena, essa estratégia seria viável.
Por exemplo, poderíamos ter um único arquivo hosts.txt que fosse armazenado em um servidor e cada usuário utilizaria esse arquivo para suas consultas.
No entanto, em redes grandes, o uso do arquivo hosts.txt provoca alguns problemas. Dentre os problemas temos:
- Inconsistência na atualização de nomes e IPs. Consequentemente, essa inconsistência provocaria problemas na padronização do acesso de nomes e IPs.
- Arquivo hosts.txt muito grande. Arquivos hosts.txt traria lentidão na pesquisa de nomes e ocuparia mais memória de armazenamento.
- Além disso, se fossemos centralizar o arquivo hosts.txt em um único servidor, teríamos problemas de sobrecarga de recursos e menor tolerância a falhas.
O DNS
Criado para resolver os problemas relacionados a tradução de nomes e IPs foi criado o DNS (Domain Name System) em 1983.
O DNS foi criado para ter uma estrutura hierárquica e com um banco de dados distribuídos geograficamente.
Dessa forma, o DNS resolveria os problemas mencionados acima.
O DNS pode ser usado para mapear um nome em IPs ou para saber o nome associado a um IP (Consulta reversa).
Atualmente, o DNS está definido também nas RFCs: 1034, 1035, 2181.
Como funciona o DNS
O DNS é utilizado da seguinte forma: para mapear um nome em um endereço IP, um programa de aplicação chama um procedimento de biblioteca (normalmente, gethostbyname ou algo equivalente) e repassa a ele o nome como um parâmetro.
Depois disso a consulta de nomes é repassara para o DNS local, como na figura abaixo.
Nota. O processo do resolvedor de nomes pode ser chamado de resover stub.
O DNS faz o mapeamento de um nome para um endereço IP usando chamadas de procedimentos como por exemplo “gethostbyname”.
Vale ressaltar que a consulta a esse mapeamento é feita para um resolvedor de nomes local (o DNS local).
Esse resolvedor de nomes local é responsável por iniciar uma pesquisa recursiva utilizando vários resolvedores de DNS.
Exemplo de consulta DNS recursiva
Podemos usar como exemplo um navegador acessando um nome de página pela primeira vez.
Inicialmente o navegador iria repassar a requisição da resolução do nome para o processo responsável pela resolução de nomes.
Em seguida o host iria repassar a requisição ao servidor DNS local ou DNS padrão do host.
O host faz a consulta ao seu DNS local e espera a resposta.
Depois disso, o DNS local verifica se possui em cache a o nome que responde a consulta.
Caso o DNS padrão/local saiba resolver aquele nome, este retornará o IP.
Caso o DNS local não tenha o nome em cache, este faz consultas recursivas para cada pedaço hierárquico do nome que está sendo buscado.
Depois de terminada a consulta recursiva o resolvedor local devolve a resposta, que na maioria das vezes é um IP.
Consequentemente, o host pode entregar o endereço de IP para a aplicação que pediu e essa pode realizar o acesso usando o IP.
Nota. Ao longo do tempo as consultas DNS eram majoritariamente com UDP.
No entanto, o DNS também pode realizar consultas usando o protocolo TCP.
Por que o DNS local faz consulta recursiva?
O servidor DNS local faz consultas recursivas porque atende apenas aos hosts do seu domínio. Dessa forma, a consulta recursiva não gera uma sobrecarga ao DNS local.
Somente o DNS local faz consulta recursiva?
Para responder essa pergunta vamos investigar como os outros DNSs respondem as perguntas. Os servidores de DNS raiz não trabalham de forma recursiva, ao invés disso esses servidores indicam outros DNSs que podem responder parte da consulta de nomes. De posse dessa informação, o DNS local vai perguntar par ao DNS que o servidor DNS raiz indicou.
Por que o servidor raiz não faz a consulta recursiva?
A verdade é que a consulta recursiva causa muita sobrecarga para o o servidor que está executando.
Dessa forma, o servidor DNS raiz prefere passar a consulta de forma interativa e responder informando quem o DNS local deve consultar para completar sua descoberta de nomes.
O que o DNS local faz com as consultas que chegam?
As respostas das consultas são armazenadas no cache, isso inclui as respostas das consultas parciais.
Assim, como a consulta recursiva retorna informações parciais até que todo o domínio seja alcançado, o cache do DNS local vai armazenar também as informações parciais.
Ao armazenar as respostas das consultas em cache, o DNS local permite que novas consultas para o mesmo domínio sejam respondidas sem que haja uma nova consulta.
Dessa forma, o cache promove um maior desempenho já que parte das consultas em uma empresa tendem a ser repetidas.
Por quanto tempo um nome deve ficar armazenado no cache DNS?
A resposta para essa pergunta é depende de quão volátil é a informação do domínio.
Isso significa que domínios que variam com menor frequência podem ficar mais tempo no cache dos DNS locais.
Ao contrário, domínios que têm uma alta volatilidade em termos de mapeamento de nomes em IPs devem ter uma curta duração nos caches do DNS local.
O que acontece quando uma consulta DNS não é respondida?
O DNS local faz uma requisição e aguarda por um tempo. Então, caso não receba uma resposta, o DNS local vai tentar um outro servidor DNS que possa responder sua consulta.
É muito comum vermos em alguns sistemas o papel do DNS secundário.
Um host pode usar um DNS secundário para responder às suas requisições quando o DNS primário falhar ou estiver sobrecarregado.
Nota. Utilizar um DNS secundário em um host pode evitar problemas com a falta de conexão com a Internet.
Muitas vezes o DNS do nosso provedor de internet fica sobrecarregado ou mesmo passa por alguma falha.
Essa falha pode nos levar a uma conclusão errada de que estamos sem acesso à Internet. No entanto, o que estamos é sem acesso a um servidor DNS que possa atender às nossas consultas.
Como evitar ficar sem acesso à Internet por falha de DNS no provedor?
Uma das formas de evitar ficar sem acesso à internet por falha no servidor DNS do provedor é acrescentar um segundo DNS na configuração de rede do seu host.
Nesse caso, podemos usar DNSs públicos como o do google “8.8.8.8”.
Dessa forma, caso o DNS do seu provedor apresente alguma falha, o seu host vai usar o segundo DNS que você inseriu nas configurações.
A figura abaixo apresenta uma configuração em que usamos um DNS secundário da google.
Nesse caso, estamos usando o “8.8.8.8” como secundário.
Como é uma consulta DNS?
Nos dados da consulta, temos um ID de transação e o nome que está sendo consultado.
O ID de transação serve para manter um controle sobre a transação de pedido e reposta DNS.
A consulta recursiva na maioria das vezes utiliza uma Query Name (QNAME) mínima.
Dessa forma o DNS local pode enviar uma parcela da consulta para o servidor de nomes que atende apenas aquela parcela da consulta, como por exemplo um servidor de nomes autorizado.
Vamos supor que nosso servidor DNS local vai realizar a pesquisa sobre o nome www.simplificandoredes.com.
Nesse caso, o nosso DNS enviaria a consulta para um servidor DNS autorizado, requisitando apenas simplificandoredes.com.
Ou seja, não enviaria todo o nome de domínio totalmente qualificado (FQDN, Fully Qualified Domain Name).
Essa forma de enviar consultas minimizadas auxilia na segurança.
Inicialmente o DNS usava o protocolo UDP e porta 53 para atender aos pedidos de requisição.
Com o passar dos anos, foram desenvolvidos ataques de negação de serviço e envenenamento de cache que exploravam vulnerabilidade na requisição de nomes.
Além disso, a utilização do UDP foi motivada inicialmente para garantir uma maior velocidade no atendimento das requisições DNS.
No entanto, a velocidade de acesso à internet nos tempos atuais permite que a consulta DNS utilize o TCP sem que haja um prejuízo significativo na velocidade de resposta às requisições de nomes.
Por que o TCP causa uma maior lentidão na resposta DNS?
A lentidão causada pelo TCP se deve ao início da conexão TCP que utiliza 3 way handshake para realizar a conexão e depois enviar os dados.
Dessa forma, ao invés de enviar apenas uma requisição, como faria com o uso do UDP, o DNS com TCP vai fazer as 3 vias do handshake e somente depois disso que será dada a resposta da consulta DNS.
Vale a pena usar DNS com TCP?
Se pensarmos que o TCP permite o uso de protocolos mais seguros como DNS-over-TLS (DoT) e DNS-over-HTTPS (DoH), então a resposta é sim.
Livros Indicados:
E-Books de Redes e Segurança
Veja mais em:
Instalação de servidores em Docker
Addrwatch : Instalar e Configurar
Juliana Mascarenhas
Data Scientist and Master in Computer Modeling by LNCC.
Computer Engineer
