Quando você digita um endereço como exemplo.com no navegador, é o DNS (Domain Name System) que torna possível encontrar o servidor correto na internet. Ele é o sistema que traduz nomes de domínio, como exemplo.com, em endereços IP que os dispositivos usam para se comunicar na internet. Sem ele, precisaríamos memorizar sequências numéricas para acessar qualquer serviço online.
Embora funcione de forma quase invisível para o usuário, o DNS é um dos pilares da infraestrutura da internet moderna. Ele é usado em redes domésticas, empresas e por provedores de serviços.
Neste artigo, vamos entender como esse sistema funciona na prática, sua estrutura hierárquica, os principais tipos de registros e os mecanismos de segurança envolvidos.
O que é o DNS?
O DNS é um sistema distribuído e hierárquico responsável pela resolução de nomes na internet. Ele permite que dispositivos convertam nomes de domínio em endereços IP por meio de consultas realizadas a servidores especializados, conhecidos como Name Servers.
Ele opera na camada de Aplicação do modelo TCP/IP. Usa principalmente a porta 53, tanto no protocolo UDP quanto no TCP porém, por questões de desempenho, o protocolo UDP é o principal a ser utilizado, enquanto o TCP é utilizado em situações específicas, como transferências de zona ou quando a resposta excede o tamanho suportado por uma consulta UDP.
Como o DNS funciona?
Quando um domínio é digitado na pesquisa do navegador, uma consulta é enviada para um servidor DNS configurado na rede. Esse servidor verifica se possui o endereço correspondente a esse domínio. Após encontrar o endereço, ele é enviado de volta ao navegador, que prossegue com a pesquisa.
Para que o processo de consulta no servidor não tenha que se repetir todas as vezes, esse endereço que está atrelado ao domínio é armazenado temporariamente em cache para consultas futuras.
Até aqui, vimos o funcionamento de forma simplificada. Na prática, o processo de resolução envolve múltiplos servidores organizados hierarquicamente.
Como funciona na prática
Diferente da explicação anterior, que foi mais simplificada, o processo real de resolução DNS envolve múltiplos servidores distribuídos em diferentes partes do mundo, organizados em uma hierarquia bem definida.
A resolução DNS se inicia quando uma aplicação precisa converter um nome de domínio em um endereço IP. Esse processo envolve componentes chamados resolvedores, que atuam como intermediários entre os programas e os servidores DNS.
Existem dois tipos principais de resolvedores:
Stub Resolver: é o componente presente no sistema operacional do usuário. Ele recebe a requisição da aplicação e a encaminha para um servidor DNS configurado na rede.
Recursive Resolver: é o servidor DNS responsável por realizar a busca completa da informação. Ele consulta outros servidores da hierarquia DNS até obter a resposta final. Normalmente, esse servidor é fornecido pelo provedor de internet ou pode ser um serviço público, como o 8.8.8.8 ou o 1.1.1.1.
Na prática, o processo de resolução ocorre da seguinte forma:
A aplicação envia a requisição ao stub resolver, presente no sistema operacional.
O stub resolver encaminha a consulta ao resolvedor recursivo configurado na rede.
O resolvedor recursivo consulta a hierarquia do DNS, começando pelos servidores raiz, que indicam qual é o próximo nível responsável pelo domínio solicitado.
Em seguida, o resolvedor continua seguindo as delegações até alcançar o servidor autoritativo responsável pelo domínio específico.
Por fim, o resolvedor consulta o servidor autoritativo, que retorna o endereço IP correspondente.
A resposta volta ao resolvedor recursivo, que a encaminha ao stub resolver e, finalmente, à aplicação.
A consulta feita pelo stub resolver ao resolvedor recursivo é chamada de consulta recursiva, pois o cliente espera receber a resposta final.
Já as consultas realizadas pelo resolvedor recursivo aos demais servidores da hierarquia são consultas iterativas, nas quais cada servidor responde com a melhor informação que possui, podendo indicar o próximo servidor a ser consultado.
Para que possamos visualizar melhor todo esse processo, veremos mais sobre a estrutura do DNS.
Estrutura hierárquica do DNS
Namespace e estrutura em árvore
O DNS pode ser entendido como um sistema de banco de dados distribuído, organizado de forma hierárquica. Os nomes de domínio fazem parte dessa estrutura, parecida com uma árvore invertida. Cada nó dessa árvore possui um rótulo (label), e a junção desses rótulos forma um nome de domínio completo.
Essa árvore e todos os seus nós compõem o que chamamos de namespace do DNS.
A raiz (Root)
No topo dessa árvore temos a raiz (root). Ela não tem rótulo e é representada por um ponto final (“.”) em um nome de domínio totalmente qualificado (FQDN).
O ponto final indica explicitamente a raiz da hierarquia. A leitura estrutural do nome ocorre da direita para a esquerda: começamos pela raiz, depois o domínio de topo, em seguida o domínio específico e, por fim, o host.
A raiz é o topo da hierarquia, ela contém registros do tipo NS que delegam autoridade para os domínios de topo (TLDs). Ele não armazena todos os domínios da internet, ele apenas aponta para os servidores responsáveis por cada TLD.
TLDs e delegação
Logo abaixo da raiz estão os TLDs (Top-Level Domains), como .com, .net, .org e .br. É para eles que a raiz delega autoridade, e da mesma forma que a raiz, os TLDs também delegam autoridade para domínios registrados sob eles.
A delegação acontece quando a autoridade administrativa sobre um subdomínio é transferida para outro conjunto de servidores. Esse processo permite dividir o namespace e distribuir a responsabilidade entre diferentes organizações. A delegação é feita através de registros do tipo NS.
Domínio vs Zona
Dentro dessa estrutura surge a distinção entre domínio e zona, conceitos que frequentemente são confundidos. Um domínio corresponde a um nó específico da árvore e todos os nomes abaixo dele na hierarquia, por exemplo, ".com" é um domínio e "www.exemplo.com" também é um domínio. Já uma zona representa uma porção administrativa do namespace onde um servidor DNS é responsável. Uma zona pode ser um domínio ou apenas parte dele, caso existam delegações para subdomínios.
Servidores autoritativos
Um servidor é considerado autoritativo quando possui localmente a zona sob sua responsabilidade e responde com dados oficiais sobre ela sem depender de cache para aquela zona. Nessas respostas, o campo AA (Authoritative Answer) do cabeçalho DNS é ativado.
Os registros NS (Name Server) indicam quais servidores são responsáveis por determinada zona e são usados tanto para definir autoridade quanto para realizar delegações dentro da hierarquia do DNS.
Tipos de Registros DNS
O DNS é descrito como um banco de dados composto por Resource Records (RRs). Cada registro é formado pela seguinte estrutura:
- NAME: Nome de domínio ao qual o registro pertence.
- TTL: Tempo que fica em cache.
- CLASS: Classes do registro, normalmente IN (internet).
- TYPE: Tipo do registro (A, MX, etc.).
- DATA: Dados específicos do tipo.
Existem diferentes tipos de RRs e veremos uma breve explicação de cada um deles.
A (Address Record)
É o registro que mapeia um nome de domínio a um endereço IPv4, sendo que um nome de domínio pode ter vários registros A. Não deve coexistir com o CNAME tendo o mesmo nome.
| NAME | TTL | CLASS | TYPE | RDATA |
|---|---|---|---|---|
| exemplo.com | 3600 | IN | A | 192.168.10.4 |
AAAA (Quad-A)
Ele mapeia um nome de domínio para um endereço IPv6. É o equivalente ao Address Record, mas para o IPv6.
| NAME | TTL | CLASS | TYPE | RDATA |
|---|---|---|---|---|
| exemplo.com | 3600 | IN | AAAA | 2001:db8::1 |
CNAME (Canonical Name)
O registro CNAME permite que um domínio funcione como um apelido para outro domínio. Em vez de apontar diretamente para um endereço IP, ele direciona a consulta para outro nome, que então será resolvido normalmente até encontrar um registro A ou AAAA.
Um ponto importante é que um domínio que possui CNAME não pode ter nenhum outro tipo de registro associado a ele (como A, MX ou TXT), o que é uma regra do DNS e uma causa comum de erros de configuração.
| NAME | TTL | CLASS | TYPE | RDATA |
|---|---|---|---|---|
| blog.exemplo.com | 3600 | IN | CNAME | exemplo.com |
MX (Mail Exchange)
Define quais servidores vão ser responsáveis por receber e-mails para um domínio. É composto por dois campos, o de prioridade e o nome do servidor, sendo que quanto menor o número, maior a prioridade. O MX não aponta diretamente para um IP, ele vai apontar para um nome que tenha um A ou AAAA.
| NAME | TTL | CLASS | TYPE | RDATA |
|---|---|---|---|---|
| exemplo.com | 3600 | IN | MX | mail.exemplo.com |
TX
Permite armazenar texto arbitrário associado a um domínio. É usado para SPF, DKIM e verificações de domínio.
| NAME | TTL | CLASS | TYPE | RDATA |
|---|---|---|---|---|
| exemplo.com | 3600 | IN | TX | "v=spf1 include:_spf.google.com ~all" |
NS (Name Server)
Indica qual o servidor autoritativo para uma zona, definindo autoridade e permitindo delegações. É recomendado o uso de pelo menos dois para redundância. Esse registro pode aparecer tanto na zona pai (delegação) quanto na zona filha (autoridade).
| NAME | TTL | CLASS | TYPE | RDATA |
|---|---|---|---|---|
| exemplo.com | 3600 | IN | NS | ns1.exemplo.com |
PTR (Pointer)
Faz o mapeamento reverso, traduzindo um IP para um nome, sendo usado tanto para endereços IPv4 quanto para IPv6.
| NAME | TTL | CLASS | TYPE | RDATA |
|---|---|---|---|---|
| 4.10.168.192.in-addr.arpa | 3600 | IN | PTR | exemplo.com |
SOA (Start of Authority)
Define informações administrativas de uma zona, sendo o primeiro registro de qualquer zona. Ele define parâmetros que controlam a transferência de zona, atualizações e sincronização entre primário e secundário. Tem diversos campos importantes, como MNAME, RNAME, SERIAL, REFRESH E RETRY.
TTL e Cache no DNS
TTL
TTL (Time To Live) é um campo presente em cada Resource Record (RR) que define, em segundos, por quanto tempo aquela informação pode ser armazenada em cache antes que seja necessário realizar uma nova consulta ao servidor autoritativo. O TTL não define quanto tempo a informação é válida em um servidor autoritativo, o servidor autoritativo sempre tem a informação mais atualizada, ele define o tempo que terceiros poderão reutilizar essa informação.
Cache no DNS
O cache tem o objetivo de fazer com que, a cada nova consulta, não tenha que fazer todo o caminho até o servidor autoritativo novamente. Fazendo isso, a carga nesses servidores e o tempo de resposta diminuem.
Então, quando um resolvedor recebe a resposta de algum servidor, ele armazena a informação em cache, associa o tempo de expiração restante com o TTL e enquanto a informação não expira, ele a usa como resposta.
Cache Local
O cache local é mantido no sistema operacional do cliente e, em alguns casos, também pelo próprio navegador. Esse cache afeta apenas esse dispositivo em específico, podendo ser limpo manualmente pelo próprio usuário. Por exemplo, para limpar o cache DNS no Windows, se usa o comando ipconfig /flushdns no cmd.
Cache do Resolvedor Recursivo
É o cache mais importante na prática, quando o resolvedor consulta o root, TLD e depois o autoritativo, ele armazena todas as informações intermediárias, como a resposta final (A ou AAAA), NS Records, delegações e informações de TLD. Isso reduz drasticamente a quantidade de consultas a esses servidores mais importantes.
Propagação de DNS
A chamada “propagação de DNS” não é um processo ativo de atualização global, mas sim o tempo necessário para que os diferentes caches distribuídos expirem. Enquanto o TTL não termina, resolvedores continuam respondendo com dados armazenados. Após a expiração, uma nova consulta é feita ao servidor autoritativo, refletindo então a informação atualizada.
DNS em redes domésticas e corporativas
DNS no Roteador
Em uma rede doméstica, o roteador recebe suas configurações de DNS do provedor de internet (ISP) via DHCP, distribuindo esses servidores DNS para os dispositivos da rede interna. Geralmente, o roteador não é autoritativo para domínios da internet.
DNS Público
São resolvedores recursivos públicos, fazem a resolução completa das requisições mantendo também grandes caches. Em comparação com os servidores DNS de alguns ISPs, podem oferecer melhor latência. Além disso, certos provedores disponibilizam recursos adicionais, como filtragem de ameaças, políticas específicas de privacidade e validação de DNSSEC.
DNS Interno (Corporativo)
Em ambientes corporativos existem servidores de DNS internos, zonas internas, integração com diretórios (como o Windows). O DNS interno pode ser autoritativo internamente, pode ser recursivo externamente e usar forwarders para a internet.
O uso do DNS interno é muito útil para resolver domínios internos, separar infraestrutura interna da externa e para o controle de políticas de acesso.
Split DNS (Split-Horizon DNS)
O split DNS acontece quando um domínio dá respostas diferentes dependendo da origem da consulta. Por exemplo, uma consulta interna recebe o endereço 10.0.0.25 e uma consulta de origem externa recebe a resposta 203.0.113.10. Isso garante segurança e controle, separando a infraestrutura interna da externa.
Alta disponibilidade (HA) em DNS
O DNS é um componente crítico da infraestrutura de rede. Se um servidor DNS autoritativo ficar indisponível, usuários não conseguirão resolver o nome do domínio, mesmo que o servidor web esteja funcionando corretamente.
Para evitar esse tipo de falha, o DNS foi projetado para funcionar com múltiplos servidores autoritativos para a mesma zona. As RFCs recomendam que cada zona tenha pelo menos dois servidores autoritativos diferentes, garantindo redundância.
Normalmente, existe um servidor primário, onde a zona é administrada, e um ou mais servidores secundários que recebem cópias por meio de transferências de zona. Isso garante que, se um servidor falhar, o outro continue respondendo.
Em ambientes de grande escala, provedores utilizam técnicas como distribuição geográfica e Anycast para aumentar ainda mais a resiliência e diminuir a latência.
Segurança no DNS
O DNS original, conforme definido nas RFC 1034 e 1035, não inclui mecanismos de autenticação ou criptografia, o que abriu espaço para diversas vulnerabilidades ao longo do tempo.
DNS Spoofing
DNS spoofing é a falsificação de uma resposta DNS. O atacante envia uma resposta fraudulenta fingindo ser um servidor legítimo, explorando o fato de que o DNS tradicional não possui autenticação criptográfica embutida nas respostas. Se o resolvedor aceitar essa resposta falsa, o usuário pode ser redirecionado para um destino incorreto.
DNS Poisoning
O cache poisoning ocorre quando uma resposta DNS falsificada é aceita por um resolvedor recursivo e armazenada em cache. A partir desse momento, todos os clientes que utilizam esse resolvedor passam a receber a informação incorreta até que o TTL expire ou o cache seja limpo.
DNSSEC
O DNSSEC foi criado para mitigar ataques como spoofing e cache poisoning, adicionando validação criptográfica às respostas DNS. Ele não criptografa os dados, mas garante a autenticidade da origem e integridade dos dados. Isso acontece através de validações criptográficas realizadas pelo resolvedor recursivo, que descarta as respostas consideradas inválidas.
DNS over TLS (DoT)
O DNS over TLS (DoT) protege o transporte das consultas utilizando TLS na porta 853, criptografando a comunicação entre o cliente (ou stub resolver) e o resolvedor recursivo. Ele veio para proteger contra interceptação das consultas, mas não garante a autenticidade da zona, com esse sendo o papel do DNSSEC.
DNS over HTTPS (DoH)
O DNS over HTTPS (DoH) encapsula consultas DNS dentro de requisições HTTPS, utilizando a porta 443. A criptografia é fornecida pelo TLS, enquanto o transporte ocorre sobre a infraestrutura do protocolo HTTPS.
Por utilizar a mesma porta do tráfego web comum, o DoH pode dificultar a inspeção e filtragem das consultas DNS por dispositivos intermediários de rede, aumentando a privacidade do usuário.
DDoS contra DNS
Os ataques de negação de serviço contra o DNS exploram a dependência da infraestrutura pois, caso uma falha aconteça em um servidor DNS, mesmo que seu servidor web esteja funcionando, ele não poderá ser acessado. A mitigação envolve o uso de múltiplos servidores autoritativos, distribuição geográfica e técnicas como Anycast, que permitem que múltiplas instâncias respondam sob o mesmo endereço IP.
Problemas Comuns de DNS e Diagnóstico
Mesmo sendo um sistema estável e distribuído, problemas relacionados ao DNS são frequentes tanto em redes domésticas quanto em ambientes corporativos. Entender os erros mais comuns ajuda a diagnosticar falhas de forma mais rápida e precisa.
NXDOMAIN
O erro NXDOMAIN (Non-Existent Domain) indica que o domínio consultado não existe na hierarquia do DNS. Isso significa que o servidor autoritativo informou que aquele nome não está registrado.
Esse erro pode ocorrer quando:
O domínio realmente não existe.
Um subdomínio foi digitado incorretamente.
A zona não foi configurada corretamente no servidor autoritativo.
Houve falha na delegação entre zonas.
É importante diferenciar NXDOMAIN de problemas de conectividade. Se o retorno é NXDOMAIN, o DNS respondeu corretamente — apenas informou que o nome não existe.
“Servidor DNS não responde”
Esse erro geralmente indica falha de comunicação com o servidor configurado, e não necessariamente problema no domínio consultado.
As causas mais comuns incluem:
Servidor DNS fora do ar.
Firewall bloqueando a porta 53 (UDP/TCP).
Configuração incorreta de servidor DNS no cliente ou roteador.
Problemas de conectividade com a rede externa.
Nesse caso, o cliente não recebe resposta alguma, diferentemente do NXDOMAIN, onde há resposta válida informando a inexistência do domínio.
TTL mal planejado
O TTL, como explicado anteriormente na seção sobre cache, influencia diretamente o comportamento do cache e pode causar problemas operacionais quando mal configurado.
TTL muito alto:
Mudanças demoram a se propagar.
Correções de erro levam tempo para refletir.
TTL muito baixo:
Aumenta o número de consultas aos servidores autoritativos.
Pode gerar sobrecarga desnecessária.
Reduz a eficiência do cache.
Em ambientes corporativos, é comum reduzir temporariamente o TTL antes de mudanças planejadas (como troca de IP), evitando impacto prolongado.
Ferramentas de diagnóstico: nslookup e dig
Ferramentas como nslookup e dig permitem consultar diretamente servidores DNS e analisar respostas.
Exemplos práticos:
Consultar um domínio usando o servidor configurado no sistema:
nslookup exemplo.com
Consultar explicitamente um servidor específico:
dig @8.8.8.8 exemplo.com
Essas ferramentas permitem verificar:
Se o domínio resolve corretamente.
Qual servidor está respondendo.
O TTL retornado.
Se há diferença entre servidores distintos.
Elas são essenciais para diferenciar problemas locais, de cache, de delegação ou de servidor autoritativo.
Conclusão
O DNS é um dos componentes fundamentais da internet moderna. Apesar de operar de forma quase invisível, ele é essencial para que qualquer serviço online funcione corretamente. Entender sua estrutura, funcionamento e implicações práticas é um passo importante para quem deseja trabalhar com redes ou administrar serviços na internet.