O que é DNS: guia do sistema de nomes

DNS (sistema de nomes de domínio) é o serviço distribuído da Internet que associa nomes legíveis, como o de um site ou de um servidor de e-mail, aos endereços numéricos que as máquinas usam para se conectar. Sem essa resolução, você precisaria memorizar IPs. O sistema é hierárquico, com caches e servidores especializados em cada nível da árvore de nomes.

Você digita um endereço no navegador e espera a página abrir. Por trás disso, antes de qualquer HTML, a máquina precisa descobrir para qual IP enviar o pedido. Quando essa etapa falha, o sintoma parece genérico, como site fora do ar, e-mail que não chega ou aplicativo que “não conecta”, embora o servidor de destino possa estar saudável.

Quem publica um blog, uma loja ou um painel em SaaS depende dessa tradução o tempo todo. Além disso, quem só consome a web também depende, porque o provedor, o roteador e o sistema operacional escolhem um caminho de consulta. Assim, entender o DNS ajuda a separar problema de hospedagem, de e-mail e de configuração de nome.

Como o DNS traduz um nome em endereço IP?#

A resolução DNS começa no seu dispositivo e termina num servidor que responde com autoridade sobre aquele nome. Segundo o glossário da MDN sobre DNS, o sistema mantém nomes associados a recursos, sobretudo endereços IP, e a busca desse mapeamento é o lookup. O navegador ou o sistema operacional pergunta a um resolvedor. Esse resolvedor, por sua vez, percorre a hierarquia até achar a resposta ou um encaminhamento útil.

Na prática o fluxo costuma seguir camadas. Primeiro há cache local e cache do resolvedor, que evitam repetir a mesma pergunta enquanto o tempo de vida do registro ainda vale. Em seguida vêm os servidores da raiz e do domínio de topo, que não guardam o IP final de cada site, porém indicam quem fala pela próxima fatia do nome. Por fim chega o servidor autoritativo da zona, que devolve o dado pedido, por exemplo um endereço IPv4 ou IPv6.

Um exemplo concreto ajuda. Imagine que você abre loja.exemplo.com.br. O resolvedor precisa saber quem responde por .br, depois por exemplo.com.br, e só então consulta o registro do host loja. Enquanto isso, se o TTL ainda estiver válido num cache intermediário, a resposta pode vir sem tocar o servidor oficial. Por outro lado, TTL curto acelera a visão de mudanças e aumenta o volume de consultas. TTL longo reduz tráfego e atrasa a correção quando você troca de hospedagem.

Há um custo escondido nessa velocidade. Resposta em cache errada ou adulterada pode levar muita gente ao lugar errado ao mesmo tempo. Por isso a resolução DNS não é só achar o IP. Ela também é um ponto em que privacidade e integridade importam, porque a consulta tradicional costuma viajar em texto claro e porque um intermediário malicioso pode tentar influenciar a resposta.

E se o nome existir, porém o tipo de registro estiver errado? O site pode falhar mesmo com domínio registrado, porque um A apontando para o IP antigo ou um CNAME quebrado não entrega o serviço certo. E se o domínio estiver certo e o DNS do provedor estiver lento? Você sente latência antes do primeiro byte da página, sobretudo em redes móveis, quando cada hostname novo dispara outra consulta.

No dia a dia de quem opera site, o que costuma travar o acesso depois de uma migração é cache ainda servindo o IP antigo, não a queda da máquina nova. Por isso eu baixo o TTL com antecedência, migro, confiro com consulta direta ao autoritativo e só então subo o TTL de novo.

Quais registros DNS você precisa conhecer primeiro?#

Os registros DNS são as fichas que dizem o que um nome significa. O conjunto clássico do protocolo aparece nas especificações de implementação do DNS, como a RFC 1035, de novembro de 1987, e foi ampliado depois para IPv6 e outros usos. Para o leitor leigo, bastam os tipos que aparecem em quase toda conta de hospedagem ou de e-mail.

