O Que o DNS Faz e Como Funciona?

DNS (Domain Name System) é a infraestrutura de nomenclatura distribuída da internet que traduz nomes de domínio legíveis por humanos — como example.com — em endereços IP legíveis por máquinas, como 93.184.216.34. Sem DNS, cada pedido do navegador, chamada API e entrega de email exigiria que utilizadores e aplicações conhecessem o endereço numérico exato de cada host remoto, tornando a internet moderna operacionalmente impossível em escala.

Na sua essência, o DNS é uma base de dados hierárquica globalmente distribuída. Não é um único servidor nem um registo centralizado — é uma árvore de delegação que abrange centenas de milhares de servidores de nomes autoritativos em todo o mundo, coordenada através de um pequeno conjunto de servidores raiz e regida por normas definidas no RFC 1034 e RFC 1035.

Por Que o DNS É Mais do Que Apenas uma “Lista Telefónica”

A analogia com a lista telefónica é útil para iniciantes, mas subestima dramaticamente o que o DNS realmente faz. O DNS é um sistema de pesquisa em tempo real, tolerante a falhas e globalmente replicado que também gere:

• Encaminhamento de email via registos MX, direcionando o email para os servidores de email corretos
• Descoberta de serviços via registos SRV, utilizados por protocolos como SIP, XMPP e redes internas do Kubernetes
• Verificação de propriedade de domínio via registos TXT, utilizados para SPF, DKIM, DMARC e Google Search Console
• Nomenclatura canónica via registos CNAME, permitindo integração com CDN e balanceamento de carga
• Endereçamento IPv6 via registos AAAA
• Pesquisas inversas via registos PTR na zona in-addr.arpa, críticos para a reputação do servidor de email e auditoria de segurança
• Validação DNSSEC, que adiciona assinaturas criptográficas às respostas DNS para prevenir envenenamento de cache

Cada vez que envia um email, se liga a uma VPN ou carrega uma aplicação web, o DNS está a resolver múltiplos tipos de registos em segundo plano — frequentemente dezenas de consultas por carregamento de página.

A Hierarquia DNS: Como o Espaço de Nomes Está Estruturado

O DNS está organizado como uma árvore invertida. Compreender esta estrutura é essencial para entender por que a resolução funciona da forma que funciona.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Zona Raiz (.): Gerida pela IANA. Existem 13 endereços lógicos de servidores raiz (A a M), operados por organizações como a Verisign, NASA e ICANN. Na prática, são servidos por centenas de máquinas físicas via encaminhamento anycast.
• Domínios de Topo (TLDs): TLDs genéricos como .com, .net, .org, e TLDs de código de país como .uk, .de, .md. Cada TLD tem o seu próprio conjunto de servidores de nomes autoritativos.
• Domínios de Segundo Nível (SLDs): O domínio que regista — example.com. O DNS autoritativo para esta zona é controlado por quem registou o domínio.
• Subdomínios: www, mail, api, staging — estes são registos dentro da zona SLD, totalmente controlados pelo proprietário do domínio.

Passo a Passo: Como uma Consulta DNS É Resolvida

Uma resolução DNS recursiva completa envolve até sete trocas de rede distintas. Aqui está a sequência precisa:

Passo 1 — Verificação da Cache do Navegador

Quando escreve www.example.com no seu navegador, o sistema operativo verifica primeiro a sua cache DNS local. No Linux, isto pode ser gerido pelo systemd-resolved; no Windows, pelo serviço DNS Client. Se existir um registo em cache válido e o seu TTL (Time to Live) não tiver expirado, a resolução termina aqui.

Pode inspecionar a cache DNS local no Linux com:

resolvectl statistics

Ou limpá-la com:

sudo resolvectl flush-caches

No Windows:

ipconfig /displaydns
ipconfig /flushdns

Passo 2 — Consulta ao Resolver Recursivo

Se não existir resposta em cache, o sistema operativo encaminha a consulta para o resolver recursivo configurado (também chamado servidor DNS recursivo ou resolver de serviço completo). Este é tipicamente:

• O resolver do seu ISP (atribuído via DHCP)
• Um resolver público: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Um resolver auto-hospedado como Unbound ou BIND na sua própria infraestrutura de Alojamento VPS

O resolver recursivo faz o trabalho pesado. Percorrerá a hierarquia DNS em seu nome e guardará os resultados em cache para servir consultas futuras mais rapidamente.

