DNS é o sistema que permite usar nomes como codigoemsala.com.br no lugar de decorar endereços IP. Quando você digita um domínio no navegador, uma das primeiras tarefas da rede é descobrir qual endereço está associado àquele nome. Essa resolução acontece por meio de uma estrutura distribuída de servidores, registros e caches.
O DNS não “transporta o site” e não substitui HTTP ou HTTPS. Ele responde a uma pergunta anterior: para qual endereço devo enviar a comunicação? Depois dessa descoberta, outros protocolos entram em ação. Por isso, compreender DNS ajuda a entender a Web, diagnosticar falhas de rede e administrar domínios com muito mais segurança.
Por que o DNS existe?
Computadores encaminham tráfego usando endereços de rede, mas pessoas trabalham melhor com nomes. Seria pouco prático memorizar um endereço numérico para cada site, serviço de e-mail ou servidor. O Domain Name System surgiu para organizar essa associação de forma distribuída.
Essa ideia é importante: não existe um único computador central contendo todos os nomes da Internet. O espaço de nomes é hierárquico e diferentes servidores são responsáveis por diferentes partes dessa árvore. A RFC 1034 descreve justamente o DNS como um sistema formado pelo espaço de nomes e registros, pelos servidores de nomes e pelos resolvedores que fazem consultas.
Como uma consulta DNS acontece, passo a passo
Imagine que você abra www.exemplo.com. O processo real pode variar por causa de caches, configurações do sistema e infraestrutura do provedor, mas o fluxo conceitual é este:
- o navegador ou o sistema verifica se já conhece a resposta em cache;
- se necessário, a consulta vai para um resolvedor recursivo, normalmente configurado pela rede, pelo provedor ou por um serviço de DNS;
- se o resolvedor ainda não tiver a resposta em cache, ele procura a informação na hierarquia DNS;
- servidores da raiz indicam onde encontrar informações sobre o domínio de nível superior, como
.com; - servidores do TLD indicam quais servidores são autoritativos para o domínio desejado;
- o servidor autoritativo fornece o registro solicitado;
- o resolvedor devolve a resposta ao cliente e pode armazená-la temporariamente em cache.
Esse fluxo é frequentemente chamado de resolução de nomes. Em muitos acessos reais, alguns passos não precisam acontecer novamente porque respostas anteriores ainda estão válidas no cache.
Raiz, TLD e servidor autoritativo
O DNS organiza os nomes como uma árvore. No topo conceitual está a raiz. Abaixo dela aparecem domínios de nível superior, ou TLDs, como .com, .org e .br. Depois vêm domínios registrados e, abaixo deles, subdomínios.
| Parte | Exemplo | Função simplificada |
|---|---|---|
| Raiz |
.
|
Aponta para servidores responsáveis pelos TLDs |
| TLD |
.com ou .br
|
Ajuda a localizar os servidores autoritativos do domínio |
| Domínio |
exemplo.com
|
Zona administrada por uma organização ou responsável |
| Subdomínio |
blog.exemplo.com
|
Nome abaixo do domínio, com registros próprios ou herdados conforme a configuração |
Um servidor autoritativo é uma fonte oficial para os dados de uma zona que administra. Já um resolvedor recursivo trabalha em nome do cliente para obter a resposta. Confundir esses papéis é comum: ambos lidam com DNS, mas executam funções diferentes.
Principais registros DNS
DNS não guarda apenas “nome e IP”. Ele trabalha com resource records, ou registros de recursos. O tipo do registro informa que espécie de dado está sendo consultada.
| Registro | Uso comum | Exemplo conceitual |
|---|---|---|
| A | Associa um nome a um endereço IPv4 |
site.exemplo → 192.0.2.10
|
| AAAA | Associa um nome a um endereço IPv6 |
site.exemplo → 2001:db8::10
|
| CNAME | Define um nome como alias de outro nome |
www → site.exemplo
|
| MX | Indica servidores responsáveis por receber e-mail |
mail.exemplo
|
| NS | Indica servidores de nomes de uma zona |
ns1.exemplo
|
| TXT | Armazena texto associado ao domínio | Usado, entre outras finalidades, em políticas e verificações |
Os registros A, NS, CNAME, SOA, PTR e MX já aparecem nas especificações históricas fundamentais do DNS. Outros tipos foram adicionados ou refinados ao longo da evolução do sistema. Por isso, ao administrar um domínio, é importante seguir a documentação atual do serviço usado e não assumir que todo registro tem a mesma finalidade.
Cache e TTL: por que uma mudança pode demorar a aparecer?
O DNS foi projetado para permitir cache. Quando um resolvedor obtém uma resposta, pode guardá-la por um período. Isso reduz consultas repetidas e distribui melhor a carga do sistema.
O TTL — Time To Live informa por quanto tempo um registro pode permanecer em cache antes de precisar ser consultado novamente. Se você altera um registro DNS, usuários diferentes podem receber respostas diferentes por algum tempo porque alguns caches ainda contêm a informação anterior.
Também existem caches no sistema operacional, no navegador e em componentes intermediários. Portanto, limpar apenas um cache nem sempre altera imediatamente tudo o que você observa.
DNS usa UDP ou TCP?
A RFC 1035 definiu acesso a servidores DNS tanto por UDP quanto por TCP na porta 53. Consultas tradicionais frequentemente usam UDP por seu baixo overhead, enquanto TCP é utilizado em situações que exigem transporte confiável ou quando o protocolo e o tamanho da resposta tornam isso necessário. O DNS moderno recebeu várias extensões ao longo do tempo, então a regra simplista “DNS é sempre UDP” está errada.
Para iniciantes, a ideia importante é: DNS é um protocolo de aplicação e pode usar diferentes mecanismos de transporte conforme a operação e as especificações aplicáveis.
Quando o DNS falha?
Um sintoma clássico é conseguir alcançar um endereço IP, mas não conseguir acessar um serviço pelo nome. Isso não prova sozinho que “o DNS caiu”, mas torna a resolução de nomes uma hipótese forte.
No Windows, o comando nslookup permite consultar o DNS diretamente. Por exemplo:
nslookup codigoemsala.com.br
nslookup -type=mx example.com
Se você quer um roteiro de investigação completo, use o guia Diagnóstico de rede no Windows. Ele mostra como combinar ipconfig, ping, tracert e nslookup sem tirar conclusões precipitadas.
Erros que não são necessariamente DNS
- o servidor web pode estar indisponível mesmo que o nome resolva corretamente;
- um firewall pode bloquear a conexão depois da resolução;
- HTTPS pode falhar por problema de certificado mesmo com DNS funcionando;
- um registro pode estar correto, mas apontar para um serviço configurado incorretamente;
- a rede local pode não ter conectividade externa.
DNS é uma etapa do caminho, não o caminho inteiro. O artigo HTTP e HTTPS ajuda a separar a resolução do nome da comunicação Web que acontece depois.
DNS e segurança
O DNS clássico foi criado em uma época em que a Internet era menor e o modelo de ameaça era diferente do atual. A infraestrutura evoluiu com extensões e práticas de segurança. Uma delas é o DNSSEC, que adiciona mecanismos de autenticação de dados DNS por meio de assinaturas digitais em zonas configuradas para isso.
DNSSEC não criptografa a consulta nem “protege o site inteiro”. Seu objetivo é permitir validação da autenticidade e integridade de dados DNS assinados. Já mecanismos como DNS over HTTPS (DoH) e DNS over TLS (DoT) tratam da proteção do transporte das consultas entre determinados participantes. São problemas diferentes.
Para quem está começando, o ponto principal é não tratar DNS como apenas uma tabela de nomes. Ele faz parte da infraestrutura crítica da Internet e sua configuração errada pode afetar acesso a sites, e-mail e outros serviços.
Exemplo completo: o que acontece antes de abrir uma página
Ao digitar https://codigoemsala.com.br, o navegador precisa, em termos simplificados:
- identificar o nome de host na URL;
- obter um endereço associado ao nome por DNS, caso não esteja em cache;
- estabelecer comunicação com o servidor apropriado;
- negociar a proteção TLS usada pelo HTTPS;
- enviar uma requisição HTTP;
- receber a resposta e processar o conteúdo.
Isso conecta três conteúdos do Código em Sala: como a Internet funciona, este artigo sobre DNS e o guia de HTTP e HTTPS. Separar essas etapas ajuda a entender onde cada tecnologia atua.
Atividade de fixação
Escolha três domínios conhecidos e use nslookup para observar as respostas. Depois consulte um deles com nslookup -type=mx dominio. Registre quais tipos de informação apareceram e explique por que um registro MX não tem a mesma função de um registro A.
Caso completo: publicar site e e-mail no mesmo domínio
Uma organização quer usar www.exemplo.com para o site e endereços @exemplo.com para e-mail. Esses serviços exigem registros diferentes. Alterar o site não deveria apagar a configuração de correio.
exemplo.com. 3600 IN A 203.0.113.10
www.exemplo.com. 3600 IN CNAME exemplo.com.
exemplo.com. 3600 IN MX 10 mail.exemplo.net.
exemplo.com. 3600 IN TXT "verificacao-do-servico"
Os endereços usam faixas reservadas para documentação e não devem ser copiados para produção. O exemplo mostra papéis: A aponta nome para IPv4, CNAME cria um alias, MX indica servidor de e-mail e TXT transporta informações textuais usadas por diversos serviços.
Plano de mudança sem improviso
- Registre a zona atual e o objetivo da alteração.
- Confirme o valor exigido na documentação do serviço.
- Verifique conflitos, especialmente CNAME no mesmo nome de outros registros.
- Defina TTL coerente antes da janela de mudança.
- Salve, consulte em resolvedores diferentes e registre horário.
- Mantenha um plano de retorno e não remova registros sem entender a função.
Diagnóstico de propagação
Crie uma tabela com nome consultado, tipo, resolvedor, resposta e horário. Compare a resposta autoritativa com dois resolvedores recursivos. Explique se a diferença pode ser cache, erro de configuração ou consulta ao nome errado.
Perguntas frequentes
DNS é a mesma coisa que domínio?
Não. O domínio é um nome dentro do espaço de nomes. DNS é o sistema distribuído usado para armazenar e consultar informações associadas a esses nomes.
Trocar o DNS deixa a internet mais rápida?
Pode alterar o tempo de resolução de nomes e a disponibilidade das consultas, mas não aumenta automaticamente a velocidade física da conexão nem a capacidade do servidor acessado.
Um domínio sempre aponta para um único IP?
Não. Um nome pode ter mais de um endereço, pode usar aliases e pode retornar respostas diferentes conforme a arquitetura do serviço.
Por que uma alteração de DNS não aparece imediatamente?
Porque respostas anteriores podem permanecer em cache até o TTL expirar, além de existirem caches em diferentes pontos do caminho.
Conclusão
DNS é uma peça fundamental da Internet porque transforma nomes utilizáveis por pessoas em informações que permitem localizar serviços. O processo envolve resolvedores, uma hierarquia de servidores, registros de diferentes tipos e caches controlados por TTL.
Entender essa estrutura muda a forma de diagnosticar problemas: quando um IP funciona e um nome não, você sabe onde investigar; quando uma alteração demora a aparecer, sabe por que o cache importa; e quando configura um domínio, entende que registros A, AAAA, CNAME, MX, NS e TXT têm papéis diferentes.
Referências bibliográficas
Livros reconhecidos utilizados como base para os conceitos deste artigo.
- KUROSE, James F.; ROSS, Keith W. Computer Networking: A Top-Down Approach . 9. ed. Pearson, 2025.
- TANENBAUM, Andrew S.; FEAMSTER, Nick; WETHERALL, David J. Computer Networks . 6. ed. Pearson, 2021.
Documentação técnica
- MOCKAPETRIS, Paul. RFC 1034 — Domain Names: Concepts and Facilities. IETF, 1987.
- MOCKAPETRIS, Paul. RFC 1035 — Domain Names: Implementation and Specification. IETF, 1987.