Principais tipos de DNS
Autor: Pedro Tebaldi PM do KeepGreen
Revisão técnica: Ednilson Correa SREO DNS é uma das infraestruturas mais críticas da internet e também uma das mais invisíveis. Serviço fora do ar, e-mail que não chega, aplicação que falha ao resolver um endpoint: o DNS costuma estar no centro desses problemas. Para equipes de TI e engenheiros de redes, entender os tipos de DNS não é curiosidade técnica: é um requisito operacional.
O DNS (Domain Name System) é o sistema que traduz nomes de domínio em endereços IP. Ou seja, sem ele cada acesso a um site ou serviço exigiria memorizar sequências numéricas. Na prática, toda requisição que sai de um dispositivo passa por uma cadeia de servidores DNS antes de chegar ao destino.
Neste artigo você vai entender como funciona essa cadeia, quais são os tipos de servidores DNS e os principais registros. Por fim, verá como o DNS afeta a disponibilidade das suas aplicações.
Todos os números que aparecem aqui saíram de laboratório próprio, não de estimativa. Subimos um servidor autoritativo e um resolvedor recursivo em BIND 9.20.27 sobre Docker. Depois disso, lemos os TTLs de domínios reais nos servidores autoritativos deles, em 3 de setembro de 2026. Além disso, cada número vem com o comando que o produziu.
Como funciona a resolução DNS
Quando um usuário digita um endereço no navegador, o dispositivo não sabe de imediato onde encontrar aquele servidor. O que acontece a seguir é uma cadeia de consultas entre quatro tipos de servidores DNS, cada um com uma função específica.
O processo ocorre em milissegundos e é transparente para o usuário, mas do ponto de vista técnico envolve múltiplos hops de rede. Uma falha em qualquer ponto dessa cadeia se traduz em erro de resolução e, na prática, em downtime percebido pelo usuário final.
A sequência básica sem cache é: Cliente → Resolvedor Recursivo → Servidor Raiz → Servidor TLD → Servidor Autoritativo → Resolvedor → Cliente.
A cadeia medida: 540 ms até a primeira resposta
Na teoria a cadeia tem quatro etapas. Na prática, cada etapa é uma ida e volta pela internet. Portanto, o custo aparece no relógio. O comando dig +trace percorre a hierarquia de cima para baixo e mostra quem respondeu o quê.
Abaixo está a resolução de www.ibge.gov.br feita a partir do laboratório, com o cache do resolvedor vazio. Cada linha corresponde a um salto de rede.
Nesse traço, o resolvedor gastou 32 ms para carregar a lista de servidores raiz. Depois disso, a raiz levou 148 ms para dizer quem responde por .br. Em seguida, o f.dns.br levou 332 ms para apontar os autoritativos do IBGE. Por fim, o salto no servidor autoritativo custou 28 ms e trouxe os dois endereços.
Somados, são 540 ms até a primeira resposta. Logo, a frase “acontece em milissegundos” só vale depois que o cache está quente. Com o cache vazio, meio segundo é o custo real de uma resolução que atravessa três níveis de hierarquia.
O cache muda a conta: 324 ms contra 0 ms
Todo resolvedor recursivo guarda a resposta pelo tempo do TTL. Para medir o efeito, perguntamos o mesmo nome duas vezes ao mesmo resolvedor, com seis segundos de intervalo.
São 324 ms contra 0 ms. Além disso, repare no TTL: ele caiu de 300 para 294, exatamente os seis segundos de intervalo. Assim, o contador decrescente prova que a resposta veio do cache do resolvedor, não do autoritativo.
Daí sai uma armadilha de diagnóstico que engana muita gente. O TTL que você lê num resolvedor é o tempo que resta, não o que a zona configurou. Para descobrir o TTL real de um domínio, pergunte ao servidor autoritativo dele com +norecurse.
Os 4 tipos de servidores DNS
Resolvedor Recursivo
O resolvedor recursivo (ou recursor DNS) é o primeiro ponto de contato de qualquer consulta DNS. Antes de tudo, ele atua como intermediário entre o cliente e os demais servidores da hierarquia. Ao receber uma consulta, ele verifica primeiro o próprio cache. Se o endereço já foi resolvido e o TTL ainda vale, responde na hora, sem percorrer a cadeia.
Na maior parte dos casos, o ISP do usuário fornece esse resolvedor. Ele também pode ser apontado à mão, como o 8.8.8.8 do Google ou o 1.1.1.1 da Cloudflare. Em redes corporativas, por outro lado, é comum ter resolvedores internos para domínios privados.
Servidor Raiz
O servidor raiz está no topo da hierarquia DNS. Existem 13 identificadores de servidores raiz, de A a M. No entanto, centenas de instâncias físicas espalhadas pelo mundo operam via Anycast, o que garante disponibilidade e latência baixa.
Nenhum servidor raiz armazena o IP final de um domínio. Todavia, a função dele é receber a consulta do resolvedor e indicar qual servidor TLD responde pela extensão consultada. No teste acima, quem atendeu foi o b.root-servers.net, em 148 ms. Os servidores raiz são supervisionados pela ICANN.
Servidor TLD
O servidor TLD (Top-Level Domain) gerencia todos os domínios que usam uma determinada extensão. Ele não armazena o IP final, mas indica qual é o servidor autoritativo responsável por aquele domínio específico. A IANA administra os TLDs, divididos em genéricos (.com, .org, .net) e por código de país (.br, .us, .pt).
No caso brasileiro, quem responde é a família a.dns.br até f.dns.br, operada pelo Registro.br. Ela atende tanto .com.br quanto os domínios de terceiro nível como .gov.br. Isto é, não existe delegação intermediária no caminho.
Servidor Autoritativo
O servidor autoritativo é a fonte oficial das informações de um domínio. É aqui que ficam os registros DNS reais. Ou seja, o endereço IP do servidor web, a configuração de e-mail, os registros de validação e o resto dos dados do domínio.
Quando o resolvedor recursivo chega ao servidor autoritativo, ele obtém a resposta definitiva. Se o domínio tiver um registro A, o servidor retorna o IP diretamente. Se tiver um CNAME, retorna o alias. Em seguida, o resolvedor abre uma nova consulta para o domínio de destino.
DNS primário e DNS secundário
Nas configurações de rede de qualquer dispositivo ou servidor, é possível definir dois endereços de servidores DNS: um primário e um secundário. Em termos de função, ambos são resolvedores recursivos capazes de responder consultas.
A distinção, contudo, está no papel de redundância. O DNS primário é consultado primeiro. Se não responder dentro do timeout configurado, o sistema consulta o DNS secundário. Por isso, uma falha no primário sem fallback interrompe toda a resolução de nomes do host.
Em ambientes corporativos, o arranjo comum usa resolvedores internos como DNS primário, para os domínios privados. O secundário fica com um DNS público confiável, que atende os domínios externos se o interno falhar.
Quanto custa um DNS primário fora do ar
Quase todo texto sobre o assunto para nesse ponto e diz que o secundário assume. Medimos quanto custa esse assumir. No laboratório, o primário aponta para um endereço que existe na rota e engole o pacote em silêncio, enquanto o secundário responde normalmente.
| Como o primário falha | Debian 13 (glibc 2.41) | Alpine 3.20 (musl 1.2.5) | Custo por resolução |
|---|---|---|---|
| Engole o pacote (rota existe, ninguém responde) | 10,01 s | 2,4 a 3,8 ms | O pior caso: dois timeouts de 5 s, um para AAAA e outro para A |
| Some da camada 2 (sem resposta de ARP) | 6,14 s | sem custo medido | O kernel desiste antes do timeout do resolvedor |
| Recusa a conexão (ICMP port unreachable) | 2,0 a 2,4 ms | 2,5 a 3,0 ms | O erro volta na hora: é o caso que engana no teste de mesa |
| Linha de base (só o resolvedor vivo) | 2,2 a 2,6 ms | 2,4 a 2,7 ms | Referência para comparar os três cenários acima |
Os pacotes explicam o número de 10 segundos. A pergunta AAAA sai para o primário em t=0. A repetição só vai para o secundário 5,005 s depois. Em seguida, a pergunta A refaz o mesmo ciclo do zero.
São dois timeouts de 5 s na mesma chamada. A biblioteca não guarda, entre uma pergunta e a outra, que o primário está morto. Por isso, paga o preço duas vezes na mesma resolução.
Em Alpine 3.20 o comportamento é outro. A musl envia as duas perguntas para os dois servidores com 64 microssegundos de diferença. Depois disso, usa a que responder primeiro. Ou seja, não existe primário em musl. Isso muda o diagnóstico de qualquer contêiner baseado nessa distribuição.
Vale um critério prático para o teste de failover: derrube a rota, não pare o serviço. Parar o daemon faz o servidor recusar a conexão: o erro volta em milissegundos e o teste passa. O caso que dói é o outro, isto é, quando o pacote entra e ninguém responde.
Principais tipos de registros DNS
Além dos tipos de servidores, existe outra classificação igualmente importante: os tipos de registros DNS. Cada registro armazenado no servidor autoritativo tem um tipo que define sua função.
O registro A mapeia um nome de domínio para um endereço IPv4. É, inclusive, o registro mais comum e o ponto de entrada da maioria dos serviços web. O registro AAAA faz o mesmo para endereços IPv6. O registro CNAME cria um alias de um domínio para outro, muito usado em CDNs e subdomínios.
O registro MX define os servidores de e-mail responsáveis por um domínio, com campo de prioridade para definir a ordem de tentativa. O registro TXT é amplamente usado para validação de domínio (SPF, DKIM, DMARC) e verificação de propriedade. O registro NS indica quais servidores autoritativos são responsáveis por uma zona DNS.
Nenhum TTL da tabela abaixo veio de manual. Todos foram lidos com dig +norecurse nos servidores autoritativos de 12 domínios brasileiros e globais, em 3 de setembro de 2026. O formato de cada tipo de registro está definido na RFC 1035, de 1987, que segue valendo.
| Registro | O que resolve | TTL medido em 03/09/2026 | Armadilha operacional |
|---|---|---|---|
| A | Nome para endereço IPv4 | Mediana de 300 s. Vai de 20 s (Itaú, Bradesco) a 172.800 s (Registro.br) | TTL alto trava a troca de servidor pelo tempo que já está em cache |
| AAAA | Nome para endereço IPv6 | Acompanha o valor do registro A quando o domínio publica os dois | O sistema pergunta AAAA antes de A: com resolvedor fora do ar, o custo dobra |
| CNAME | Apelido de um nome para outro nome | 60 s em www.uol.com.br, 172.800 s em www.registro.br |
O resolvedor ainda precisa resolver o destino, então os dois tempos se somam |
| MX | Servidores de e-mail, por ordem de prioridade | Mediana de 1.800 s. O UOL publica 18.000 s | MX com TTL alto atrasa em horas a virada de provedor de e-mail |
| TXT | Validação de domínio: SPF, DKIM, DMARC | 300 s em 5 dos 12 domínios. O UOL publica 1 s | Corrigir o SPF não conserta a entrega antes de o cache do destinatário expirar |
| NS | Quais autoritativos respondem pela zona | 172.800 s (48 h) em 5 dos 12 domínios | Trocar de provedor de DNS leva até 48 h, porque esse TTL vive no TLD |
| SOA | Dados administrativos da zona | Campo minimum de 60 s a 86.400 s |
O minimum é o TTL do NXDOMAIN: define quanto tempo um nome novo fica invisível |
Duas leituras saltam da tabela. Bancos operam com TTL de 20 s no registro A, porque precisam virar de endereço em segundos. O Registro.br, por outro lado, usa 172.800 s no mesmo registro: o endereço não muda e o volume de consultas é enorme.
TTL: o número que decide a sua janela de mudança
O TTL (Time to Live) de cada registro define por quanto tempo os resolvedores podem guardar aquela resposta. TTLs altos reduzem a carga nos servidores autoritativos e atrasam qualquer alteração. Em contrapartida, TTLs baixos permitem virar rápido, ao custo de mais consultas recursivas.
Baixar o TTL na hora da migração é o erro clássico. Medimos o efeito no laboratório: o nome app.labdns.test estava com TTL 300 e foi resolvido em t=0. Aos 13 segundos, o IP mudou no autoritativo e o TTL caiu de 300 para 30 no mesmo instante. É o que quase todo mundo faz na janela.
Só aos 302 segundos o resolvedor entregou o endereço novo. Portanto, baixar o TTL junto com a troca não adiantou nada: valeu o TTL que já estava guardado. Ao mesmo tempo, o nome que já vivia com TTL 30 convergiu em 32 segundos, quase dez vezes mais rápido.
Daí sai o limiar operacional. Baixe o TTL pelo menos um TTL antigo inteiro antes da janela. Por exemplo: se o registro está publicado em 3.600 s, o valor novo precisa estar no ar uma hora antes. Depois da janela, devolva o TTL original.
Cache negativo: por que o registro novo não aparece
Existe ainda um segundo cache no resolvedor. O que ele guarda é a ausência do nome. Quando o servidor autoritativo responde NXDOMAIN, o resolvedor memoriza que aquele nome não existe. O tempo dessa memória vem do campo minimum do registro SOA da zona, conforme a RFC 2308.
Aos 7 segundos o registro passou a existir. Ele só ficou visível aos 62. São 55 segundos de invisibilidade governados pelo SOA da zona, não pelo TTL 30 do registro recém-criado. No painel medido acima, esse campo vai de 60 s a 86.400 s.
Num domínio configurado com 86.400, um nome criado agora pode levar 24 horas para aparecer para quem já consultou antes. Daí vem a ordem de execução correta: publique o registro primeiro e teste depois. Consultar o nome antes de criá-lo, por exemplo, planta o cache negativo que atrapalha o próprio teste.
DNS público vs DNS privado
O DNS público é acessível por qualquer dispositivo conectado à internet. Os mais utilizados em infraestrutura são o Google Public DNS (8.8.8.8 e 8.8.4.4) e o Cloudflare DNS (1.1.1.1), ambos com foco em velocidade e privacidade.
O DNS privado opera dentro de uma rede corporativa ou VPN, resolvendo nomes internos que não existem no DNS público. Assim, aplicações de ambiente híbrido e on-premise ganham hostname próprio sem expor endereço IP à internet.
Combinar o DNS privado interno com um DNS público de fallback é o padrão mais comum em infraestrutura corporativa segura. Vale destacar o custo medido acima. Se o resolvedor interno cair sem recusar a conexão, cada resolução passa a custar 10 s antes de chegar ao público.
DNS, segurança e disponibilidade
O DNS é um vetor frequente de ataques e falhas de disponibilidade. O DNS Spoofing, ou envenenamento de cache, acontece quando um atacante insere registros falsos no cache de um resolvedor, redirecionando usuários para servidores maliciosos.
O DNSSEC mitiga esse risco com assinaturas criptográficas nos registros, que permitem ao resolvedor verificar a autenticidade da resposta. Ele não esconde a consulta, no entanto: apenas prova que ela não foi alterada no caminho.
Quem precisa de sigilo usa outra camada. O DNS over HTTPS (DoH) e o DNS over TLS (DoT) encriptam o conteúdo da consulta. Dessa forma, provedores e atacantes não conseguem ler nem manipular as respostas.
Ataques de DDoS sobre DNS visam sobrecarregar resolvedores ou servidores autoritativos, tornando domínios inteiros irresolvíveis. Assim, para infraestrutura crítica, a mitigação principal é usar múltiplos provedores de DNS autoritativo com Anycast.
DNS e monitoramento: quando o DNS causa downtime
Do ponto de vista de operações de TI, o DNS é uma causa silenciosa de incidentes que frequentemente passa despercebida. TTL mal configurado antes de uma migração, registro MX expirado ou falha no servidor autoritativo derrubam serviços inteiros. Pior: nada disso gera alerta óbvio no monitoramento de aplicação.
Nesse sentido, a observabilidade de infraestrutura precisa incluir monitoramento ativo de DNS. São quatro verificações: resolução periódica dos domínios críticos, alerta para TTL inesperado, divergência entre autoritativos e tempo de resposta como métrica de latência de rede.
Os números do laboratório servem de linha de base para calibrar esse alerta. No ambiente medido, a resposta em cache custou menos de 1 ms e a cadeia inteira custou 540 ms. Portanto, um tempo de resolução acima de 1 s aponta cadeia quebrada ou cache frio, não lentidão genérica de rede.
Integrar o DNS ao monitoramento de servidores e ao monitoramento de tráfego de rede correlaciona falha de resolução com degradação de aplicação. Dessa forma, o time enxerga o impacto antes do usuário final.
Identificamos gargalos de rede antes que virem incidentes críticos.
Análise de tráfego com NetFlow, sFlow e SNMP para mapeamento completo de latência, perda de pacotes e capacidade de banda.
Conclusão
O DNS é muito mais do que um serviço de tradução de nomes. É, sobretudo, uma infraestrutura hierárquica distribuída que sustenta a disponibilidade de toda aplicação conectada à internet. Entender os tipos de servidores DNS, os registros e os protocolos de segurança é o primeiro passo. O passo seguinte é operar rede com confiabilidade e diagnosticar falha com precisão.
Três números medidos aqui resumem o que costuma doer na operação. São 540 ms para atravessar a cadeia com o cache vazio e 302 s para o resolvedor largar um registro já guardado. O terceiro é 10 s por resolução, quando o DNS primário some sem recusar a conexão. Nenhum deles aparece num diagrama de arquitetura, mas os três aparecem no chamado.
Em 2026, com arquiteturas distribuídas, microsserviços e ambientes multi-cloud, o DNS ganhou mais complexidade e mais peso operacional. Em contrapartida, quem monitora DNS pela tendência detecta o problema antes que ele vire incidente. Para estruturar o monitoramento 24×7 de DNS e redes na sua organização, fale com nossos especialistas.
Perguntas Frequentes
O que é DNS e para que serve?
Quais são os 4 tipos de servidores DNS?
Qual a diferença entre DNS primário e DNS secundário?
Qual a diferença entre DNS público e DNS privado?
O que são registros DNS A, CNAME e MX?
Como funciona a resolução DNS passo a passo?
