O Que É DNS e Como Funciona a Resolução de Nomes

O que o DNS realmente faz em cada requisição

Toda requisição para example.com começa com uma busca que não tem nada a ver com sua aplicação: algo precisa transformar aquele nome em um endereço IP antes que um único pacote TCP saia da máquina. Essa tradução é o DNS, o Domain Name System, e ela acontece em toda requisição, seja o cliente um navegador, o curl, ou um serviço de backend chamando outro pelo hostname.

Não existe uma única tabela por trás disso. O DNS é uma hierarquia de servidores, cada um responsável por uma fatia do namespace, consultados em sequência até a resposta voltar. Conhecer essa cadeia é o que transforma “o site está fora do ar” em “o certificado expirou” ou “o registro ainda aponta para o IP antigo”: dois problemas bem diferentes que, vistos de uma aba do navegador, parecem idênticos.

Como um resolver recursivo percorre a hierarquia do DNS

Dois tipos de servidor fazem esse trabalho, com funções diferentes. O resolver recursivo é aquele com quem sua máquina conversa: o do seu provedor, ou um público como 1.1.1.1 ou 8.8.8.8. Ele faz o percurso por você e devolve uma única resposta final. Os servidores autoritativos guardam os registros reais de um domínio, distribuídos numa hierarquia que espelha os pontos do nome.

1
2
3
4
5
6
7
8

cliente  ->  resolver                             uma consulta, uma resposta
             resolver -> servidor raiz            "quem cuida do .com?"
                      <- nameservers de .com
             resolver -> servidor TLD .com        "quem cuida de example.com?"
                      <- nameservers de example.com
             resolver -> nameserver example.com   "registro A de example.com?"
                      <- 93.184.216.34
cliente  <-  resolver                             93.184.216.34

Os servidores raiz não sabem nada sobre example.com. Sabem apenas quais servidores cuidam do .com. O servidor TLD (top-level domain) do .com também não guarda o registro; ele só sabe quais nameservers são autoritativos para example.com, os que o seu registrador aponta quando você configura o domínio. Só esse último servidor guarda o registro A e devolve um IP. Três idas e voltas, para que sua máquina nunca precise saber que essa hierarquia existe.

Boa parte desse percurso nunca acontece numa consulta real. Os resolvers guardam em cache as respostas de servidores raiz e TLD por horas ou dias, já que quase não mudam, então uma consulta real costuma começar direto no servidor autoritativo do registro específico. Muitas vezes nem chega até lá: a resposta já está em cache.

Os tipos de registro DNS que você vai usar de verdade

O servidor autoritativo de um domínio guarda um conjunto de registros, cada um respondendo a uma pergunta diferente:

O CNAME é o que engana todo mundo. Ele não aponta para um IP; aponta para outro nome, e o resolver também precisa buscar esse nome, seguindo a cadeia até chegar a um registro A ou AAAA. Uma CDN ou uma plataforma SaaS te dá um hostname como abcd123.cloudfront.net exatamente por isso: ela pode mudar os IPs por trás daquele nome quando quiser, e devolver um diferente dependendo de onde a consulta veio, sem que você precise mexer no seu registro DNS.

Uma restrição pega todo mundo que configura um domínio nu: um CNAME não pode coexistir com outros registros no mesmo nome, e o ápice da zona (example.com sem subdomínio) sempre precisa de registros NS e SOA. Então você não pode fazer um CNAME do ápice para o hostname de uma CDN, só de um subdomínio como www. Os provedores contornam isso com o que chamam de ALIAS, ANAME, ou CNAME flattening: o servidor autoritativo resolve o destino sozinho e devolve um registro A, então o ápice parece um registro de endereço comum para qualquer cliente, mesmo enquanto acompanha os IPs que mudam por trás da CDN.

Como consultar o DNS com dig

O dig faz essas perguntas diretamente, sem o cache de um navegador no meio do caminho.

1

dig example.com

A parte que importa é a ANSWER SECTION:

1
2

;; ANSWER SECTION:
example.com.        300    IN    A    93.184.216.34

Cinco campos, em ordem: o nome consultado, o TTL em segundos (por quanto tempo essa resposta pode ficar em cache), a classe (IN de internet, na prática sempre essa), o tipo de registro e o valor. Um TTL de 300 significa que qualquer resolver com essa resposta vai consultar de novo dentro de cinco minutos.

