monero.press

Sistema DNS

Para se conectar a um site, o seu computador precisa do endereço IP dele, um número como 200.144.235.134. Mas ninguém digita números: digitamos nomes, como pt.wikipedia.org ou www.usp.br. Quem faz a ponte entre os dois é o DNS, o sistema de nomes de domínio da internet. Cada vez que você abre um site, manda um e-mail ou um aplicativo se conecta a um servidor, o DNS é consultado antes, em geral em poucos milésimos de segundo. Digite um nome no campo abaixo e acompanhe o caminho da pergunta:

O seu computador não sai perguntando por aí: ele faz uma única pergunta a um resolvedor, que faz o trabalho pesado. O resolvedor começa pelo topo, num servidor raiz, que o manda procurar os servidores responsáveis pela terminação do nome, como .org, que por sua vez o mandam procurar os servidores da organização dona do nome. Só esses últimos sabem a resposta. Na figura, as perguntas estão em laranja, as indicações de a quem perguntar em azul e as respostas em verde-azulado. No caminho, o resolvedor guarda tudo o que aprende, e por isso a mesma pergunta, repetida, é respondida na hora: escolha “Consulta repetida” para ver a diferença.

O endereço que aparece no fim é fictício, de uma faixa reservada para exemplos. Mais adiante, vamos acompanhar uma consulta de verdade, com as mensagens que foram de fato trocadas pela rede.

Essa conversa acontece trilhões de vezes por dia, e o sistema que a sustenta é um dos mais bem-sucedidos da internet: uma base de dados com mais de 400 milhões de domínios registrados, mantida por milhares de organizações independentes, sem que nenhuma delas precise conhecer o todo. Neste guia, vamos ver de onde veio a ideia, como os nomes se organizam numa árvore dividida em zonas, como um resolvedor encontra uma resposta e por que ele guarda o que aprende. Depois, vamos abrir uma mensagem byte a byte, ver como um atacante pode envenenar um cache e como as assinaturas e a criptografia protegem as respostas e a privacidade de quem pergunta.

Uma lista num arquivo

No começo, não havia DNS. Na ARPANET, a rede que deu origem à internet, cada computador tinha um nome curto, como SRI-NIC, e a tabela que ligava cada nome ao seu endereço ficava num único arquivo de texto, o HOSTS.TXT. Quem cuidava dele era o Centro de Informação da Rede, o NIC, no SRI, um instituto de pesquisa na Califórnia. Para registrar um computador novo ou mudar um endereço, o administrador mandava um pedido ao NIC, que atualizava o arquivo; de tempos em tempos, cada computador da rede baixava a versão nova inteira.

Com algumas dezenas de computadores, isso funcionava bem. Mas a rede crescia depressa: eram 213 computadores em agosto de 1981, 562 dois anos depois e mais de mil em 1984. Arraste o controle e veja o que acontece quando todos baixam o arquivo:

O problema é que duas coisas crescem juntas: o arquivo ganha uma linha a cada computador novo, e cada computador novo é mais alguém baixando o arquivo. O tráfego de cada atualização cresce com o quadrado do tamanho da rede: com dez vezes mais computadores, circulam cem vezes mais linhas. E não era só o tráfego. Uma mudança podia levar dias para chegar a todos, e quem tivesse baixado a versão anterior continuava com dados velhos. Os nomes eram todos do mesmo nível, e duas instituições não podiam dar o mesmo nome aos seus computadores. E tudo dependia de uma única equipe, na Califórnia.

Em 1983, Paul Mockapetris, do Instituto de Ciências da Informação da Universidade do Sul da Califórnia, propôs uma alternativa, nos documentos RFC 882 e RFC 883: um sistema distribuído, em que cada organização cuida dos próprios nomes, e uma estrutura hierárquica para ligar todos eles. É o Domain Name System, ou sistema de nomes de domínio. A especificação foi revista em 1987, nos RFC 1034 e RFC 1035, que continuam sendo a base do DNS, com dezenas de extensões acrescentadas desde então. O primeiro nome registrado sob .com, symbolics.com, é de 15 de março de 1985. No fim de 1987, a internet já tinha mais de 28 mil computadores.