Passo 3 — Referência ao Servidor Raiz

O resolver recursivo consulta um dos 13 clusters de servidores raiz. O servidor raiz não conhece o endereço IP de www.example.com. Em vez disso, devolve uma referência — uma lista de servidores de nomes autoritativos para a zona TLD .com, juntamente com os seus endereços IP (chamados registos glue).

Passo 4 — Consulta ao Servidor de Nomes TLD

O resolver consulta os servidores de nomes TLD .com (operados pela Verisign). Estes servidores também não detêm a resposta final. Devolvem outra referência — os servidores de nomes autoritativos para example.com especificamente (por exemplo, ns1.example.com, ns2.example.com).

Passo 5 — Consulta ao Servidor de Nomes Autoritativo

O resolver consulta o servidor de nomes autoritativo para example.com. Este servidor detém o ficheiro de zona real e devolve a resposta definitiva — o registo A contendo o endereço IPv4 (ou AAAA para IPv6).

Passo 6 — Armazenamento em Cache e Entrega da Resposta

O resolver recursivo guarda a resposta em cache de acordo com o valor TTL do registo (por exemplo, 300 segundos = 5 minutos, 86400 segundos = 24 horas). Em seguida, devolve o endereço IP ao sistema operativo do cliente, que o passa ao navegador.

Passo 7 — Ligação TCP/IP

O navegador utiliza o endereço IP resolvido para abrir uma ligação TCP (tipicamente na porta 443 para HTTPS). O trabalho do DNS está agora concluído. O servidor web responde e a página carrega.

Todo este processo — passos 2 a 6 — completa-se tipicamente em 20–120 milissegundos numa cache de resolver quente, e em menos de 500 milissegundos para uma resolução completamente fria e sem cache que percorre todos os níveis da hierarquia.

Tipos de Registos DNS: Uma Referência Técnica

Os registos CAA merecem menção especial: instruem as Autoridades de Certificação sobre quais organizações têm permissão para emitir Certificados SSL para o seu domínio — um controlo de segurança crítico que é frequentemente ignorado.

Tipos de Consulta DNS: Recursiva vs. Iterativa vs. Não Recursiva

A maioria dos dispositivos de utilizadores finais envia consultas recursivas para o seu resolver configurado. O próprio resolver utiliza consultas iterativas ao percorrer a hierarquia.

TTL: O Parâmetro DNS Mais Incompreendido

O TTL (Time to Live) é o número de segundos durante os quais um registo DNS pode ser guardado em cache por resolvers e clientes. É definido pelo proprietário do domínio no ficheiro de zona.

• TTL baixo (60–300 segundos): Propagação mais rápida das alterações. Essencial antes de migrações planeadas, alterações de IP ou eventos de failover. Aumenta a carga de consultas nos servidores autoritativos.
• TTL alto (3600–86400 segundos): Reduz a carga do resolver e acelera as consultas repetidas. As alterações demoram mais tempo a propagar-se globalmente.

Informação operacional crítica: Ao planear uma migração de servidor ou alteração de IP, reduza o seu TTL para 300 segundos pelo menos 48 horas antes da alteração. Isto garante que, no momento em que atualizar o registo A, nenhum resolver esteja a guardar em cache o valor antigo por mais de 5 minutos. Não o fazer é uma das causas mais comuns de tempo de inatividade prolongado durante migrações.

Quando regista um domínio através do Registo de Domínios e o aponta para um novo servidor, a janela de propagação é diretamente governada pelo valor TTL anterior — não por alguma regra arbitrária de “24–48 horas” que é frequentemente citada incorretamente.

Protocolos de Transporte DNS: UDP, TCP, DoH e DoT

O DNS tradicional opera sobre a porta UDP 53 para consultas com menos de 512 bytes. As respostas que excedem este tamanho desencadeiam uma alternância para a porta TCP 53. As respostas DNSSEC, transferências de zona (AXFR) e registos TXT de grande dimensão requerem frequentemente TCP.

Os protocolos modernos de privacidade DNS alteraram significativamente este panorama:

DoH vs. DoT — a diferença operacional real: O DoH encapsula o DNS dentro do tráfego HTTPS na porta 443, tornando-o indistinguível do tráfego web normal. Isto é útil para a privacidade, mas torna a monitorização e filtragem de redes empresariais significativamente mais difícil. O DoT utiliza uma porta dedicada (853), que os administradores de rede podem monitorizar, bloquear ou inspecionar de forma independente. Para infraestrutura auto-gerida num Servidor Dedicado, executar um resolver DoT ou DoH local proporciona tanto privacidade como controlo total sobre a política de resolução.

DNSSEC: Integridade Criptográfica para DNS

O DNSSEC (DNS Security Extensions) adiciona uma cadeia de assinaturas criptográficas às respostas DNS, permitindo que os resolvers verifiquem que uma resposta é autêntica e não foi adulterada em trânsito. Protege contra o envenenamento de cache DNS (ataque Kaminsky) e a falsificação DNS por man-in-the-middle.

O DNSSEC não encripta o tráfego DNS — apenas o assina. A cadeia de assinaturas funciona da seguinte forma:

1. O proprietário da zona gera uma Chave de Assinatura de Zona (ZSK) e uma Chave de Assinatura de Chave (KSK)
2. Cada conjunto de registos DNS é assinado com a ZSK, produzindo registos RRSIG
3. A KSK assina o conjunto de registos DNSKEY
4. Um registo DS (Delegation Signer) é publicado na zona pai (por exemplo, .com), criando a cadeia de confiança até à raiz

Ativar o DNSSEC é fortemente recomendado para qualquer domínio que lide com transações financeiras, autenticação ou email. Um DNSSEC mal configurado — particularmente uma assinatura expirada ou um registo DS incompatível — causará falha completa de resolução para resolvers com validação, o que é um modo de falha mais grave do que não ter DNSSEC de todo.

Falhas DNS Comuns e Como Diagnosticá-las

NXDOMAIN — Domínio Inexistente

O servidor autoritativo confirmou que o domínio não existe. Causas comuns: erro de digitação no nome do domínio, registo de domínio expirado, registo DNS eliminado.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — Falha do Servidor

O resolver não conseguiu completar a consulta. Causas comuns: falha de validação DNSSEC, servidor autoritativo inacessível, ficheiro de zona mal configurado.

dig +dnssec example.com
# Look for: status: SERVFAIL

Para contornar a validação DNSSEC e isolar o problema:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Cache Desatualizada / Atraso de Propagação

Após atualizar um registo DNS, os valores antigos persistem nas caches dos resolvers até o TTL expirar. Para consultar diretamente o servidor autoritativo e contornar a cache do resolver:

dig @ns1.example.com www.example.com

Verificar a Propagação DNS Globalmente

Utilize dig com resolvers públicos específicos para verificar o estado de propagação:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS em Ambientes de Alojamento: Configurações Práticas

Quando implementa um website ou aplicação num VPS com cPanel, a gestão DNS é tipicamente tratada através do cluster DNS do WHM ou do Editor de Zonas do cPanel. Compreender a estrutura subjacente do ficheiro de zona permite-lhe fazer alterações que a interface gráfica não expõe.

Um ficheiro de zona mínimo para example.com tem o seguinte aspeto:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Para que o Alojamento de Email funcione corretamente, o registo MX deve apontar para um hostname (não diretamente para um endereço IP), e esse hostname deve resolver-se através de um registo A. Uma configuração incorreta comum é apontar MX diretamente para um IP — isto viola o RFC 2821 e causa falhas de entrega com servidores de email rigorosos.

Desempenho DNS: O Que Realmente Afeta a Velocidade de Resolução

• Proximidade do resolver: Um resolver geograficamente próximo do cliente (ou na mesma rede) reduz drasticamente o tempo de ida e volta.
• Taxa de acertos na cache: Domínios de alto tráfego com TTLs razoáveis são quase sempre servidos a partir da cache. A resolução com cache fria é 5–20 vezes mais lenta.
• Encaminhamento anycast: Os servidores raiz e os principais resolvers públicos utilizam anycast, encaminhando automaticamente as consultas para o nó físico mais próximo.
• Número de pesquisas DNS por página: Uma única página web pode desencadear 20–50 consultas DNS (recursos CDN, análises, fontes, redes de publicidade). Os navegadores paralelizam estas consultas, mas cada hostname único requer a sua própria pesquisa.
• Pré-carregamento DNS: Os navegadores modernos suportam <link rel="dns-prefetch" href="//cdn.example.com"> para resolver hostnames de terceiros antes de serem necessários, reduzindo a latência percebida.

