edubun
Português

DNS: transformando nomes em endereços

Os 13 servidores raiz de nomes são operados por 12 organizações a partir de 2047 máquinas pelo mundo (root-servers.org, 17 de outubro de 2026).

ContextoAntes do DNS, todo computador da ARPANET guardava uma cópia de um único arquivo de texto, o HOSTS.TXT, com todos os nomes e endereços de hosts. O Network Information Center do Stanford Research Institute o mantinha, e cada local baixava cópias novas. À medida que a rede crescia, o arquivo crescia, as mudanças demoravam mais para se espalhar e os nomes entravam em conflito. A RFC 1034 descreve esse problema e o projeto que o substituiu: uma árvore de nomes, cada parte cuidada pelos próprios servidores. O DNS foi publicado como RFC 1034 e RFC 1035 em 1987.

Hoje ninguém baixa esse arquivo. Você digita example.com em vez de 198.51.100.20, e o nome é consultado no momento em que você precisa dele. Os roteadores, porém, ainda só entendem números, então antes que o seu navegador possa enviar um único pacote a um site, o nome precisa virar um endereço. O Domain Name System (DNS, sistema de nomes de domínio) faz isso, e o guia da Cloudflare o chama de lista telefônica da internet.

Um nome é um caminho descendo uma árvore

Leia www.example.com da direita para a esquerda. No topo fica a raiz, escrita como um ponto invisível. Abaixo dela estão os domínios de primeiro nível (TLDs), como com, org e kr. Abaixo de com está example, e abaixo dele, www. Cada pedaço é um rótulo; a RFC 1035 permite até 63 bytes por rótulo e 255 bytes para um nome inteiro. Organizações diferentes cuidam de galhos diferentes da árvore, então nenhum computador sozinho precisa saber todos os nomes. Era justamente isso que dava errado com o HOSTS.TXT, em que um arquivo em cada máquina tentava guardar todos.

A árvore do DNS. www.example.com é o caminho www → example → com → raiz, lido da esquerda para a direita, mas consultado da raiz para baixo.

Quatro servidores, oito passos

A Cloudflare lista quatro tipos de servidor em uma consulta. O resolvedor recursivo, geralmente operado pelo seu provedor ou por um serviço público de DNS, faz o trabalho pesado por você. Um servidor raiz sabe onde estão os servidores TLD. Um servidor TLD, como o de com, sabe quais servidores guardam cada domínio abaixo dele. O servidor autoritativo de um domínio guarda os registros de verdade e dá a resposta final. Sem nada em cache, uma consulta leva oito passos. O seu computador pergunta ao resolvedor. O resolvedor pergunta à raiz, que o encaminha para com. Ele pergunta a com, que o encaminha para os servidores de nomes do domínio. Ele pergunta a esses servidores, eles respondem com o endereço, e o resolvedor devolve o endereço a você.

Carregando

Arraste para girar. Role ou faça pinça para dar zoom.

Aperte Próximo passo oito vezes, ou Reproduzir. Depois aperte Consultar de novo: o cache do navegador responde na hora e nenhuma mensagem sai do computador. Espere 1 minuto e consulte de novo: a cópia do navegador expirou, mas o cache do SO ainda a tem. Espere 1 hora: o TTL de 3600 segundos acabou em todo lugar e a consulta completa recomeça.

Por que a segunda consulta é instantânea

Se toda consulta levasse oito passos, o DNS seria lento e os servidores raiz se afogariam em perguntas. Por isso as respostas são guardadas. Elas ficam em cache no navegador, no sistema operacional e no resolvedor. Cada registro vem com um tempo de vida em segundos, definido pelo dono do domínio. Um TTL de 3600 quer dizer "você pode reutilizar esta resposta por uma hora". Um TTL curto permite que o dono mude um site de lugar depressa; um longo poupa consultas. Os servidores raiz também são espalhados: os 13 servidores raiz com nome, de a a m, funcionavam como 2047 instâncias separadas em 17 de outubro de 2026.

Dois tipos de pergunta, uma porta

Uma consulta mistura dois tipos de pergunta. O seu computador envia ao resolvedor uma consulta recursiva, que quer dizer "me dê a resposta final ou um erro". O resolvedor então envia consultas iterativas aos servidores raiz, TLD e autoritativo, e cada um responde com o melhor que tem, muitas vezes só uma indicação do próximo servidor. As mensagens DNS vão para a porta 53, normalmente por UDP, porque uma pergunta e uma resposta cabem cada uma em um pacote. Respostas grandes e transferências entre servidores usam TCP, que a RFC 7766 torna parte obrigatória de toda implementação completa de DNS. Você mesmo pode testar. Na maioria dos computadores, o comando nslookup example.com mostra o resolvedor usado e os endereços que ele recebeu.