Consulte um tipo específico em vez do A padrão:

1
2
3

dig example.com MX
dig example.com TXT
dig example.com NS

Adicione +short quando quiser só o valor, que é o que você quer num script:

1
2

dig +short example.com
93.184.216.34

Consulte um resolver específico com @. É assim que você verifica se uma mudança já chegou a um provedor antes de chegar até você:

1
2

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

O +trace reproduz todo o percurso, do servidor raiz até a resposta autoritativa, em vez de confiar num resultado em cache:

1

dig +trace example.com

O nslookup faz o mesmo trabalho básico com uma interface mais antiga e mais verbosa. Vale a pena conhecer porque vem instalado por padrão no Windows, onde o dig muitas vezes não está.

Por que uma mudança de DNS demora: TTL e cache

Você muda um registro e ele não aparece em todo lugar na hora. Esse atraso é chamado de “propagação”, uma palavra que sugere algo se espalhando pela internet cópia por cópia. Nada se espalha. O novo valor já está ativo no servidor autoritativo no momento em que você salva. O que demora é cada resolver que já tinha a resposta antiga em cache e continua servindo ela até essa cópia expirar.

Isso muda a pergunta certa a se fazer. Não “quanto tempo demora a propagação”, mas “qual era o TTL do registro antigo, e quantos resolvers guardaram ele em cache”. Um TTL de 300 segundos significa que um resolver que consultou há um minuto serve a resposta antiga por no máximo mais quatro minutos. Um TTL de 86400 significa que algum resolver em algum lugar responde com o IP antigo por até um dia depois da sua mudança. Alguns provedores também ignoram o TTL que você definiu e guardam em cache por mais tempo do que você pediu, que é o outro motivo pelo qual duas pessoas em redes diferentes podem, honestamente, ver respostas diferentes no meio de uma mudança.

Então planeje a mudança em vez de esperar ela passar sozinha. Um dia antes de uma migração planejada para um novo servidor ou uma nova CDN, baixe o TTL do registro que você vai mexer para 60 ou 300 segundos. Esse TTL baixo precisa primeiro chegar nos caches e expirar as cópias de vida longa. Depois faça a mudança de verdade: todo resolver agora se atualiza dentro da nova janela curta em vez da antiga longa. Suba o TTL de volta assim que o novo valor estiver confirmado.

Erros comuns de DNS, e quando o problema não é o DNS

Um CNAME órfão é o erro mais comum na prática. Um subdomínio ainda aponta para um serviço desativado, um bucket S3 antigo ou uma distribuição de CDN apagada, e quem reivindicar aquele nome do outro lado pode servir o próprio conteúdo sob o seu domínio. Apague o registro DNS no mesmo dia em que você desativa o que ele apontava, não semanas depois.

Registros MX ausentes ou errados parecem um problema do servidor de e-mail. Se o e-mail de saída funciona mas nada chega, verifique o registro MX do domínio antes de mexer na configuração do servidor de e-mail; ele pode ainda apontar para um serviço do qual você migrou meses atrás.

Muitos relatos de “o DNS está quebrado” não são DNS de forma alguma. Se dig example.com devolve o IP atual correto e o site ainda não carrega, a resolução já deu certo e o problema está mais adiante: uma regra de firewall, um certificado que não bate no handshake TLS, ou um reverse proxy roteando com base num header Host que ele não reconhece. Confira a resposta com dig antes de tirar conclusões do que o navegador mostra.

Onde checar primeiro quando um domínio não resolve

Rode dig +short <domínio> contra o seu resolver do sistema e contra um público (dig @1.1.1.1 +short <domínio>). Se eles discordarem, você está no meio de uma mudança, e o TTL antigo diz quanto tempo mais esperar. Se concordarem e o IP estiver certo, o DNS fez o trabalho dele: siga para TLS, roteamento ou a aplicação. Se o IP estiver errado ou nada voltar, corrija no nameserver autoritativo. Limpar o seu cache local não muda nada do que qualquer outra pessoa vê.

Artigos relacionados

• O Que É um CDN e Como Funciona
• O Que É TLS e Como Funciona a Criptografia HTTPS
• O Que É um Reverse Proxy e Como Funciona