O velho arquivo, aliás, não desapareceu por completo. Todo computador ainda tem uma pequena lista local de nomes, o arquivo hosts, que fica em /etc/hosts no Linux e no macOS e em C:\Windows\System32\drivers\etc\hosts no Windows. Ele é consultado antes do DNS, e, no Linux e no macOS, é ele que faz o nome localhost funcionar mesmo sem rede.

Uma árvore de nomes

A primeira ideia do DNS é dar uma estrutura aos nomes. Um nome como pt.wikipedia.org se lê da direita para a esquerda, do mais geral para o mais específico: org é um dos domínios de topo, wikipedia é um nome dentro de org, e pt é um nome dentro de wikipedia.org. Cada parte entre os pontos é um rótulo, e os rótulos formam uma árvore, com a raiz no topo:

Digite outros nomes e veja o caminho que eles fazem na árvore; os rótulos que ainda não existem nela são acrescentados. Você também pode tocar num rótulo para escolhê-lo. O nome completo de um rótulo é o caminho dele até a raiz, e por isso o mesmo rótulo pode aparecer em vários lugares: www.usp.br e www.uol.com.br não se confundem, porque os dois www estão em ramos diferentes. Cada dono de um ramo escolhe livremente os nomes abaixo dele, sem precisar consultar ninguém.

A raiz também tem um rótulo, que é vazio. Por isso, a forma completa de um nome, como pt.wikipedia.org., termina com um ponto, depois do qual vem o rótulo vazio da raiz. No navegador, o ponto final quase sempre fica subentendido, mas ele aparece nos arquivos de configuração e nas ferramentas de diagnóstico.

Há algumas regras. Cada rótulo tem no máximo 63 caracteres, e o nome inteiro, no máximo 253. Tradicionalmente, só se usam letras sem acento, algarismos e o hífen, e maiúsculas e minúsculas são equivalentes: WWW.USP.BR é o mesmo nome que www.usp.br. Nomes com acentos ou em outras escritas, como açaí.com.br, são convertidos numa forma que usa só esses caracteres e começa com xn--: xn--aa-4iaz.com.br. Experimente digitá-lo na figura. Essa conversão, chamada Punycode, aparece no guia sobre o Unicode.

Os rótulos logo abaixo da raiz são os domínios de topo. Alguns são genéricos, como com, org e net; outros, de duas letras, são de países e territórios, como br, pt e jp; e há centenas de genéricos mais novos, como app e rio. Ao todo, são mais de 1 400. O .br foi delegado em 18 de abril de 1989 ao grupo que operava a rede da Fapesp, em São Paulo, e hoje é administrado pelo NIC.br, com quase 6 milhões de nomes registrados, a maior parte sob com.br.

Zonas e delegação

A árvore é enorme, e ninguém a guarda inteira. Ela é dividida em zonas, pedaços administrados de forma independente, cada um pelos seus próprios servidores de nomes. A zona raiz sabe quais são os domínios de topo, mas nada sobre o que existe dentro deles; a zona br sabe quais nomes foram registrados sob .br, mas não quais computadores existem dentro de usp.br. Toque nos rótulos para ver a zona de cada um, com os seus servidores:

A passagem de um pedaço da árvore para outra zona se chama delegação, e está marcada em laranja. Para delegar usp.br, a zona br publica os nomes dos servidores responsáveis por ele, em registros do tipo NS, de name server. Quem perguntar ao .br qualquer coisa sobre usp.br recebe essa indicação: “não sei, pergunte a a.dns.usp.br, b.dns.usp.br, c.dns.usp.br ou ns1.ansp.br”. Os nomes e as listas de servidores da figura são reais.

Repare num detalhe: três dos servidores de usp.br têm nomes dentro do próprio usp.br. Para descobrir o endereço de a.dns.usp.br, seria preciso perguntar aos servidores de usp.br, mas, para perguntar a eles, é preciso saber o seu endereço. Para quebrar esse círculo, a zona de cima guarda também os endereços desses servidores, numa informação extra chamada cola (glue, em inglês), que acompanha a indicação.