DNS vs. Mecanismos Alternativos de Resolução

O ficheiro /etc/hosts é avaliado antes do DNS em praticamente todos os sistemas operativos. Isto torna-o inestimável para o desenvolvimento local — pode mapear myapp.local para 127.0.0.1 sem tocar em qualquer infraestrutura DNS.

Principais Conclusões e Lista de Verificação de Decisões

Utilize esta lista de verificação ao configurar ou resolver problemas de DNS em qualquer ambiente de produção:

• Antes de qualquer migração de servidor: Reduza o TTL para 300 segundos pelo menos 48 horas antes
• Para entregabilidade de email: Verifique se os registos MX, SPF (TXT), DKIM (TXT), DMARC (TXT) e PTR estão todos corretamente configurados
• Para segurança: Ative o DNSSEC no seu domínio e adicione registos CAA para restringir a emissão de certificados
• Para privacidade: Utilize DoT ou DoH em dispositivos cliente e servidores; evite enviar DNS em texto simples sobre redes não confiáveis
• Para desempenho: Defina o TTL para 3600–86400 para registos estáveis; utilize 300 apenas para registos que mudam frequentemente
• Para diagnóstico: Consulte sempre o servidor autoritativo diretamente com dig @ns1.yourdomain.com para distinguir o atraso de propagação de uma configuração incorreta genuína
• Para gestão de zonas: Incremente o número de série SOA sempre que modificar um ficheiro de zona — os resolvers utilizam-no para detetar alterações
• Para alojamento: Confirme que a delegação de servidores de nomes do seu registador corresponde aos registos NS no seu ficheiro de zona — uma incompatibilidade é a causa mais comum de “DNS não funciona” após uma transferência de domínio

Perguntas Frequentes

Qual é a diferença entre um resolver DNS e um servidor DNS autoritativo?

Um resolver recursivo (por exemplo, 8.8.8.8) é um intermediário que consulta a hierarquia DNS em nome do seu dispositivo e guarda os resultados em cache. Um servidor de nomes autoritativo detém os registos de zona reais para um domínio específico e fornece respostas definitivas. O seu resolver consulta muitos servidores autoritativos; o servidor autoritativo do seu domínio apenas responde para as zonas que aloja.

Por que é que a propagação DNS demora tempo após atualizar um registo?

O atraso de propagação é causado pelo armazenamento em cache baseado em TTL. Cada resolver que anteriormente guardou em cache o seu registo antigo continuará a servi-lo até o TTL expirar. Se o seu TTL era 86400 (24 horas), os resolvers podem servir o registo antigo durante até 24 horas após a sua atualização. Isto não é um erro — é o mecanismo de cache pretendido que torna o DNS escalável.

O que é uma fuga DNS e por que é importante?

Uma fuga DNS ocorre quando o seu dispositivo envia consultas DNS fora do resolver pretendido — tipicamente o resolver do seu ISP — mesmo quando utiliza uma VPN ou ferramenta de privacidade. Isto expõe a sua atividade de navegação ao seu ISP. Pode testar fugas em dnsleaktest.com e corrigi-las configurando o seu cliente VPN para forçar o encaminhamento DNS através do seu próprio resolver.

O DNS pode ser utilizado como vetor de ataque?

Sim. Os ataques baseados em DNS comuns incluem envenenamento de cache (injeção de registos falsos na cache de um resolver), DDoS de amplificação DNS (utilização de resolvers abertos para inundar um alvo com grandes respostas DNS), sequestro DNS (redirecionamento de consultas para servidores maliciosos) e tunelamento DNS (exfiltração de dados codificando-os em strings de consulta DNS). O DNSSEC mitiga o envenenamento de cache; a limitação de taxa e a limitação de taxa de resposta (RRL) nos servidores autoritativos mitigam a amplificação.

Como encontro os servidores de nomes autoritativos para qualquer domínio?

Utilize dig com o tipo de registo NS e o sinalizador +short para uma saída limpa:

dig NS example.com +short

Para rastrear o caminho completo de delegação desde a raiz até ao autoritativo, utilize:

dig +trace example.com

Isto mostra cada salto de referência — raiz → TLD → autoritativo — que é a forma mais fiável de diagnosticar configurações incorretas de delegação.