A documentação de conceitos básicos de DNS da Microsoft descreve A, CNAME, MX, NS e o uso de TXT para políticas como SPF no mesmo espírito. O registro AAAA, por sua vez, foi definido para armazenar endereço IPv6, conforme a família de extensões documentada na RFC 3596, de outubro de 2003. Assim, um site moderno pode publicar A e AAAA ao mesmo tempo, e o cliente escolhe o caminho conforme a rede.

Exemplo de zona mínima para site e e-mail#

Suponha o domínio oficina.exemplo.com.br com site na hospedagem e correio noutro provedor. Uma configuração didática, com IPs fictícios da faixa de documentação, seria um A em @ para 192.0.2.10, um AAAA para 2001:db8::10, um CNAME de www para o hostname da hospedagem, um MX com preferência 10 apontando para mail.provedor.exemplo, e TXT com a política SPF pedida pelo provedor de e-mail. Porém, CNAME no ápice da zona colide com NS e SOA. Por isso muita gente usa A ou AAAA no raiz e reserva CNAME para subdomínios.

O risco clássico aqui é misturar pedaços de tutoriais. Você aponta o site certo e esquece o MX, ou altera NS sem copiar todos os TXT de verificação, e perde e-mail ou a validação de um serviço. Além disso, TTL agressivamente baixo em todos os registros eleva carga sem benefício se você não está prestes a migrar. Em contrapartida, TTL alto demais depois de um IP errado alonga o prejuízo.

Quando eu reviso uma zona nova, começo pelos NS e pelo SOA, depois confiro A ou AAAA do host principal, em seguida MX e TXT de correio, e só no fim os CNAME de serviços satélites. Essa ordem reduz a chance de site ok e e-mail morto, que é o combo mais caro para quem depende de atendimento.

Qual a diferença entre servidor DNS recursivo e autoritativo?#

O servidor DNS recursivo trabalha a pedido dos clientes da rede. Ele recebe a pergunta do seu notebook ou do roteador, consulta outros servidores e devolve a resposta final, muitas vezes com cache. Já o servidor autoritativo guarda a zona oficial de um domínio e responde o que foi publicado ali, sem precisar descobrir o dado em outra árvore para nomes sob sua autoridade. O CERT.br explica essa separação ao tratar de recursivos abertos e dos abusos que eles facilitam.

A armadilha operacional é juntar as duas funções sem filtro. Um recursivo aberto para a Internet inteira pode ser usado em ataques de amplificação e também fica mais exposto a tentativas de envenenamento de cache. Por outro lado, um autoritativo mal protegido, com transferência de zona liberada demais, entrega mapa interno da rede a quem não deveria vê-lo. Separar papéis e restringir quem pode perguntar em modo recursivo são medidas de higiene, não enfeite.

O que isso muda para quem só tem um domínio#

Se você só registrou um .br e usa o DNS do registrador ou da hospedagem, na prática consome os dois lados sem administrá-los. Seu celular fala com o recursivo do provedor ou com um resolvedor público. Esse recursivo fala com o autoritativo da sua zona. Porém, se você sobe um resolvedor em casa ou na empresa para aprender, e deixa recursão aberta, o equipamento deixa de ser laboratório e vira alvo. O custo não é só banda. Pode haver envolvimento em abuso contra terceiros.

E se o recursivo do provedor falhar? Sites somem para muitos clientes ao mesmo tempo, mesmo com autoritativo saudável. E se o autoritativo cair e não houver secundário? A zona some da Internet na medida em que os caches expiram. Por isso zonas sérias publicam mais de um NS em redes distintas, aceitando o custo de manter réplicas coerentes.

Quem trata recursivo e autoritativo como a mesma caixa costuma descobrir o problema só depois do incidente. Eu prefiro recursão só para a rede interna, autoridade em hosts separados sempre que o tamanho da operação permitir, e monitoramento de consultas anômalas antes de culpar a hospedagem web.

O DNS é seguro por padrão? O que DNSSEC e DoH mudam?#

Não. O desenho original priorizou distribuição e desempenho, não autenticidade nem confidencialidade da consulta. As extensões DNSSEC acrescentam autenticação de origem e integridade dos dados DNS, com negação autenticada de existência, conforme a RFC 4033, de março de 2005. Em outras palavras, um resolvedor que valida pode rejeitar respostas que não batem com a cadeia de chaves da zona. No entanto, DNSSEC não cifra a pergunta, não impede negação de serviço e não torna um site confiável só porque o nome está assinado.