Nem todo ponto de um nome é uma delegação, e nem toda delegação muda de mãos. com.br e gov.br são zonas à parte, mas ficam nos mesmos servidores do .br. Já www.gov.br, o portal do governo federal, é delegado aos servidores do Serpro. E pt.wikipedia.org fica na mesma zona que wikipedia.org: a Wikimedia não precisa delegar nada para criar um nome novo, basta acrescentá-lo à sua zona. É isso que permite ao DNS crescer sem um centro: cada zona só precisa conhecer as suas delegações.

Quem pergunta e quem responde

Há dois tipos bem diferentes de servidor no DNS. Os servidores autoritativos guardam as zonas e só respondem sobre elas: os servidores raiz pela zona raiz, os do .br pela zona br, os da USP pela zona usp.br. Eles não perguntam nada a ninguém. Ou sabem a resposta, porque ela está na sua zona, ou indicam quem sabe.

Os resolvedores são o contrário: não guardam zona nenhuma, mas sabem percorrer a árvore, perguntando de servidor em servidor até chegar à resposta, e guardam no cache tudo o que aprendem. Em geral, o resolvedor que o seu computador usa é o do seu provedor de internet, informado automaticamente quando você se conecta à rede. Mas também existem resolvedores públicos, abertos a qualquer um, como o do Google, no endereço 8.8.8.8, lançado em 2009, o Quad9, em 9.9.9.9, de 2017, e o da Cloudflare, em 1.1.1.1, de 2018.

No seu computador há ainda um terceiro participante, bem mais simples: o resolvedor local, a parte do sistema operacional que os programas chamam quando precisam de um endereço. Ele não percorre a árvore; só repassa a pergunta ao resolvedor de verdade, com um pedido de recursão, que quer dizer “vá até o fim e me traga a resposta pronta”.

Uma consulta, passo a passo

Vamos acompanhar uma consulta real: as mensagens trocadas para descobrir o endereço de www.usp.br, em setembro de 2026, com o cache do resolvedor vazio. Arraste o controle, ou toque nas setas, para ver o conteúdo de cada mensagem:

A mesma pergunta, “qual é o endereço de www.usp.br?”, é feita três vezes, a três servidores diferentes. A raiz não sabe a resposta, mas sabe quem cuida do .br, e devolve uma indicação: a lista dos servidores do .br, na seção de autoridade da mensagem, e os endereços deles, a cola, na seção adicional. O servidor do .br faz o mesmo, um nível abaixo. Só o servidor da USP tem a resposta, e a marca como autoritativa.

E a resposta traz uma surpresa: www.usp.br não tem endereço próprio. Ele é um apelido, um registro do tipo CNAME, de usp.br, e o servidor da USP aproveita a mensagem para mandar também o endereço do nome verdadeiro. Os números que aparecem antes dos tipos, 1800 e 300, são a validade de cada registro, em segundos; já vamos chegar a eles.

Os tempos da figura são aproximados, para um resolvedor em São Paulo. Cada ida e volta a um servidor custa de alguns a dezenas de milissegundos, conforme a distância, e é por isso que o resolvedor faz de tudo para não repeti-las. Da próxima vez que alguém perguntar por www.usp.br, ou por qualquer outro nome terminado em .br, ele já saberá a quem se dirigir.

Os servidores raiz

Toda busca começa pelo mesmo lugar, e por isso os resolvedores já vêm com uma lista de endereços de servidores raiz. São 13 nomes, de a.root-servers.net a m.root-servers.net, operados por 12 organizações diferentes: a Verisign cuida de dois, o A e o J, e os outros ficam com universidades, agências do governo americano, empresas e organizações sem fins lucrativos, como o RIPE NCC, na Holanda, a Netnod, na Suécia, e o projeto WIDE, no Japão.

Por que 13? Por causa de um limite do projeto original: uma resposta do DNS podia ter no máximo 512 bytes, e 13 é o número de servidores cujos nomes e endereços cabem numa resposta desse tamanho. Mas 13 é só o número de nomes. Cada servidor raiz é, na verdade, um grupo de cópias idênticas espalhadas pelo mundo, todas com o mesmo endereço IP: em 28 de setembro de 2026, eram 2 045 cópias. O truque se chama anycast. Cada cópia anuncia o mesmo endereço às redes vizinhas, e o roteamento da internet, que vimos no guia sobre o IP, leva cada pacote à cópia mais próxima, em termos de rede. Compare um servidor só com as cópias espalhadas, e mude de lugar:

As linhas no globo separam as regiões atendidas por cada cópia. As 43 cidades da figura são uma simplificação, e na internet de verdade a cópia que responde nem sempre é a mais próxima em quilômetros, porque os caminhos dependem de acordos entre as redes. Mas o efeito é real. Com um servidor só, quem está do outro lado do mundo espera centenas de milissegundos a cada pergunta; com as cópias, quase todo mundo tem uma raiz a poucos milissegundos. O tempo da figura é uma estimativa: a luz percorre a fibra óptica a uns 200 mil quilômetros por segundo, e os cabos raramente seguem a linha mais curta. O anycast também protege contra ataques: uma enxurrada de pacotes vinda de uma região atinge só as cópias daquela região.

Mesmo com tantas cópias, os servidores raiz não são consultados a toda hora. As indicações que eles dão valem por dois dias, e um resolvedor movimentado quase nunca precisa perguntar à raiz onde fica o .com ou o .br. Muitas das perguntas que chegam à raiz são, na verdade, sobre domínios de topo que não existem, fruto de configurações erradas.

Cache e validade

Se todo resolvedor fizesse o caminho completo a cada consulta, a raiz e os domínios de topo receberiam uma avalanche de perguntas, e cada acesso a um site levaria bem mais tempo. O que salva o sistema é o cache: o resolvedor guarda cada registro que recebe e responde às perguntas seguintes sem sair de casa. Mas por quanto tempo? Quem decide é o dono do nome. Cada registro traz a sua validade, o TTL (de time to live, “tempo de vida”), em segundos. Na consulta de www.usp.br, o apelido vale 1 800 segundos, meia hora, e o endereço, 300, cinco minutos.

A figura abaixo simula duas horas de consultas a um nome cujo endereço muda aos 75 minutos. Cada ponto da linha de cima é a pergunta de um usuário ao resolvedor; a linha do meio mostra o que o resolvedor guarda, e a de baixo, o endereço que o servidor autoritativo informa. Mude a validade e o movimento do site:

A escolha da validade é um compromisso. Com validades curtas, quase toda consulta vai até o servidor autoritativo, o que deixa as respostas mais lentas e os servidores mais carregados, mas uma mudança chega logo a todos. Com validades longas, quase tudo sai do cache, mas uma mudança pode levar horas para chegar a todo mundo: enquanto a cópia antiga não vence, o resolvedor continua entregando o endereço antigo, com toda a confiança. Repare também que, num site muito acessado, mesmo uma validade curta já poupa a maioria das idas ao servidor.

Isso explica a famosa “propagação do DNS”, as horas de espera depois de trocar o servidor de um site. Na verdade, nada se propaga: os resolvedores do mundo inteiro só vão, cada um no seu tempo, deixando vencer as cópias que guardaram. Quem planeja uma mudança pode reduzir a validade dos registros alguns dias antes, e aumentá-la de novo depois. E há caches por toda parte, não só no resolvedor: o sistema operacional e o navegador também guardam as respostas por algum tempo.

Até a falta de resposta vai para o cache. Quando um nome não existe, o servidor autoritativo responde com um código de erro, NXDOMAIN, e o resolvedor guarda também essa resposta negativa, pelo tempo indicado no registro SOA da zona.

Os tipos de registro

Até aqui só falamos de endereços, mas o DNS guarda muitos tipos de informação sobre um nome, cada um num tipo de registro. Os registros de uma zona costumam ser escritos num arquivo de texto, num formato definido em 1987 e usado até hoje. Este é o de uma padaria fictícia (o domínio example é reservado para exemplos). Toque numa linha para ver o que ela diz:

Cada linha traz o nome, a classe (quase sempre IN, de internet), o tipo e os dados. Os tipos mais comuns são A e AAAA, para endereços IPv4 e IPv6; CNAME, para apelidos; MX, para e-mail; NS e SOA, que descrevem a própria zona; e TXT, para texto livre. Um nome pode ter vários registros do mesmo tipo, e toda pergunta ao DNS diz qual tipo quer: um servidor que vai entregar um e-mail pergunta pelo MX, e o navegador pede o A e o AAAA.