Os registros guardam mais do que endereços

RegistroGuardaExemplo
AUm endereço IPv4www.example.com → 198.51.100.20
AAAAUm endereço IPv6 (RFC 3596)www.example.com → 2001:db8::20
CNAMEOutro nome para consultar no lugarshop.example.com → example.com
MXO servidor de e-mail do domínioexample.com → mail.example.com
NSOs servidores de nomes autoritativosexample.com → ns1.example.com
  1. Uma consulta sem cache de www.example.com: quais servidores o resolvedor consulta, em ordem?
  2. Qual servidor dá a resposta final para www.example.com?
    • O servidor autoritativo de example.com
    • O servidor raiz
    • O servidor TLD de com
    • O servidor web
  3. Quantos passos leva uma consulta sem cache na descrição da Cloudflare?
  4. Qual registro guarda um endereço IPv6?
    • AAAA
    • A
    • MX
    • CNAME
  5. Um registro tem TTL 3600. Por quantos minutos um cache pode reutilizá-lo?
  6. Qual é o maior tamanho que um único rótulo (como example) pode ter segundo a RFC 1035?
  7. Quantos servidores raiz com nome existem?
  8. Você consultou um nome há 10 segundos e o cache do navegador o guarda por 60 segundos. Quantas mensagens DNS saem do seu computador se você consultar de novo agora?
  9. Para que serve um registro MX?
    • Indicar o servidor de e-mail de um domínio
    • Guardar uma página da web
    • Guardar um endereço IPv6
    • Definir o TTL de outros registros
  10. O que o DNS substituiu?
    • Um único arquivo HOSTS.TXT copiado para todos os computadores
    • A rede telefônica
    • Endereços IP
    • Os roteadores
Erros comuns
  • "O DNS guarda as páginas da web." O DNS só responde com registros, como endereços, servidores de e-mail e outros nomes. A página em si vem do servidor web no endereço que o DNS devolveu.
  • "Quando um site muda de endereço, todo mundo vê o novo na mesma hora." Navegadores, sistemas operacionais e resolvedores guardam a resposta antiga até o TTL dela acabar. Com um TTL de 3600, alguns visitantes ainda podem ser mandados ao endereço antigo por até uma hora.
  • "Existem exatamente 13 computadores servidores raiz." Existem 13 nomes, de a a m, operados por 12 organizações. Em 17 de outubro de 2026 eles respondiam a partir de 2047 instâncias pelo mundo.
  • "O meu computador pergunta ao servidor raiz ele mesmo." O seu computador pergunta uma vez ao resolvedor recursivo. O resolvedor vai da raiz ao servidor TLD e ao servidor autoritativo e devolve só o resultado.
Nota do professorLeiam juntos alguns nomes da direita para a esquerda antes de desenhar qualquer coisa; esse hábito de leitura é o primeiro a construir. O resolvedor é a caixa que some dos desenhos dos alunos, então desenhe-o separado do computador e faça toda seta que sai do computador parar nele. Rode os oito passos do simulador uma vez e logo depois aperte Consultar de novo. Uma segunda consulta que não envia nada explica o cache melhor do que uma definição. Se houver um terminal disponível, o nslookup de um site que a turma já conhece transforma o diagrama em algo real.
Pontos-chave
  • O DNS transforma nomes em endereços; os nomes são lidos da direita para a esquerda descendo uma árvore.
  • Resolvedor recursivo → raiz → TLD → autoritativo: oito passos sem nada em cache.
  • As respostas ficam em cache no navegador, no SO e no resolvedor pelo TTL do registro (em segundos).
  • A = IPv4, AAAA = IPv6, CNAME = apelido, MX = e-mail, NS = servidores de nomes.
Fontes deste curso (28)
  • (checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
  • IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
  • RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
  • RFC 792 ICMP (Time Exceeded)
  • RFC 801 NCP/TCP transition plan (1 January 1983)
  • RFC 894 Ethernet (1500-byte payload)
  • RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
  • RFC 1122 (127.0.0.0/8 loopback)
  • RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
  • RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
  • RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
  • RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
  • RFC 8446 TLS 1.3 (one round-trip handshake)
  • RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
  • RFC 9293 TCP (three-way handshake, sequence numbers)
  • IANA: ip-parameters registry (recommended default TTL 64)
  • IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
  • Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
  • "What is a URL?", "HTTP response status codes" (developer.mozilla.org)
  • Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
  • "What is HTTP/3?" (cloudflare.com/learning)
  • Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
  • Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
  • Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
  • History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
  • historyofinformation.com and Wikipedia ARPANET (Kline)
  • Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
  • Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)

Data de verificação: 2026-10-17