A confidencialidade da consulta segue outro caminho. O DNS over HTTPS, padronizado na RFC 8484 em outubro de 2018, transporta a pergunta e a resposta dentro de HTTPS, de modo que um observador na rede local tenha mais dificuldade de ler ou alterar o tráfego de resolução. O benefício vem com trade-offs. Você passa a confiar no operador do resolvedor DoH escolhido. Malware no próprio aparelho continua fora desse escudo, e sinais laterais da conexão web ainda existem. Relacionar isso à criptografia ajuda, porque DoH protege o canal da consulta, enquanto DNSSEC protege a autenticidade do dado publicado.

Como isso conversa com phishing e rede local#

Um ataque que envenena cache ou responde antes do servidor legítimo pode mandar você a um IP falso com página parecida com a do banco ou da loja. Isso se conecta diretamente a phishing, porque o engodo começa na resolução do nome, não só no texto do e-mail. Em Wi-Fi público, a combinação de consulta em claro e ausência de validação aumenta a superfície. Mesmo assim, HTTPS no site destino não substitui DNS íntegro, e DNS íntegro não substitui julgamento sobre o domínio que você está abrindo.

No Brasil, a administração do DNS da zona .br fica a cargo da estrutura do Registro.br no âmbito do NIC.br, que desde 1995 cuida do registro e da publicação dessa árvore nacional, conforme a página institucional do NIC.br sobre o Registro.br. Isso não elimina erro de configuração do titular do domínio. Só situa quem opera a camada de país na hierarquia.

Antes de confiar só no cadeado do navegador, eu olho se a resolução está caindo no destino esperado e se mudanças recentes de NS ou A ainda podem estar em cache. Para zona própria, avalio DNSSEC com processo de assinatura e renovação que a equipe consiga manter, porque assinatura expirada dói mais que zona sem assinatura.

Como o DNS se liga a nuvem, API, VPN e firewall?#

Em computação em nuvem, nomes curtos escondem balanceadores, certificados e IPs que mudam. Um CNAME para o hostname do provedor é comum, porém cada mudança mal propagada gera indisponibilidade percebida mesmo com a aplicação no ar. Serviços de API sofrem o mesmo efeito, porque clientes e webhooks resolvem o hostname antes de autenticar. Se o DNS apontar para o ambiente errado, você pode vazar tráfego de teste em produção ou o contrário.

Há também o encaixe com borda de rede. Regras de firewall e de VPN muitas vezes filtram por IP, enquanto humanos pensam em nomes. Quando o IP atrás do nome muda e a regra não acompanha, o sintoma parece VPN engasgada ou API bloqueada. Por isso times maduros documentam se a política depende de nome resolvido dinamicamente ou de endereço fixo, e aceitam o custo operacional dessa escolha.

Checklist rápido antes de mudar DNS em produção#

1. Liste o que depende do nome, incluindo site, correio, autenticação, webhooks e painéis.
2. Reduza TTL dos registros que vão mudar com antecedência suficiente para caches expirarem.
3. Publique os novos valores e valide no autoritativo, não só no resolvedor do seu notebook.
4. Monitore erro de conexão e de e-mail durante a janela de propagação.
5. Só então restabeleça TTL adequado ao ritmo real de mudança do serviço.

O atalho perigoso para quem publica serviço em nuvem é alterar NS, A e MX na mesma janela sem inventário. Eu faço uma mudança por classe de serviço sempre que o risco de receita ou de suporte for alto, porque rollback de DNS é simples no arquivo e lento na Internet cacheada.

Termos relacionados#

• phishing Golpes que desviam você a páginas falsas podem começar por resolução de nome adulterada ou por domínio parecido.
• criptografia DoH e DNSSEC usam mecanismos criptográficos com objetivos diferentes, canal versus autenticidade do dado.
• computação em nuvem Hostnames de nuvem mudam com frequência e tornam o DNS parte do desenho do serviço, não detalhe de painel.
• API Clientes de API resolvem o hostname antes de enviar credenciais, então erro de DNS aparece como falha de integração.
• firewall Políticas por IP precisam acompanhar mudanças de registro A ou AAAA para não bloquear o destino certo.
• VPN Tunelamento e resolução de nomes internos interagem. DNS errado dentro do túnel quebra acesso a sistemas corporativos.
• SaaS Ferramentas sob assinatura pedem CNAME, TXT ou NS específicos, e atraso de DNS atrasa a ativação do produto.

