Vamos começar do jeito certo: DNS (Domain Name System) é o sistema que traduz nomes (por exemplo, www.seusite.com.br) em endereços IP (por exemplo, 203.0.113.10), para que as máquinas consigam se conectar ao destino correto.
Tecnicamente, o DNS é um banco de dados distribuído e hierárquico mais um conjunto de protocolos para consultar e atualizar esses dados (RFC 1034 e RFC 1035). Ele guarda mais do que o mapeamento nome para IP: também publica para onde vai o e-mail do domínio, onde ficam certos serviços e textos de validação.
Se você ainda não leu, vale conhecer antes o Modelo OSI e o artigo O que é IP? Quais as diferenças entre IPv4 e IPv6?. Pense no DNS como a ponte entre o mundo humano (nomes) e o mundo roteável (IPs): sem ele, até daria para navegar, mas você teria que memorizar endereços.
Onde o DNS “mora” no modelo OSI e no TCP/IP
Modelo OSI: o DNS é um protocolo da camada 7 (Aplicação). Ele é consumido por aplicações (navegador, cliente de e-mail, serviços corporativos) e, por baixo, usa as camadas de transporte e de rede.
Modelo TCP/IP: fica na camada de Aplicação e usa normalmente UDP na porta 53 para consultas e respostas. O TCP na porta 53 entra quando a resposta não cabe em um pacote UDP (o servidor sinaliza com o bit TC, de truncado) e nas transferências de zona. O RFC 7766 define que os servidores devem aceitar TCP. Hoje também existem o DNS sobre TLS (porta 853) e o DNS sobre HTTPS, que cifram a consulta.
Visão prática, o que você precisa gravar:
Quando você digita um domínio, o seu computador não “vai à internet procurar o site”. Primeiro ele precisa do IP.
Quem entrega esse IP (ou pelo menos o “próximo passo” até ele) é o DNS.
Resolução recursiva vs autoritativa: quem pergunta para quem
Agora vem a parte que mais cai em troubleshooting.
Dois papéis diferentes, que muita gente mistura
Resolvedor recursivo: recebe a pergunta do cliente e se vira para trazer a resposta final. Ele consulta outros servidores DNS, segue as delegações e faz cache do resultado. Se não for autoritativo e não tiver a resposta em cache, parte dos servidores raiz para encontrá-la.
Servidor autoritativo: é o que “detém a verdade” sobre uma zona (por exemplo, example.com). Ele responde com base nos registros oficiais que estão configurados nessa zona.
Pergunta de prova prática: quando alguém diz “o DNS do meu domínio está errado”, de qual DNS estamos falando? Quase sempre o problema está no cache do recursivo ou na zona do autoritativo, e o tratamento muda completamente.
A trilha típica de uma consulta
Seu computador (um “stub resolver”) pergunta ao DNS recursivo configurado: o da empresa, do roteador ou do provedor.
Se o recursivo não tem a resposta em cache, ele pergunta, passo a passo, aos servidores raiz, depois aos servidores do TLD (como .com ou .br) e por fim ao autoritativo do domínio.
O recursivo guarda a resposta em cache pelo tempo do TTL e a devolve ao seu computador.
Na próxima vez que alguém pedir o mesmo nome, o recursivo responde direto do cache, até o TTL expirar.
Recursiva vs autoritativa, em uma frase
Recursiva: “eu te devolvo a resposta final (ou um erro)”.
Autoritativa: “eu sou a fonte oficial deste domínio”.
Isso explica dois comportamentos típicos:
“No meu computador abre, no do cliente não”: normalmente é diferença de cache no recursivo.
“Troquei no painel de DNS e não mudou”: pode ser TTL e cache (veremos já já) ou o domínio estar delegado a outro autoritativo, com o registro NS errado.
Principais tipos de registro que todo profissional de infra usa
Pense nos registros DNS como linhas de configuração que respondem à pergunta: para este nome, qual informação eu devo devolver? Duas regras mentais evitam erro em produção:
Nome (owner name): qual nome você está configurando? (www, api, _sip._udp, a raiz do domínio...)
Tipo (RR type): qual classe de informação você quer publicar? (IP, alias, e-mail, serviço...)
A seguir, os registros que você vai usar o tempo todo, com exemplos no formato de zona. Nos exemplos usamos o domínio example.com e endereços reservados para documentação. Se você administra o DNS por painel, os nomes dos campos mudam, mas a lógica é a mesma.
A: nome para IPv4
Aponta um nome para um endereço IPv4. Aparece em site, API, concentrador de VPN e servidor de aplicação exposto.
www.example.com. 300 IN A 203.0.113.10AAAA: nome para IPv6
Aponta um nome para um endereço IPv6. Aparece quando você tem pilha dupla (IPv4 e IPv6) ou um serviço só IPv6.
www.example.com. 300 IN AAAA 2001:db8:1234::10CNAME: apelido de um nome
Diz que um nome é apelido de outro nome. Aparece quando você aponta para o hostname de um CDN ou de um serviço SaaS.
blog.example.com. 300 IN CNAME www.example.com.O CNAME não entrega IP: ele manda o resolvedor seguir para outro nome. E há uma regra que causa muito erro em produção: um nome que tem CNAME não pode ter nenhum outro registro no mesmo nome (RFCs 1034 e 2181). Por isso não se coloca CNAME na raiz do domínio, onde já existem NS, SOA e, em geral, MX. Em painéis, o que alguns provedores chamam de “ALIAS” ou “CNAME flattening” é um recurso próprio deles, não um registro padrão.
MX: roteamento de e-mail
Indica para onde vão os e-mails do domínio. Aparece em Google Workspace, Microsoft 365 e servidor de e-mail próprio. Quanto menor o número de prioridade, mais preferido é o servidor.
example.com. 3600 IN MX 10 mail1.example.com.O destino do MX deve ser um nome com registro A ou AAAA, e não um CNAME (RFC 2181, seção 10.3).
TXT: texto, com usos modernos
Armazena texto. Na prática atual serve para dois grandes usos: a verificação de domínio (um serviço pede “crie um TXT com este token”) e a autenticação de e-mail (SPF, DKIM e DMARC). Aparece sempre que você integra serviços externos ou endurece o e-mail.
example.com. 3600 IN TXT "v=spf1 include:_spf.example.net -all"NS: quem são os servidores autoritativos (delegação)
Define os servidores de nomes autoritativos de um domínio. Aparece quando você aponta o domínio para Cloudflare, Route 53 ou outro provedor de DNS, e quando migra o DNS: trocar de provedor de DNS é, no fundo, trocar os NS no registro do domínio (no Registro.br, para domínios .br).
example.com. 86400 IN NS ns1.example.net.SRV: localização de serviços, com porta
Publica onde um serviço está, incluindo a porta. Os campos são, nesta ordem: prioridade, peso, porta e servidor de destino (RFC 2782). Aparece em SIP e VoIP, em alguns cenários de LDAP e Active Directory e na descoberta de serviços em geral.
_sip._udp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.Quem trabalha com SIP encontra o SRV (e o NAPTR) no jogo: é assim que um telefone ou um proxy descobre qual servidor atende um domínio, como descreve o RFC 3263.
TTL, cache e “por que a mudança não propaga”
Vamos atacar a frase clássica: “Eu alterei o DNS e não propagou.” Na maioria das vezes, propagou sim: só que alguém está respondendo com cache antigo.
O que é TTL (Time To Live)
TTL é o tempo que um resolvedor pode manter uma resposta em cache antes de descartá-la e perguntar de novo. TTL curto faz a mudança aparecer mais rápido, mas gera mais consultas. TTL longo dá estabilidade e desempenho, mas deixa a mudança mais lenta.
Onde o cache pode existir, e te confundir
Quando você muda um registro, a resposta antiga pode estar “presa” em vários lugares:
no DNS recursivo da empresa ou do provedor;
no sistema operacional (cache local);
no navegador, em alguns cenários;
em resolvedores públicos usados por alguns clientes.
A pergunta “já propagou?” depende de quem está perguntando e a qual resolvedor. Existe ainda o cache de respostas negativas: se alguém consultou um nome antes de você criar o registro, a resposta “não existe” (NXDOMAIN) também fica em cache, por um tempo definido no registro SOA da zona (RFC 2308).
Um mini-laboratório mental, que usamos em aula
Quando alguém diz “não propagou”, comece por três perguntas:
Qual registro você mudou? (A, CNAME, MX...)
Qual TTL estava configurado antes da mudança? O TTL antigo é o que manda no cache atual.
Você baixou o TTL com antecedência? É a boa prática em migrações.
Se você não baixou o TTL antes, o cenário típico é este: o TTL era de 4 horas, você mudou agora e alguns clientes continuam vendo o valor antigo por até 4 horas. Isso não é falha de propagação: é o DNS funcionando como projetado.
Boas práticas para não sofrer na virada de produção
Antes de uma migração: reduza o TTL (por exemplo, para 300 segundos) com antecedência, esperando pelo menos o tempo do TTL antigo, para que o valor baixo já esteja valendo nos caches quando você fizer a troca.
Depois que a migração estabilizar: aumente o TTL novamente.
Para diagnosticar: compare as respostas em resolvedores diferentes (o da empresa, o da rede móvel e um público). Se o autoritativo já responde com o dado novo, o problema costuma ser cache no caminho.
Como diagnosticar na prática com o dig
O dig (Linux e macOS; no Windows, o nslookup serve para o básico) mostra a resposta, o TTL restante e quem respondeu. Os cinco comandos que resolvem a maior parte dos casos:
# pergunta ao resolvedor configurado na sua máquina
dig www.example.com A +noall +answer
# pergunta a um resolvedor público específico
dig @1.1.1.1 www.example.com A +noall +answer
# descobre quem são os autoritativos do domínio
dig NS example.com +short
# pergunta direto a um autoritativo
dig @ns1.example.net www.example.com A
# percorre raiz, TLD e autoritativo, como um recursivo faria
dig +trace www.example.comComo interpretar: a resposta de um servidor autoritativo vem com a flag aa (authoritative answer) no cabeçalho. No resultado do dig, o número logo depois do nome é o TTL restante: se ele diminui a cada consulta ao recursivo, a resposta está vindo do cache. Se o autoritativo responde com o valor novo e o recursivo com o antigo, é cache, e a solução é esperar o TTL ou, no seu computador, limpar o cache local:
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux com systemd-resolved
resolvectl flush-cachesLimpar o cache local não limpa o cache do recursivo da sua empresa ou do seu provedor: esse você só vê expirar.
Resumindo
DNS traduz nomes em IPs e em outros dados, e é um banco de dados distribuído e hierárquico.
O recursivo busca e guarda em cache; o autoritativo é a fonte oficial da zona.
Conheça os registros: A, AAAA, CNAME (nunca na raiz), MX, TXT, NS e SRV.
“Não propagou” quase sempre é cache: baixe o TTL com antecedência e use o dig para comparar.
Na Parte 2, vamos tratar do DNS reverso (PTR), do DNS interno e de noções de DNSSEC. Se você quer reforçar a base de redes, conheça os nossos cursos.