Saiba como Paul Mockapetris criou o DNS, substituindo listas de hosts por um sistema de nomes escalável. Entenda como o DNS funciona, por que cache importa e noções básicas de segurança.
Toda vez que você digita um endereço web, clica em um link ou manda um e‑mail, está dependendo de uma ideia simples: humanos devem usar nomes memoráveis, enquanto os computadores fazem o trabalho de achar a máquina certa.
O DNS resolve um problema do dia a dia: computadores se comunicam usando endereços numéricos (IPs) como 203.0.113.42, mas as pessoas não querem memorizar sequências de números. Você quer lembrar example.com, não o endereço numérico que o site usa hoje.
O Sistema de Nomes de Domínio (DNS) é a “agenda” da internet que traduz nomes amigáveis pelo humano em endereços IP que os computadores usam para se conectar.
Essa tradução parece pequena, mas é a diferença entre uma internet utilizável e uma que parece uma lista telefônica escrita inteiramente em dígitos.
Este é um tour não técnico — sem necessidade de conhecimento de redes. Vamos ver:
No caminho, você conhecerá Paul Mockapetris, o engenheiro que projetou o DNS no início dos anos 1980. O trabalho dele foi importante porque ele não criou apenas um novo formato de nome — projetou um sistema que podia escalar enquanto a internet crescia de uma pequena rede de pesquisa para algo usado por bilhões de pessoas.
Se você já viu um site “cair”, esperou uma alteração de domínio “propagar” ou se perguntou por que configurações de e‑mail incluem entradas DNS misteriosas, já encontrou o DNS pelo lado de fora. O resto deste artigo explica o que acontece por trás das cenas — de forma clara e sem jargão.
Muito antes de alguém digitar um endereço web conhecido, redes iniciais tinham um problema mais simples: como alcançar uma máquina específica? Computadores podiam se comunicar usando endereços IP (números como 10.0.0.5), mas humanos preferiam nomes de host — rótulos curtos como MIT-MC ou SRI-NIC que eram mais fáceis de lembrar e compartilhar.
Para a ARPANET inicial, a solução foi um único arquivo compartilhado chamado HOSTS.TXT. Era essencialmente uma tabela de consulta: uma lista de hostnames pareados com seus endereços IP.
Cada computador mantinha uma cópia local desse arquivo. Se você queria conectar a uma máquina por nome, seu sistema olhava o HOSTS.TXT e encontrava o IP correspondente.
Isso funcionou no começo porque a rede era pequena, mudanças eram relativamente raras e havia um lugar claro para obter atualizações.
À medida que mais organizações entraram, a abordagem começou a ceder diante do crescimento normal:
A questão central era coordenação. HOSTS.TXT era como um livro de endereços compartilhado para o mundo inteiro. Se todo mundo depende do mesmo livro, cada correção exige uma edição global, e todo mundo precisa baixar a versão mais nova rapidamente. Quando a rede alcançou certo tamanho, esse modelo de “um arquivo para tudo” ficou lento demais, centralizado demais e sujeito a erros.
O DNS não substituiu a ideia de mapear nomes para números — substituiu a forma frágil como esse mapeamento era mantido e distribuído.
No início dos anos 1980, a internet estava mudando de uma pequena rede de pesquisa para algo maior, mais bagunçado e mais amplamente compartilhado. Mais máquinas entravam, organizações queriam autonomia e as pessoas precisavam de um jeito mais fácil de alcançar serviços do que memorizar endereços numéricos.
Paul Mockapetris, trabalhando nesse ambiente, é amplamente creditado como o desenhista do DNS. A contribuição dele não foi um produto chamativo — foi uma resposta de engenharia para uma pergunta prática: como manter nomes úteis quando a rede continua crescendo?
Um sistema de nomes parece simples até você imaginar o que “simples” significava na época: uma lista compartilhada de nomes que todo mundo tinha que baixar e manter atualizada. Esse método se quebra assim que a mudança se torna constante. Cada novo host, renomeação ou correção vira trabalho de coordenação para todo mundo.
A visão de Mockapetris foi perceber que nomes não são apenas dados; são acordos compartilhados. Se a rede expande, o sistema para criar e distribuir esses acordos precisa expandir também — sem exigir que todo computador busque constantemente uma lista mestra.
O DNS substituiu a ideia de “um arquivo autoritativo” por um desenho distribuído:
Essa é a genialidade silenciosa: o DNS não foi projetado para ser sofisticado, foi projetado para continuar funcionando sob restrições reais — largura de banda limitada, mudanças frequentes, muitos administradores independentes e uma rede que não parava de crescer.
O DNS não foi inventado como um atalho esperto — foi desenhado para resolver problemas específicos e práticos que surgiram à medida que a Internet crescia. A abordagem de Mockapetris foi definir objetivos claros primeiro e então construir um sistema de nomes que aguentasse por décadas.
O conceito chave é a delegação: grupos diferentes gerenciam partes diferentes da árvore de nomes.
Por exemplo, uma organização gerencia o que está sob .com, um registrador ajuda você a reivindicar example.com, e então você (ou seu provedor DNS) controla os registros para www.example.com, mail.example.com, e assim por diante. Isso divide a responsabilidade limpidamente, de modo que o crescimento não cria um gargalo.
O DNS assume que problemas vão ocorrer — servidores caem, redes se particionam, rotas mudam. Por isso ele conta com múltiplos servidores autoritativos para um domínio e com cache em resolvedores, de forma que uma interrupção temporária não quebre imediatamente todas as consultas.
O DNS traduz nomes amigáveis ao humano em dados técnicos, mais famosamente endereços IP. Não é “a própria Internet” — é um serviço de nomes e consulta que ajuda seus dispositivos a encontrar onde se conectar.
O DNS torna os nomes manejáveis organizando‑os como uma árvore. Em vez de uma lista gigante onde todo nome precisa ser único globalmente (e alguém teria que policiá‑la), o DNS divide os nomes em níveis e delega responsabilidade.
Um nome DNS é lido da direita para a esquerda:
www.example.com. termina tecnicamente com um ..com, .org, .net, códigos de país como .ukexample em example.comwww em www.example.comPortanto www.example.com pode ser quebrado em:
com (o TLD)example (o domínio registrado sob .com)www (um rótulo que o dono do domínio cria e controla)Essa estrutura reduz conflitos porque nomes só precisam ser únicos dentro do seu pai. Muitas organizações podem ter um www, porque www.example.com e www.another-example.com não colidem.
Também espalha a carga. Os operadores de .com não precisam gerenciar os registros de cada site; eles só apontam quem é responsável por example.com, e então o dono de example.com gerencia os detalhes.
Uma zona é simplesmente um pedaço gerenciável dessa árvore — os dados DNS pelos quais alguém é responsável publicar. Para muitas equipes, “nossa zona” significa “os registros DNS de example.com e quaisquer subdomínios que hospedamos”, armazenados no servidor autoritativo do provedor DNS.
Quando você digita um nome de site no navegador, você não está perguntando “à internet” diretamente. Alguns ajudantes especializados dividem o trabalho para que a resposta seja encontrada rápida e confiavelmente.
Você (seu dispositivo e navegador) começa com uma pergunta simples: “Qual o endereço IP correspondente a example.com?” Seu dispositivo normalmente ainda não sabe a resposta e não quer chamar uma dúzia de servidores para descobrir.
Um resolvedor recursivo faz a busca em seu lugar. Geralmente é fornecido pelo seu ISP, pelo TI da sua empresa/escola ou por um resolvedor público. O benefício chave: ele pode reaproveitar respostas em cache de consultas anteriores, acelerando as coisas para todos que o usam.
Servidores DNS autoritativos são a fonte de verdade para um domínio. Eles não “procuram” na internet; eles guardam os registros oficiais que dizem quais IPs, servidores de e‑mail ou tokens de verificação pertencem àquele domínio.
example.com.Pense no resolvedor recursivo como um bibliotecário que pode procurar por você (e lembrar respostas populares), enquanto um servidor autoritativo é o catálogo oficial do editor: ele não vasculha outros catálogos — simplesmente diz o que é verdade para seus próprios livros.
Quando você digita example.com no navegador, o navegador na verdade não está procurando por um nome — ele precisa de um endereço IP (um número como 93.184.216.34) para saber onde conectar. O DNS é o sistema “me encontre o número para este nome”.
Seu navegador primeiro pergunta ao sistema operacional do computador/telefone: “Já sabemos o IP de example.com?” O SO verifica sua memória de curto prazo (cache). Se encontrar uma resposta válida, a consulta termina aí.
Se o SO não tem, ele encaminha a pergunta a um resolvedor DNS — normalmente operado pelo seu ISP, empresa ou por um provedor público. Pense no resolvedor como seu “concierge DNS”: ele faz o trabalho pesado para que seu dispositivo não precise.
Se o resolvedor não tem a resposta em cache, começa uma busca guiada:
.com). O root não devolve o IP final — devolve referências, basicamente instruções: “Pergunte a esses servidores de .com a seguir.”.com): o resolvedor pergunta aos servidores de .com onde example.com é tratado. Novamente, não é o IP final — são mais instruções: “Pergunte a este servidor autoritativo por example.com.”A ou AAAA) contendo o endereço IP.O resolvedor manda o IP de volta ao seu SO, depois ao navegador, que enfim consegue conectar. A maioria das consultas parece instantânea porque resolvedores e dispositivos cacheiam respostas por um período definido pelo dono do domínio (TTL).
Um fluxo fácil de lembrar é: Navegador → cache do SO → cache do resolvedor → Root (referência) → TLD (referência) → Autoritativo (resposta) → de volta ao Navegador.
O DNS seria irritantemente lento se toda visita a um site exigisse começar do zero e perguntar a vários servidores pela mesma resposta. Em vez disso, o DNS depende do cache — uma “memória” temporária de consultas recentes — de modo que a maioria dos usuários obtém respostas em milissegundos.
Quando seu dispositivo pergunta a um resolvedor DNS por example.com, o resolvedor pode precisar fazer algum trabalho na primeira vez. Depois que aprende a resposta, ele a armazena em cache. A próxima pessoa que pedir o mesmo nome pode ser respondida imediatamente.
O cache existe por dois motivos:
Todo registro DNS é servido com um valor TTL (Time To Live). Pense no TTL como instruções que dizem: mantenha essa resposta por X segundos, depois descarte e pergunte novamente.
Se um registro tem TTL de 300, resolvedores podem reutilizá‑lo por até 5 minutos antes de rechecá‑lo.
TTL é um jogo de equilíbrio:
Se você estiver movendo um site para outro host, trocando um CDN ou fazendo corte de e‑mail (mudando registros MX), o TTL determina com que rapidez os usuários deixam de ir para o lugar antigo.
Uma abordagem comum é reduzir os TTLs antes de uma mudança planejada, fazer a troca e então aumentar os TTLs novamente quando tudo estiver estável. É por isso que o DNS pode ser rápido no dia a dia — e por que pode parecer “teimoso” logo após uma atualização.
Quando você entra num painel de DNS, geralmente vai editar alguns tipos de registro. Cada registro é uma pequena instrução que diz ao mundo onde mandar pessoas (web), onde entregar e‑mail, ou como verificar propriedade.
| Record | O que faz | Exemplo simples |
|---|---|---|
| A | Aponta um nome para um endereço IPv4 | example.com → 203.0.113.10 (seu servidor web) |
| AAAA | Aponta um nome para um endereço IPv6 | example.com → 2001:db8::10 (mesma ideia, endereçamento mais novo) |
| CNAME | Faz um nome ser um alias de outro nome | www.example.com → example.com (para que ambos apontem ao mesmo lugar) |
| MX | Diz para onde o e‑mail do domínio deve ir | example.com → mail.provider.com (prioridade 10) |
| TXT | Armazena “notas” que máquinas podem ler (verificação, política de e‑mail) | example.com com um SPF tipo v=spf1 include:mailgun.org ~all |
| NS | Diz quais servidores autoritativos hospedam o DNS de um domínio/zone | example.com → ns1.dns-host.com |
| SOA | O “cabeçalho” da zona: NS primário, contato admin e valores de temporização | SOA de example.com inclui ns1.dns-host.com e timers de retry/expire |
Alguns problemas de DNS aparecem repetidamente:
example.com). Muitos provedores não permitem porque o nome raíz também precisa carregar registros como NS e SOA. Se precisar apontar o root para um hostname, use um registro A/AAAA ou um recurso “ALIAS/ANAME” se o provedor suportar.www). Escolha uma abordagem.mail.provider.com pode quebrar e‑mail; pontos faltando/extras e copiar o campo host errado (por exemplo, @ vs www) é causa comum de interrupções.Se você distribui orientação DNS para uma equipe, uma pequena tabela como a de cima nos seus docs (ou em uma página de runbook) torna auditorias e troubleshooting muito mais rápidos.
O DNS funciona porque a responsabilidade é dividida entre muitas organizações. Essa divisão também é o motivo pelo qual você pode migrar provedores, mudar configurações e manter seu nome online sem pedir permissão à “internet”.
Registrar um domínio é comprar o direito de usar um nome (como example.com) por um período. Pense nisso como reservar um rótulo para que ninguém mais possa reivindicá‑lo.
Hospedar DNS é rodar as configurações que dizem ao mundo onde o nome deve apontar — seu site, provedor de e‑mail, registros de verificação etc. Você pode registrar um domínio com uma empresa e hospedar DNS em outra.
.com, .org ou .uk). Mantém o banco de dados oficial de quem detém cada nome sob esse TLD e quais servidores de nome são responsáveis por ele.Servidores root ficam no topo do DNS. Eles não sabem o IP do seu site e não armazenam os registros do seu domínio. O trabalho deles é mais restrito: dizer aos resolvedores onde encontrar os servidores autoritativos de cada TLD (por exemplo, onde .com é tratado).
Quando você define “servidores de nome” para seu domínio no registrador, você cria uma delegação. O registro de .com (por meio dos seus servidores autoritativos) então aponta consultas por example.com para os servidores de nome que você escolheu.
A partir desse momento, esses servidores de nome controlam as respostas que o resto da internet recebe — até você mudar a delegação novamente.
O DNS é construído sobre confiança: quando você digita um nome, assume que a resposta aponta para o serviço real. Na maioria das vezes é assim — mas o DNS também é um alvo comum, porque uma pequena mudança em “para onde este nome vai” pode redirecionar muitas pessoas.
Um problema clássico é spoofing ou envenenamento de cache. Se um atacante conseguir enganar um resolvedor DNS para armazenar uma resposta falsa, usuários podem ser enviados para o IP errado mesmo digitando o domínio correto. O resultado pode ser páginas de phishing, downloads maliciosos ou tráfego interceptado.
Outro problema é sequestro de domínio no nível de registrador. Se alguém invadir sua conta no registrador, pode mudar servidores de nome ou registros e efetivamente “assumir” seu domínio sem tocar no provedor de hospedagem.
Há também o perigo cotidiano: má configurações. Um CNAME indevido, um TXT antigo ou um MX incorreto pode quebrar fluxos de login, entrega de email ou checagens de verificação. Essas falhas frequentemente parecem que “a internet está fora”, mas a causa raiz é uma pequena edição de DNS.
DNSSEC adiciona assinaturas criptográficas aos dados DNS. Em termos simples: a resposta DNS pode ser validada para confirmar que não foi alterada em trânsito e que realmente veio do autoritativo do domínio. O DNSSEC não criptografa o DNS nem oculta o que você consulta, mas pode impedir muitos tipos de respostas forjadas de serem aceitas.
Consultas DNS tradicionais são fáceis de observar em redes. DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT) criptografam a conexão entre seu dispositivo e um resolvedor, reduzindo espionagem e alguma manipulação on‑path. Elas não tornam o DNS “anônimo”, mas mudam quem pode ver e manipular consultas.
Use MFA no registrador, habilite bloqueios de domínio/transferência e restrinja quem pode editar DNS. Trate mudanças de DNS como deploys de produção: exija revisão, mantenha um registro de alterações e configure monitoramento/alertas para mudanças de registros ou servidores de nome para saber sobre surpresas rapidamente.
O DNS pode parecer “configura e esquece”, até que uma pequena mudança derrube seu site ou e‑mail. A boa notícia: alguns hábitos tornam o gerenciamento previsível — mesmo para equipes pequenas.
Comece com um processo leve e repetível:
A maioria dos problemas de DNS não é complexa — apenas difícil de perceber rápido.
Se você faz deploys frequentes, o DNS vira parte do processo de release. Por exemplo, equipes que publicam apps em plataformas como Koder.ai (onde você pode construir e deployar apps via chat e depois associar domínios customizados) ainda dependem dos mesmos fundamentos: alvos A/AAAA/CNAME corretos, TTLs sensatos durante cortes e um caminho claro de rollback se algo apontar para o lugar errado.
Se você envia e‑mail do seu domínio, o DNS afeta diretamente se mensagens chegam às caixas de entrada.
Nomes amigáveis ao humano fizeram a internet escalar além de uma comunidade de pesquisa. Trate o DNS como infraestrutura compartilhada — um pouco de cuidado antecipado mantém seu site acessível e seu e‑mail confiável conforme você cresce.
O DNS (Domain Name System) traduz nomes amigáveis ao humano como example.com em endereços IP como 93.184.216.34, para que seu dispositivo saiba para onde se conectar.
Sem o DNS, você teria que memorizar endereços numéricos para cada site e serviço que usa.
Redes iniciais dependiam de um único arquivo compartilhado (HOSTS.TXT) que fazia o mapa entre nomes e endereços IP.
À medida que a rede cresceu, isso virou um problema: atualizações constantes, conflitos de nomes e falhas causadas por cópias desatualizadas. O DNS substituiu o modelo de “um arquivo global” por um sistema distribuído.
Paul Mockapetris projetou o DNS no início dos anos 1980 para resolver o problema de escala dos nomes numa rede em rápido crescimento.
A ideia-chave foi a delegação: dividir responsabilidade entre muitas organizações para que não exista uma lista mestre (ou administrador) que vire gargalo.
Os nomes DNS são hierárquicos e lidos da direita para a esquerda:
www.example.com..comexample.comwww.example.comEssa hierarquia torna a delegação e a gestão práticas em escala global.
Um resolvedor recursivo pesquisa respostas em seu nome e as guarda em cache (geralmente fornecido por ISP, empresa ou um resolvedor público).
Um servidor DNS autoritativo é a fonte de verdade para os registros de um domínio; ele não “pesquisa” a internet — ele responde pelo seu zoneamento.
Um fluxo típico é:
.com) → servidores autoritativos do domínio.A/).TTL (Time To Live) indica por quanto tempo os resolvedores podem armazenar uma resposta em cache antes de checar novamente.
“Propagação” é, na prática, apenas caches expirando em momentos diferentes.
Os registros mais comuns que você vai gerenciar são:
Um registrar é onde você registra/renova o nome de domínio (seu direito de usar example.com).
Um provedor de DNS/host executa os servidores autoritativos e armazena seus registros DNS.
Você pode registrar em uma empresa e hospedar DNS em outra alterando os NS (servidores de nome) no painel do registrador.
O DNS pode falhar por:
Defesas práticas:
AAAAAAAAACNAME: faz um alias de um nome para outro (comum em www).MX: para onde o email do domínio deve ser entregue.TXT: verificação e autenticação de email (SPF, DKIM, DMARC).NS: quais servidores são autoritativos para o domínio.Uma regra prática: não coloque CNAME e A no mesmo hostname.