O último registro, PTR, mora numa árvore especial e faz o caminho inverso, do endereço para o nome. Ele é usado, por exemplo, por servidores de e-mail que querem saber quem os está contatando, e por ferramentas de diagnóstico que mostram nomes em vez de números. Os endereços IPv6 têm uma árvore equivalente, sob ip6.arpa.

Uma mensagem por dentro

Como é, afinal, uma pergunta ao DNS? É uma mensagem curta, quase sempre enviada num único datagrama UDP para a porta 53 do servidor. Escolha um tipo de registro e alterne entre a pergunta e a resposta; toque nos bytes para ver o que cada um significa:

Toda mensagem começa com um cabeçalho de 12 bytes: um número de identificação, os bits de controle e quatro contadores, que dizem quantos registros há em cada uma das seções seguintes, a da pergunta, a da resposta, a de autoridade e a adicional. A mesma estrutura serve para perguntas e respostas: a resposta repete a pergunta e acrescenta os registros.

Os nomes não aparecem com pontos. Cada rótulo vem precedido de um byte com o seu tamanho, e o nome termina com um byte zero, o rótulo vazio da raiz. É daí que vem o limite de 63 caracteres por rótulo: dos oito bits do byte de tamanho, os dois primeiros têm outro uso. Quando os dois são 1, o byte não é um tamanho, mas o começo de um ponteiro para um nome que já apareceu antes na mensagem. Mude para a resposta e repare que o nome não se repete: em seu lugar aparecem os dois bytes C0 0C, um ponteiro para o byte 12, onde começa a pergunta.

Mensagens pequenas eram uma exigência do projeto original: pelo UDP, uma resposta podia ter no máximo 512 bytes. Quando a resposta não cabe, o servidor manda o que cabe e liga um bit que avisa que ela foi truncada, e o resolvedor repete a pergunta por TCP. Em 1999, uma extensão chamada EDNS permitiu que quem pergunta anuncie que aceita respostas maiores. Desde 2020, o limite mais usado é de 1 232 bytes, para que a resposta caiba num único pacote, sem ser fragmentada pelo caminho; o que passar disso vai por TCP.

Envenenamento de cache

A confiança do resolvedor nas respostas que recebe é, ao mesmo tempo, a força e a fraqueza do DNS. No projeto original, nada garante que uma resposta veio mesmo do servidor a quem se perguntou. O UDP não tem conexão: o resolvedor aceita a primeira resposta que chegar ao endereço e à porta de onde partiu a pergunta, desde que ela traga o mesmo número de identificação e a mesma pergunta. Um atacante que adivinhe esse número pode mandar uma resposta falsa, com o endereço do servidor verdadeiro forjado como remetente. Se ela chegar antes da verdadeira, vai para o cache, e todos os usuários daquele resolvedor passam a receber o endereço que o atacante escolheu. É o envenenamento de cache.

O número de identificação tem 16 bits, ou seja, 65 536 valores possíveis. Não é muito, mas o atacante tem pouco tempo, só os milissegundos entre a pergunta e a chegada da resposta verdadeira. E, se perdesse a corrida, precisava esperar a validade da resposta verdadeira vencer para tentar de novo, horas ou dias depois. Em 2008, Dan Kaminsky mostrou como evitar a espera: em vez de perguntar sempre pelo mesmo nome, o atacante faz o resolvedor perguntar por nomes que não existem, como x1.banco.example, x2.banco.example e assim por diante. Cada nome novo é uma nova corrida, e a resposta falsa não traz só um endereço: traz também uma indicação falsa, dizendo que os servidores de banco.example são os do atacante. Basta acertar uma vez para tomar o domínio inteiro:

Com mil respostas falsas por tentativa, a chance de acerto é de 1,5%, e bastam, em média, umas 66 tentativas. Nos testes de Kaminsky, o envenenamento levava menos de dez segundos. A descoberta foi mantida em segredo enquanto os fabricantes de servidores de DNS preparavam, juntos, uma correção, lançada ao mesmo tempo por todos em 8 de julho de 2008. Os detalhes deveriam ser revelados só em agosto, numa conferência de segurança, mas vazaram duas semanas depois da correção, e logo apareceram programas prontos para o ataque.