Perguntas frequentes sobre DNS#

Estas dúvidas concentram o que costuma sobrar depois do guia. Elas cobrem definição no cotidiano, tempo de propagação, relação com e-mail, papel do DNSSEC e o que fazer quando o site some só para alguns usuários. Use as respostas como critério, não como diagnóstico fechado do seu caso.

O que é DNS no cotidiano de quem só usa o navegador?#

É o passo invisível que transforma o nome digitado no endereço numérico do servidor. Sem resolução DNS bem-sucedida, a página nem começa a carregar. Você percebe a falha como erro de endereço, tempo esgotado ou destino inalcançável, embora a causa possa estar no resolvedor, no cache ou na zona do domínio.

Quanto tempo leva para uma mudança de DNS valer em todo lugar?#

Não há um relógio único. O TTL de cada registro limita quanto tempo caches podem reutilizar a resposta antiga, e resolvedores podem encurtar esse teto por política própria. Por isso uma troca de A pode parecer instantânea num dispositivo e demorar noutras redes. Planeje a janela olhando o TTL publicado antes da mudança, não um prazo mágico de marketing.

DNS errado derruba e-mail mesmo com site no ar?#

Sim, porque correio depende sobretudo de MX e de TXT de autenticação, enquanto o site depende de A, AAAA ou CNAME. É comum o HTTP funcionar e a caixa falhar depois de uma limpeza apressada na zona. Antes de apagar registros que parecem lixo, exporte a zona e confira com o provedor de e-mail quais entradas ainda são obrigatórias.

DNSSEC deixa meu site imune a golpe?#

Não. DNSSEC ajuda o resolvedor validador a detectar dados DNS forjados na resolução da zona assinada. Ele não impede domínio parecido registrado por terceiros, não remove malware do seu computador e não substitui hábitos seguros de login. Trate-o como camada de integridade do sistema de nomes de domínio, não como antivírus.

Por que o site abre na minha casa e não na do cliente?#

Porque cada rede pode usar servidor DNS e caches diferentes. Uma rede ainda serve IP antigo, outra já pegou o novo, e uma terceira pode ter filtro ou falha no recursivo. Compare respostas a partir de redes distintas e, se possível, consulte o autoritativo. Só depois discuta hospedagem ou firewall no destino.

Preciso de DoH no celular para estar seguro?#

DoH reduz exposição da consulta em redes hostis, porém desloca confiança para o resolvedor escolhido e não cobre todas as formas de rastreio. Em empresa, a política de DNS pode exigir resolvedor interno para acessar nomes privados. Avalie o ambiente. Em Wi-Fi público o ganho de privacidade da consulta é mais evidente. Em rede gerida, o conflito de política também é.

Conclusão#

Para a maioria das pessoas que publicam ou mantêm presença online, o DNS deve ser tratado como infraestrutura crítica, não como tela secundária do painel. Domínio sem zona coerente é vitrine com endereço trocado. Comece inventariando site, e-mail e integrações, documente os registros DNS que cada um exige e mude com TTL planejado.

A resposta muda quando você opera resolvedor próprio, zona com alto volume ou requisito forte de autenticidade. Aí entram separação entre recursivo e autoritativo, monitoramento e, quando houver processo sustentável, validação com DNSSEC. O primeiro passo continua modesto. Abra a zona atual, anote o que cada registro sustenta e só então edite.

Este texto sobre DNS (sistema de nomes de domínio) é informativo e geral. Não substitui diagnóstico de rede, hardening feito por profissional nem orientação jurídica sobre incidentes, dados pessoais ou abuso. Ferramentas, resolvedores e painéis mudam com o tempo. Confira a configuração e as políticas vigentes na data em que for agir, e trate segurança como processo com custo de manutenção, não como ajuste único.