Como funciona o DNS - Do domínio ao IP · oGuedes

Nessas férias da faculdade tenho tentando me aprofundar mais em assuntos sobre Web, mas sem ser sobre linguagens ou frameworks. Nisso eu percebi que nesses dois anos desenvolvendo software eu nunca entendi de verdade como funcionava o processo do DNS (recebendo um domínio, e retornando um IP). E como na internet tem muitas explicações bem simples, ou técnicas até demais, decidi estudar bastante sobre o assunto e acho que finalmente entendi uns 70-80% sobre o assunto.

Quando estudamos sobre desenvolvimento web, aprendemos rápidamente que quando pesquisamos um site (ex: google.com) no browser, o Protocolo HTTP vai enviar a url pro DNS, e ele magicamente vai nos retornar o IP do servidor que queremos acessar. Mas o buraco é bem mais fundo que isso, diria até 3 níveis mais fundo.

1 - DNS Client + DNS Server + Root Server

Quando fazemos a requisição prum site, estamos assumindo o papel de um DNS Client (igual o conceito de client-server que o HTTP passa), onde ele pega o domínio que querems acessar (google.com) e envia pro DNS Server. Ele é um servidor (pode ser público, ou o nosso ISP (Provedor de Internet)) que tem acesso a uma lista atualizada com a localização de todos os Root Server do mundo.

Root Server (assim como o DNS Server) é um conjunto de 13 servidores (Root Server A até o Root Server M) que são mantidos por empresas muito importantes no mundo da tecnologia (ex: o Root Server J é mantido pela Cloudflare), que conseguem identificar o TLD (Top-Level Domain) do nosso domínio (ex: .com, .br, etc.)

Quando o Root Server identificar que o nosso domínio pertence ao TLD .com, ele irá informar pro DNS Server a localização desse TLD

2 - TLD Server

Assim como o Root Server, o TLD (Top-Level Domain) também é um conjunto de servidores mantidos por organizações importantes (ex: o .br é mantido pelo NIC.br), mas que tem o objetivo de informar o Name Server do domínio que queremos acessar. Podemos entender como Name Server o IP do serviço de hospedagem onde está o servidor do site que queremos acessar, E NÃO O IP DO SERVIDOR

Um desenvolvedor informar pra qual Name Server seu domínio deve apontar, após comprar o domínio (ex: pode comprar no Registro.br e apontar lá), e ele sabe pra qual Name Server apontar após pagar um serviço de hospedagem e copiar o que ela mandar usar.

Ou seja, o TLD informa pro DNS Server o endereço do serviço de hospedagem (do servidor do site que queremos acessar)

3 - Authoritative Server

Por fim, o endereço do Name Server nos faz chegar até o Authoritative Server, eu não entendi muito bem se ele é o servidor do serviço de hospedagem rodando outros servidores (inclusive o do site que queremos acessar), ou se ele é uma feature/funcionalidade específica do serviço do hospedagem. O que importa, é que ele vai finalmente ver o domínio que queremos acessar (google.com) e vai retornar pro DNS Server o IP correto. E o DNS Server vai retorná-lo para nós.

Cache em todo lugar

Por mais que pareça que essas três etapas sejam muito específicas para simplesmente chegarmos no IP do site que queremos acessar, normalmente (levando em conta sinal de internet, etc.) essas etapas são finalizadas em milissegundos. Podemos testar o tempo da consulta pelo Ubuntu, rodando o comando:

dig www.google.com

Porém, como forma de otimizar essas consultas, sempre que pesquisarmos um site pelo browser, nós não passaremos diretamente por essas 3 etapas, na verdade (não sei se o HTTP) vai tentar ver se já temos oIP que queremos acessar, armazenado num cache, que pode ser:

No cache do browser se já acessamos esse site antes;
No cache do nosso sistema operacional;
No cache do nosso Local DNS Server (ex: nossos Roteadores, Moldens, etc.);

E mesmo que o IP não esteja nesses caches, eles podem estar nos do DNS Server (ex: nosso provedor de internet) caso seja sites muito acessados. No final, se não conseguirmos, faremos as 3 etapas vistas anteriormente.

Tipos de consulta

Por fim, mesmo que sempre tenhamos que passar por essas 3 etapas (Root Server, TLD e Authoritative Server), existem duas formas de implementá-las.

A primeira são as Consultas Recursivas, que é basicamente o passo a passo que lemos acima, onde um DNS Server entra em contato com o Root Server, depois o Root Server entra em contato com o TLD, depois o TLD com o Authoritative Server, e por fim cada um vai passando o IP retornado pra trás, até chegar no DNS Server, e ele dar pro DNS Client (nós no caso)

Já a segunda forma são as Consultas Iterativas, o DNS Server que entrará em contato com cada um, sendo primeiro com o Root Server, depois com o TLD, e o Authoritative Server