A correção foi sortear também a porta de origem de cada pergunta. Agora a resposta falsa precisa acertar o número de identificação e a porta, e, com cerca de 64 mil portas possíveis, as combinações passam de 4 bilhões. Escolha “Número e porta” na figura: quase nenhuma resposta falsa acerta sequer a porta, e seriam necessárias milhões de tentativas. Mas isso é uma dificuldade, não uma garantia: poucas semanas depois da correção, um pesquisador envenenou um servidor já corrigido em menos de dez horas, numa rede local de um gigabit por segundo. A solução definitiva era outra: tornar as respostas verificáveis.

Assinaturas: o DNSSEC

As extensões de segurança do DNS, o DNSSEC, acrescentam assinaturas digitais às zonas. O dono de cada zona tem chaves criptográficas: a parte privada fica guardada com ele e serve para assinar os registros; a parte pública é publicada na própria zona, em registros do tipo DNSKEY. As assinaturas vão em registros RRSIG, que acompanham as respostas. Quem recebe uma resposta confere a assinatura com a chave pública, e qualquer alteração no caminho, um único bit que seja, faz a conferência falhar.

Mas como saber que a chave pública é mesmo do dono da zona, e não de um atacante que assinou os próprios registros falsos? A garantia vem da zona de cima. Ela publica um resumo criptográfico da chave da zona de baixo, num registro DS, e assina esse registro com a sua própria chave. A chave de usp.br é garantida pelo .br, a do .br é garantida pela raiz, e a da raiz é conhecida de antemão: ela vem instalada nos resolvedores, como uma âncora de confiança. Veja o resolvedor conferir a resposta de usp.br, com as chaves reais:

Os números nas caixas identificam as chaves. Cada zona costuma ter duas: uma que assina só o conjunto de chaves da zona, e é a que a zona de cima resume no seu registro DS, e outra que assina todo o resto, e pode ser trocada com frequência sem incomodar a zona de cima. Escolha “Endereço trocado” e a assinatura deixa de conferir. Escolha “Chaves trocadas”, em que o atacante assina tudo de novo com chaves que ele mesmo criou: a assinatura passa a conferir, mas a chave nova não bate com o resumo que o .br publicou. Para enganar a cadeia, o atacante precisaria roubar a chave privada da própria zona ou de alguma zona acima dela.

Quando a conferência falha, o resolvedor não entrega a resposta: devolve um erro, e o nome simplesmente não funciona. É uma escolha deliberada, porque, para o DNSSEC, é melhor não responder do que responder errado. Isso também significa que um erro de configuração, como uma assinatura vencida, derruba o domínio inteiro para quem usa um resolvedor que confere as assinaturas.

A raiz foi assinada em 15 de julho de 2010. A chave privada dela fica em equipamentos de segurança, em duas instalações nos Estados Unidos, e só é usada em cerimônias públicas, gravadas em vídeo, com a presença de representantes da comunidade da internet de vários países. E essa chave acaba de ser trocada. Em 11 de outubro de 2026, a raiz passou a assinar com uma chave nova, a KSK-2024, de número 38696, no lugar da KSK-2017, de número 20326, que aparece na figura como estava em setembro. A chave nova tinha sido publicada na zona raiz em janeiro de 2025, com tempo para que os resolvedores a aprendessem sozinhos.

O DNSSEC só protege quem participa nas duas pontas: a zona precisa ser assinada, e o resolvedor precisa conferir. O .br foi, ao lado do .se, da Suécia, um dos primeiros domínios de país a adotá-lo. E o DNSSEC garante a autenticidade das respostas, não o sigilo: as respostas assinadas continuam legíveis por quem estiver no caminho.

Quem vê as suas perguntas

O DNS foi projetado numa época em que não se pensava em privacidade, e as perguntas viajam em texto aberto. Quem estiver no caminho entre você e o resolvedor, como a rede Wi-Fi de um café ou o seu provedor, vê cada nome que você consulta. O resolvedor, por definição, vê todos eles, junto com o seu endereço IP. E os servidores autoritativos veem as perguntas que o resolvedor faz, em geral sem o seu endereço; alguns resolvedores repassam um pedaço dele, para que o servidor possa indicar uma cópia do site perto de você. Ligue as proteções abaixo para ver o que cada um passa a enxergar:

A primeira proteção é cifrar a conversa com o resolvedor, com as mesmas técnicas das conexões seguras da web. O DNS sobre TLS, de 2016, usa uma porta própria, a 853. O DNS sobre HTTPS, de 2018, manda as perguntas como se fossem pedidos a um site, pela porta 443, e fica difícil de distinguir do resto do tráfego da web. Os navegadores oferecem o DNS sobre HTTPS, e os sistemas operacionais mais recentes, um ou os dois. Mas essas proteções não escondem tudo: quem está no caminho continua vendo com que endereços IP você se conecta em seguida. E a criptografia não muda nada quanto ao próprio resolvedor, que continua vendo todas as suas perguntas. Escolher um resolvedor é escolher em quem confiar.

A segunda proteção é a minimização de nomes: em vez de perguntar o nome inteiro a cada servidor, o resolvedor pergunta a cada um só o necessário. À raiz, basta perguntar quem cuida do .br; ao .br, quem cuida de usp.br. Só o servidor da USP precisa saber que a pergunta é sobre www.usp.br. A técnica foi proposta em 2016, virou padrão em 2021 e já vem ligada em vários dos resolvedores mais usados.

O DNS na prática

Você pode fazer as suas próprias consultas. No Linux e no macOS, o comando dig mostra as respostas quase como elas vêm na mensagem; no Windows, o equivalente é o nslookup, que também existe nos outros sistemas:

$ dig www.usp.br

;; ANSWER SECTION:
www.usp.br.      1800   IN   CNAME   usp.br.
usp.br.          300    IN   A       200.144.235.134

$ dig +trace www.usp.br          # percorre a árvore a partir da raiz
$ dig usp.br MX                  # outro tipo de registro
$ dig -x 8.8.8.8                 # o caminho inverso, pelo PTR: dns.google
$ dig +dnssec usp.br             # mostra também as assinaturas

A opção +trace faz o que o resolvedor faz, a partir da raiz, e mostra cada indicação no caminho, como na figura da consulta passo a passo. Se você repetir a primeira consulta, verá a validade diminuindo: é o tempo que ainda falta para aquela cópia vencer no cache do resolvedor.

Quando um site não abre, o DNS é um dos primeiros suspeitos. Em 21 de outubro de 2016, um ataque de negação de serviço feito com câmeras e gravadores invadidos derrubou os servidores da Dyn, uma empresa que hospedava o DNS de muitos sites, e serviços como Twitter, Netflix e Spotify ficaram fora do ar para boa parte dos usuários, sobretudo nos Estados Unidos. Em 4 de outubro de 2021, um erro durante uma manutenção desligou a rede interna do Facebook, e os servidores de DNS da empresa, sem conseguir falar com o resto dela, retiraram da internet as rotas até eles. Por cerca de seis horas, facebook.com, instagram.com e o WhatsApp deixaram de existir para o mundo, mesmo com os servidores funcionando. Não é à toa que, entre administradores de rede, há um ditado: quando algo misterioso dá errado, “é sempre o DNS”.

Palavras finais

O DNS foi projetado em 1983, quando a rede tinha pouco mais de 500 computadores, e hoje responde por centenas de milhões de domínios, sem ter mudado de ideia central. A proposta de Mockapetris, de dividir a árvore em zonas e deixar cada dono cuidar da sua, permitiu que o sistema crescesse sem que ninguém precisasse conhecer o todo. E a parte que o torna rápido é a menos vistosa: o cache, que faz a maioria das perguntas ser respondida sem sair do resolvedor.

As fraquezas também vêm do projeto original, de uma rede em que todos se conheciam. Não havia como conferir as respostas, nem como esconder as perguntas, e as soluções vieram depois, em camadas: portas sorteadas, assinaturas, criptografia. Da próxima vez que você digitar um nome no navegador, lembre que, antes da primeira letra da página aparecer, uma pequena pergunta pode ter dado a volta ao mundo, ou, bem mais provavelmente, ter sido respondida por um resolvedor que já sabia a resposta.

Leituras adicionais

As mensagens da consulta a www.usp.br, os servidores de nomes da árvore e as chaves do DNSSEC foram consultados em setembro de 2026 e podem ter mudado desde então. Os endereços da primeira figura e os domínios da padaria e do banco são fictícios, de faixas e nomes reservados para exemplos, e os tempos das figuras são estimativas.