DNS por dentro: como um nome vira um endereço, e por que o seu e-mail depende disso

Toda vez que alguém digita o endereço do site da sua empresa, abre o aplicativo do banco ou envia um e-mail, uma pergunta silenciosa acontece antes de qualquer outra coisa: onde fica esse nome? Computadores conversam por endereços numéricos, e pessoas lembram de nomes. Quem faz a ponte entre os dois, bilhões de vezes por dia, é o DNS, o sistema de nomes de domínio.

O DNS é tão confiável que fica invisível, e por isso pega muita gente de surpresa quando falha. Um registro apagado tira um site do ar; um TTL longo demais faz uma migração demorar um dia inteiro; um registro de e-mail mal escrito manda as notas fiscais da empresa para a caixa de spam dos clientes. Entre administradores de sistemas, existe até uma piada recorrente para incidentes misteriosos: "é sempre o DNS".

Este artigo é uma imersão no DNS, de dentro para fora: a hierarquia de nomes, o caminho de uma consulta e o formato das mensagens, os tipos de registro e o arquivo de zona, o cache, o uso do DNS para distribuir tráfego, o papel dele na entrega de e-mails, a segurança e as ferramentas para investigar problemas, com um diagnóstico passo a passo e uma seção de perguntas frequentes. No fim, os cuidados que seguimos na Gothor.

O que é o DNS

O DNS (Domain Name System) é um banco de dados distribuído e hierárquico que associa nomes a informações. A mais conhecida é o endereço IP: o nome www.exemplo.com.br aponta para um endereço como 203.0.113.10 (no IPv4) ou 2001:db8::10 (no IPv6). Mas o DNS guarda muito mais: quais servidores recebem os e-mails de um domínio, quais servidores podem enviar em nome dele, chaves públicas de assinatura, provas de propriedade para serviços de terceiros e regras sobre quem pode emitir certificados.

Três características explicam por que ele funciona em escala planetária:

• Distribuído. Nenhum servidor sabe tudo. Cada organização mantém os dados do próprio domínio, e o sistema sabe a quem perguntar.
• Hierárquico. Os nomes formam uma árvore, e a responsabilidade por cada galho pode ser delegada a outra pessoa.
• Com cache em todo lugar. Cada resposta vem com um prazo de validade, e quem a recebe pode guardá-la até esse prazo vencer. A maioria das consultas nunca chega aos servidores de origem.

As consultas usam normalmente o protocolo UDP na porta 53, rápido e sem conexão. Respostas grandes e transferências de zona entre servidores usam TCP, também na porta 53, e versões cifradas do protocolo usam outras portas, como veremos.

Por dentro de uma mensagem DNS

Pergunta e resposta usam o mesmo formato, definido em 1987 e praticamente intacto até hoje. Uma mensagem tem um cabeçalho fixo de 12 bytes e quatro seções:

O identificador casa a resposta com a pergunta, já que o UDP não tem conexão. Entre os indicadores, os mais úteis no dia a dia são: qr (é uma resposta), rd (o cliente pediu recursão), ra (o servidor oferece recursão), aa (a resposta vem de um servidor autoritativo, e não de um cache), tc (a resposta foi truncada e deve ser repetida por TCP) e ad (os dados foram validados com DNSSEC).

O código de resposta diz como a consulta terminou, e saber lê-lo resolve metade dos diagnósticos:

Um código de resposta, porém, diz pouco: um SERVFAIL pode significar um servidor fora do ar, uma assinatura vencida ou um domínio bloqueado por política. Os erros estendidos (Extended DNS Errors), da RFC 8914, de 2020, acrescentam à resposta um código numérico e, opcionalmente, um texto com o motivo. Alguns dos códigos definidos: 3, resposta vencida servida do cache; 6, falha na validação DNSSEC; 7, assinaturas vencidas; 9, a zona de cima tem um DS, mas não há chave correspondente na zona; 15, domínio bloqueado pela política de segurança do operador do resolvedor; 17, bloqueado a pedido do próprio cliente; 22, nenhum servidor autoritativo alcançável. A RFC deixa claro que o erro estendido não muda o significado do código de resposta, só o explica. Quando o resolvedor o envia, ele encurta muito o diagnóstico de um SERVFAIL.

Originalmente, uma resposta por UDP tinha no máximo 512 bytes. A extensão EDNS(0) permitiu ao cliente anunciar que aceita mensagens maiores, necessárias para DNSSEC e para registros TXT longos. Hoje, os grandes resolvedores e servidores combinaram um tamanho prudente, por volta de 1.232 bytes, para evitar a fragmentação de pacotes no caminho; o que passa disso volta truncado e é repetido por TCP. Um firewall que bloqueia a porta 53 em TCP, por isso, quebra exatamente as respostas grandes, e costuma ser difícil de diagnosticar.

Uma história curta

No começo da ARPANET, a rede que deu origem à internet, a lista de nomes e endereços era um único arquivo de texto, o HOSTS.TXT, mantido pelo centro de informações da rede, no SRI, na Califórnia, e copiado periodicamente por todos os computadores da rede. Com algumas centenas de máquinas, funcionava. Com milhares, virou um gargalo: cada mudança dependia de uma pessoa, o arquivo crescia sem parar e os nomes começavam a colidir. Um descendente direto desse arquivo existe até hoje em todo computador: o arquivo hosts (/etc/hosts no Linux e no macOS, C:\Windows\System32\drivers\etc\hosts no Windows), consultado antes do DNS.

Em 1983, Paul Mockapetris propôs o DNS nas RFCs 882 e 883, com a hierarquia, a delegação e o cache que existem até hoje. Em 1987, as RFCs 1034 e 1035 consolidaram o protocolo, e elas continuam sendo a base da especificação, complementadas por dezenas de documentos posteriores. Na mesma década surgiu o BIND, em Berkeley, que por muitos anos foi praticamente sinônimo de servidor DNS.

O domínio .br foi delegado ao Brasil em 1989. Hoje ele é administrado pelo Registro.br, o departamento do NIC.br responsável pelo registro de nomes sob .br. Em 1998 foi criada a ICANN, que coordena a raiz do DNS e a política dos domínios de topo.

A década de 2000 trouxe as preocupações de segurança. Em 2008, o pesquisador Dan Kaminsky revelou uma forma eficiente de envenenar o cache de resolvedores, o que levou a correções urgentes em todo o mundo e acelerou a adoção do DNSSEC, que adiciona assinaturas digitais às respostas; a raiz do DNS foi assinada em 2010, e o .br esteve entre os primeiros domínios de topo de país a adotar a tecnologia. Na década seguinte vieram os protocolos que cifram as consultas, o DNS sobre TLS (2016) e o DNS sobre HTTPS (2018), para que quem está no caminho não veja quais sites cada pessoa visita.

O espaço de nomes também cresceu. Os nomes com acentos e outros alfabetos, os domínios internacionalizados, são convertidos para um formato só com letras simples chamado punycode: um nome como açaí.com.br viaja pelo DNS como uma sequência que começa com xn--. O Registro.br aceita nomes com acentos e cedilha. E, a partir de 2012, um programa da ICANN abriu a criação de novos domínios de topo genéricos, e a raiz passou de algumas dezenas para mais de mil, com nomes como .app, .shop e .rio.

A hierarquia: da raiz até o seu domínio

Um nome de domínio é lido da direita para a esquerda, do mais geral para o mais específico. Em www.exemplo.com.br., o ponto final, quase sempre omitido, representa a raiz. Depois vêm o domínio de topo br, o domínio de segundo nível com.br, o domínio exemplo.com.br e, por fim, o nome www dentro dele.

Cada parte entre pontos é um rótulo, com até 63 caracteres, e o nome inteiro tem até 253. Letras maiúsculas e minúsculas são equivalentes: Gothor.com.br e gothor.com.br são o mesmo nome. Os domínios de topo se dividem em genéricos (.com, .org, .net e os novos) e de país, com duas letras (.br, .pt, .ar). Sob o .br, o Registro.br mantém categorias de segundo nível, como com.br, org.br, net.br, gov.br, edu.br e várias de profissões, como adv.br e eng.br.

Zonas e delegação

A árvore é dividida em zonas, e cada zona é responsabilidade de um conjunto de servidores autoritativos, os que dão a resposta oficial para os nomes dela. A zona da raiz não sabe o endereço de www.exemplo.com.br; ela só sabe quem responde por br. A zona de br sabe quem responde por exemplo.com.br. E os servidores de exemplo.com.br sabem, finalmente, o endereço de www. Esse "quem responde por" é a delegação, feita com registros do tipo NS.

É a delegação que permite a uma empresa trocar de provedor de DNS sem pedir nada a ninguém além do registro do domínio: basta apontar os registros NS para os servidores do novo provedor.

O ovo e a galinha: registros de cola

A delegação esconde um problema circular. Se os servidores de exemplo.com.br se chamam ns1.exemplo.com.br e ns2.exemplo.com.br, como descobrir o endereço de ns1 sem antes perguntar ao próprio ns1? A solução são os registros de cola (glue records): a zona de cima, além dos NS, publica os endereços desses servidores, e os entrega na seção adicional da referência. Por isso, quando o servidor de nomes fica dentro do próprio domínio, o registrador pede o endereço IP junto com o nome. Quando os servidores ficam em outro domínio, como os de um provedor de DNS, a cola não é necessária, porque o endereço deles é descoberto por outro caminho da árvore.

A raiz

A raiz é servida por 13 identidades de servidor, de a.root-servers.net a m.root-servers.net, operadas por 12 organizações. Isso não significa 13 máquinas: graças ao anycast, em que o mesmo endereço é anunciado a partir de muitos lugares, cada identidade é atendida por dezenas ou centenas de instâncias espalhadas pelo mundo, mais de mil no total. A consulta chega à instância mais próxima pela rede.

Os resolvedores conhecem a raiz por um arquivo de dicas (root hints), embutido no software, com os nomes e endereços das 13 identidades. Ao iniciar, eles perguntam a uma delas a lista atual e passam a usá-la. É o único ponto da árvore que não é descoberto por delegação.

Registro, registrador e DNS: três papéis diferentes

Uma confusão comum é misturar três coisas:

• O registro é quem administra o domínio de topo. Para .br, o Registro.br.
• O registrador é onde se contrata e renova o domínio. No caso de .br, o próprio Registro.br atende diretamente, além de provedores credenciados.
• O provedor de DNS é quem hospeda a zona, ou seja, os servidores autoritativos com os registros do domínio. Pode ser o próprio registrador, a empresa de hospedagem ou um serviço especializado.

Na prática, contratar o domínio num lugar e hospedar o DNS em outro é comum e saudável. O que liga os dois são os registros NS configurados no registrador.

O caminho de uma consulta

Quando o navegador precisa do endereço de www.exemplo.com.br, a pergunta percorre uma cadeia de caches e servidores. Na maioria das vezes, ela é respondida logo no começo; o caminho completo só acontece quando ninguém tem a resposta guardada.

1. O navegador e o sistema operacional consultam primeiro os próprios caches e o arquivo hosts. O componente do sistema que faz consultas é o stub resolver, um cliente simples que delega o trabalho pesado.
2. O resolvedor recursivo recebe a pergunta. Pode ser o do provedor de internet, o da rede da empresa ou um público, como os da Cloudflare (1.1.1.1), do Google (8.8.8.8) ou da Quad9 (9.9.9.9). Ele também tem cache, compartilhado por todos os seus usuários.
3. A raiz responde ao recursivo com uma referência: "não sei, mas os servidores de br são estes".
4. **Os servidores de .br** respondem com outra referência: "os servidores de exemplo.com.br são estes".
5. O servidor autoritativo de exemplo.com.br dá a resposta final, com o endereço e o TTL.
6. O recursivo guarda a resposta no cache e a devolve ao sistema operacional, que a entrega ao navegador.

Os passos 3, 4 e 5 são consultas iterativas: cada servidor responde o que sabe, e o recursivo segue as referências. Já a consulta do passo 2 é recursiva: o cliente pede a resposta final e espera. Os resolvedores também guardam as referências, então, depois da primeira consulta a qualquer .com.br, eles não precisam voltar à raiz por um bom tempo.

Dá para ver esse caminho com a ferramenta dig, disponível no Linux, no macOS e no Windows pelo WSL. A saída abaixo foi resumida, e os endereços e servidores são ilustrativos:

$ dig +trace www.exemplo.com.br

.                  518400  IN  NS  a.root-servers.net.
br.                172800  IN  NS  a.dns.br.
exemplo.com.br.     86400  IN  NS  ns1.provedor-dns.exemplo.
www.exemplo.com.br.   300  IN  A   203.0.113.10

Cada linha traz o nome, o TTL em segundos, a classe (IN, de internet), o tipo e o valor. No Windows, o PowerShell oferece o equivalente com Resolve-DnsName www.exemplo.com.br.

Por dentro do resolvedor recursivo

O resolvedor recursivo é a peça que mais trabalha, e os bons fazem bem mais do que seguir referências:

• Escolha do servidor mais rápido. Uma zona tem vários servidores autoritativos. O resolvedor mede o tempo de resposta de cada um e passa a preferir os mais rápidos, sem abandonar os outros, para notar quando um deles melhora.
• Minimização da pergunta. No desenho original, o resolvedor mandava o nome completo (www.exemplo.com.br) à raiz e ao .br, que não precisavam dele. Com a minimização (QNAME minimisation), ele pergunta à raiz só por br, ao .br só por exemplo.com.br, e o nome completo só chega a quem precisa responder. É uma melhoria de privacidade adotada pelos principais resolvedores.
• Renovação antecipada. Para nomes muito consultados, o resolvedor renova a resposta pouco antes do TTL vencer, e ninguém espera pela consulta completa.
• Respostas vencidas como reserva. Se os servidores autoritativos de um domínio ficam fora do ar, alguns resolvedores entregam a última resposta conhecida, mesmo vencida, por um tempo limitado (serve-stale). Um TTL longo, por isso, também é uma proteção contra falhas do provedor.
• Validação. Resolvedores que validam DNSSEC conferem as assinaturas e recusam respostas adulteradas, como veremos na seção de segurança.

Qual resolvedor usar

Não há escolha certa para todos. Uma rede de lojas pode usar um resolvedor público com filtro de domínios maliciosos, como o da Quad9, nos caixas e um resolvedor interno no escritório, onde existem nomes que só fazem sentido dentro da rede.

Os tipos de registro

Uma zona é uma lista de registros de recurso. Cada um tem nome, tipo, TTL e valor. Os tipos mais usados cobrem desde o endereço do site até as regras de e-mail.

Alguns detalhes que costumam causar problemas:

• CNAME não convive com outros registros no mesmo nome. Por isso ele não pode ficar no apex (o domínio "puro", exemplo.com.br), que obrigatoriamente tem NS e SOA. Vários provedores oferecem soluções próprias, chamadas de CNAME flattening ou registros ALIAS, que resolvem o apelido no servidor e respondem com o endereço final.
• MX aponta para um nome, nunca para um IP, e esse nome precisa ter registro A ou AAAA. O número antes do nome é a prioridade: quanto menor, mais preferido.
• TXT é o canivete suíço. SPF, DMARC, chaves DKIM e verificações de propriedade de serviços como Google, Microsoft e Meta moram em registros TXT.
• O PTR não fica na zona do seu domínio. O DNS reverso de um endereço IP é responsabilidade de quem controla o bloco de endereços, normalmente a empresa de hospedagem, e é configurado no painel dela.
• Subdomínios são nomes como quaisquer outros. loja.exemplo.com.br pode ter os próprios registros na mesma zona ou ser delegado a outros servidores com registros NS.
• O curinga não cobre tudo. Um registro *.exemplo.com.br responde por qualquer nome que não exista na zona, mas não por nomes que existem com outros tipos de registro, nem pelo próprio apex.

Os registros HTTPS e SVCB

Durante décadas, o DNS só dizia onde ficava um site, e o navegador descobria como falar com ele na própria conexão: tentava HTTP, era redirecionado para HTTPS, descobria depois que o servidor aceitava HTTP/3. Os registros SVCB e HTTPS, padronizados na RFC 9460, de 2023, levam essas informações para a própria resposta do DNS, e o navegador já chega sabendo o caminho.

Cada registro tem uma prioridade, um nome de destino e uma lista de parâmetros. A prioridade 0 indica o modo apelido (AliasMode), que aponta o nome para outro, e a RFC diz que o propósito principal desse modo é permitir apelidos no apex, onde o CNAME é proibido; é a solução padronizada para o problema que os provedores resolvem hoje com o CNAME flattening. As outras prioridades indicam o modo serviço, com parâmetros como alpn (os protocolos aceitos, como h3 para HTTP/3 e h2 para HTTP/2), port (uma porta diferente da padrão) e ipv4hint e ipv6hint (endereços que o cliente pode usar enquanto espera os registros A e AAAA):

exemplo.com.br.      3600  IN  HTTPS  1 . alpn="h3,h2" ipv4hint=203.0.113.10
loja.exemplo.com.br. 3600  IN  HTTPS  0 loja.plataforma.exemplo.

Há um efeito de segurança: a RFC estabelece que um registro HTTPS orienta o cliente a falar com aquele nome só por um transporte seguro, de forma parecida com o HSTS, o cabeçalho que obriga o navegador a usar HTTPS. Um nome que publica o registro deixa de ser acessado primeiro por HTTP em texto aberto. A RFC também reserva nesse registro um parâmetro para o Encrypted ClientHello, a extensão do TLS feita para esconder de quem observa a rede o nome do site que a pessoa está abrindo.

CAA e a validação de certificados pelo DNS

O registro CAA, hoje definido na RFC 8659, de 2019, diz quais autoridades certificadoras podem emitir certificados para o domínio. Antes de emitir, a autoridade é obrigada a procurar esse registro e só pode emitir se estiver na lista. A busca sobe pela árvore: para loja.exemplo.com.br, ela procura no próprio nome e, se não achar, em exemplo.com.br, e assim por diante, parando antes da raiz; o primeiro conjunto CAA encontrado decide. Por isso, um único registro no domínio principal protege todos os subdomínios que não tenham o seu.

Três etiquetas fazem o trabalho. A issue lista as autoridades permitidas, e um valor vazio (";") proíbe todas. A issuewild vale só para certificados curinga (*.exemplo.com.br) e, quando existe, tem prioridade sobre a issue nesses pedidos. A iodef dá um endereço para receber avisos de pedidos que violaram a política. O CAA não é verificado pelos navegadores: ele protege o momento da emissão, e não o uso do certificado depois.

O DNS também é usado para provar que alguém controla o domínio. No protocolo ACME, da RFC 8555, usado pela Let's Encrypt e por outras autoridades, o desafio dns-01 pede que o cliente publique um registro TXT em _acme-challenge seguido do nome a validar, com um valor derivado de um código aleatório e da chave da conta. Segundo a documentação da Let's Encrypt, é o desafio que permite emitir certificados curinga e validar domínios cujos servidores web não são acessíveis pela internet. A contrapartida, que a mesma documentação aponta, é que o processo de renovação precisa de uma credencial da API do provedor de DNS, e guardá-la no servidor web é arriscado: quem a obtém pode alterar a zona inteira. Essa credencial merece o mesmo cuidado que a senha do registrador, de preferência limitada aos registros _acme-challenge, quando o provedor permite.

Uma zona completa, linha a linha

Os painéis dos provedores escondem o formato, mas por baixo uma zona é um arquivo de texto com uma sintaxe de 1987. Ver uma inteira ajuda a entender o que cada campo do painel significa:

$ORIGIN exemplo.com.br.
$TTL 3600
@     IN  SOA  ns1.provedor-dns.exemplo. hostmaster.exemplo.com.br. (
               2026103001 ; número de série
               7200       ; refresh: secundários conferem a cada 2 h
               900        ; retry: se falhar, tentam de novo em 15 min
               1209600    ; expire: sem contato por 14 dias, param de responder
               300 )      ; TTL das respostas negativas
@     IN  NS     ns1.provedor-dns.exemplo.
@     IN  NS     ns2.provedor-dns.exemplo.
@     IN  A      203.0.113.10
@     IN  AAAA   2001:db8::10
www   IN  CNAME  exemplo.com.br.
@     IN  MX     10 mail.exemplo.com.br.
mail  IN  A      203.0.113.20
@     IN  TXT    "v=spf1 mx -all"
@     IN  CAA    0 issue "letsencrypt.org"

O $ORIGIN diz qual domínio completa os nomes relativos, e o @ representa o próprio domínio. O $TTL é o prazo padrão de quem não declara o seu. O ponto final em exemplo.com.br. não é enfeite: sem ele, o nome seria completado com a origem e viraria exemplo.com.br.exemplo.com.br, um erro clássico de quem edita zonas à mão.

O registro SOA (start of authority) abre toda zona. O segundo nome é o e-mail do responsável, com o primeiro ponto no lugar do @. O número de série é a versão da zona, e por convenção segue o formato ano, mês, dia e um contador (2026103001). Os outros campos controlam a sincronização entre servidores, e o último define por quanto tempo uma resposta "este nome não existe" fica em cache.

Primários, secundários e redundância

Uma zona deve ter pelo menos dois servidores autoritativos, de preferência em redes diferentes, para que a queda de um não tire o domínio do ar. Num desenho clássico, um servidor é o primário, onde a zona é editada, e os outros são secundários, que copiam a zona dele. Quando a zona muda, o primário avisa os secundários (uma mensagem NOTIFY); eles comparam o número de série e, se for maior, baixam a zona inteira (AXFR) ou só as diferenças (IXFR). Se o aviso se perder, os secundários conferem sozinhos a cada intervalo de refresh.

Por isso o número de série precisa sempre aumentar: uma mudança com o mesmo número fica só no primário, e metade das consultas recebe a versão antiga. Os provedores de DNS gerenciados cuidam disso automaticamente, e servem cada zona a partir de dezenas de pontos com anycast, que é uma das razões para usá-los.

Cache e TTL: por que "propagar" leva tempo

Cada registro tem um TTL (time to live), em segundos: o tempo que um resolvedor pode guardar a resposta antes de perguntar de novo. É o mecanismo que permite ao DNS aguentar a carga da internet inteira, e também a origem da maioria dos mal-entendidos.

O mito da propagação

Quando um registro muda, nada é "propagado" ativamente. Os servidores autoritativos passam a responder o valor novo na hora. O que acontece é que caches espalhados pelo mundo ainda guardam o valor antigo até o TTL deles vencer. Se o TTL era de 86.400 segundos (um dia), um resolvedor que consultou o nome um minuto antes da mudança pode continuar entregando o endereço velho por quase 24 horas. Por isso, a mesma mudança "já funciona" para uma pessoa e "ainda não" para outra.

Dá para ver o cache trabalhando: ao repetir a mesma consulta num resolvedor, o TTL da resposta diminui a cada vez, porque ele mostra quanto tempo ainda resta antes de o resolvedor perguntar de novo.

Como planejar uma mudança

A regra é reduzir o TTL antes da mudança, com antecedência de pelo menos um TTL antigo:

1. Dias antes, baixe o TTL do registro que vai mudar para um valor curto, como 300 segundos.
2. Espere passar o TTL antigo inteiro, para que todos os caches já tenham o valor com TTL curto.
3. Faça a mudança. Em poucos minutos, os caches renovam e passam a usar o valor novo.
4. Mantenha o servidor antigo funcionando por um tempo, para os retardatários.
5. Com tudo estável, volte o TTL para um valor maior.

A troca de provedor de DNS, em que os registros NS mudam, segue a mesma lógica, com um detalhe: o TTL dos NS na zona do .br é definido pelo registro, e não por você, e costuma ser de horas. Durante esse tempo, parte dos resolvedores pergunta ao provedor antigo e parte ao novo. A migração segura é criar a zona completa no provedor novo, conferir registro por registro com dig apontando para os servidores novos, trocar os NS no registrador e só desligar a zona antiga dias depois.

Quanto usar

Não existe valor certo para todos. TTLs longos (horas ou um dia) reduzem consultas e deixam o domínio mais resistente a falhas momentâneas do provedor de DNS; TTLs curtos (minutos) permitem mudanças e failover rápidos. Registros que quase nunca mudam, como NS e MX, costumam ter TTLs maiores; registros de serviços que podem trocar de endereço, menores. Muitos provedores usam por padrão 300 segundos, um meio-termo razoável.

O cache negativo

Respostas negativas também ficam em cache. Se alguém consultou um nome antes de ele existir, a resposta "não existe" (NXDOMAIN) é guardada pelo tempo definido no registro SOA da zona. É por isso que um subdomínio recém-criado às vezes demora a aparecer justamente para quem testou cedo demais.

Os caches do seu próprio computador

Antes do resolvedor, há caches no próprio aparelho, e eles explicam muitos "no meu computador ainda não mudou". O navegador mantém um cache próprio; o Chrome limpa o dele na página interna chrome://net-internals/#dns. O sistema operacional mantém outro: no Windows, ipconfig /displaydns lista o conteúdo e ipconfig /flushdns o apaga. Limpar esses caches só resolve o lado do seu aparelho; o cache do resolvedor do provedor continua valendo até o TTL vencer, e não há como apagar os caches do mundo.

Nomes internos: o DNS dentro da empresa

Toda empresa com uma rede própria acaba tendo nomes que só fazem sentido lá dentro: o servidor de arquivos, a impressora do financeiro, o sistema que só roda no escritório. Por muito tempo, a prática comum foi inventar um domínio de topo para isso, como .empresa, .lan ou .corp, servido pelo resolvedor interno. O problema é que um nome inventado hoje pode existir amanhã: o programa de novos domínios de topo da ICANN mostrou que a raiz pode crescer, e um sufixo que não existia passou a ter dono. Além disso, quando um notebook sai da rede da empresa, as consultas por esses nomes vazam para os resolvedores públicos e chegam à raiz, revelando a quem observa o nome dos sistemas internos.

Há três saídas corretas. A primeira é usar um subdomínio de um domínio que a empresa já possui, como interno.exemplo.com.br, servido só pelo resolvedor interno; é a mais robusta, porque o nome é da empresa e pode até receber certificados válidos pelo desafio dns-01. A segunda é o **.internal**: em 29 de julho de 2024, o conselho da ICANN reservou esse domínio de topo de forma permanente, para que nunca seja delegado na raiz, justamente para uso privado. A terceira, para redes domésticas, é o home.arpa, reservado pela RFC 8375, de 2018, que trocou o .home usado antes porque as consultas a ele vazavam para os servidores da raiz.

Um nome que não deve ser usado para o DNS interno é o .local. Pela RFC 6762, de 2013, todo nome terminado em .local é tratado como local ao segmento de rede e consultado por multicast DNS, o mecanismo com que impressoras e aparelhos se anunciam sem servidor nenhum. Uma rede que usa .local no resolvedor da empresa entra em conflito com esse mecanismo, e os sintomas são lentidão e nomes que resolvem num computador e não no outro.

Quando o mesmo nome precisa responder coisas diferentes dentro e fora da empresa, por exemplo o endereço interno de um sistema para quem está no escritório e o endereço público para quem está fora, usa-se o DNS de horizonte dividido (split-horizon): o resolvedor interno responde uma zona, e os servidores autoritativos públicos, outra. Funciona bem, mas exige disciplina, porque as duas versões precisam ser mantidas juntas; uma mudança feita só na zona pública é a origem clássica de "fora do escritório funciona, dentro não".

DNS além do endereço: distribuição de tráfego

Como toda conexão começa com uma consulta, o DNS virou também uma ferramenta para decidir para onde cada pessoa vai:

• Vários endereços no mesmo nome. Um nome pode ter vários registros A. O servidor alterna a ordem a cada resposta (o round robin), e os clientes tendem a usar o primeiro, o que espalha a carga entre servidores. É simples, mas não sabe se um servidor caiu.
• Failover com verificação de saúde. Provedores de DNS gerenciado testam os servidores periodicamente e tiram da resposta o endereço que parou de responder. O tempo da troca depende do TTL, por isso esses registros usam TTLs de segundos a poucos minutos.
• Respostas por região. O servidor autoritativo responde endereços diferentes conforme a origem da consulta, mandando cada pessoa ao servidor mais próximo. Como quem pergunta ao autoritativo é o resolvedor, e não a pessoa, existe uma extensão (EDNS Client Subnet) pela qual o resolvedor informa parte do endereço do cliente.
• CDNs e proxies. Num serviço de entrega de conteúdo, o DNS do seu domínio responde com os endereços da rede do serviço, e não do seu servidor. A pessoa conecta ao ponto mais próximo da rede, que entrega o conteúdo em cache ou busca no seu servidor. É o que acontece no modo com proxy de provedores como a Cloudflare.

O IPv6 acrescenta uma decisão a mais. Quando um nome tem registros A e AAAA, o cliente tenta os dois quase ao mesmo tempo, com uma pequena vantagem para o IPv6, e fica com o que conectar primeiro (o algoritmo Happy Eyeballs). Se o IPv6 do servidor recusa a conexão na hora, o cliente cai para o IPv4 sem a pessoa perceber; se ele aceita a conexão e entrega o serviço errado, a pessoa vê o erro.

DNS e e-mail: SPF, DKIM e DMARC

O protocolo de e-mail, o SMTP, foi criado numa época de confiança: qualquer servidor pode enviar uma mensagem dizendo ser de qualquer remetente. Para combater a falsificação, três mecanismos foram construídos sobre o DNS. Juntos, eles respondem à pergunta que todo provedor de e-mail faz ao receber uma mensagem: este e-mail veio mesmo de quem diz ser?

MX: para onde vai

Antes da autenticação, o básico: o registro MX diz quais servidores recebem os e-mails do domínio. Sem ele, ninguém consegue enviar mensagens para os seus endereços. Com vários MX, o servidor remetente tenta primeiro o de menor prioridade e, se ele não responder, o seguinte; como o SMTP guarda a mensagem e tenta de novo por horas ou dias, uma queda curta do servidor de e-mail não perde mensagens.

SPF: quem pode enviar

O SPF (Sender Policy Framework) é um registro TXT no domínio que lista os servidores autorizados a enviar e-mails em nome dele:

exemplo.com.br.  TXT  "v=spf1 mx ip4:203.0.113.10 include:_spf.servico-de-envio.exemplo -all"

O servidor de destino compara o IP de quem está entregando a mensagem com essa lista. O final define o que fazer com quem não está nela: -all pede que a mensagem falhe; ~all pede uma falha "suave", em geral tratada como suspeita. Dois cuidados: o SPF aceita no máximo dez consultas a outros nomes (cada include, a ou mx conta), e cada domínio deve ter um único registro SPF.

Há uma limitação importante: o SPF verifica o domínio do envelope da mensagem (o remetente técnico, usado para devoluções), e não o endereço que aparece no campo "De:" para a pessoa. Um golpista pode usar o envelope de um domínio dele, passar no SPF e ainda assim exibir o seu domínio no "De:". Quem fecha essa brecha é o DMARC.

DKIM: a assinatura

O DKIM (DomainKeys Identified Mail) assina cada mensagem com uma chave privada que fica no servidor de envio. A chave pública correspondente é publicada no DNS, num nome formado por um seletor e por _domainkey:

mail._domainkey.exemplo.com.br.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

O servidor de destino lê o seletor no cabeçalho da mensagem, busca a chave no DNS e confere a assinatura. Se a mensagem foi alterada no caminho, ou se não foi assinada por quem tem a chave, a verificação falha. Diferente do SPF, a assinatura sobrevive a encaminhamentos.

O seletor é o que permite trocar de chave sem interromper nada: publica-se a chave nova num seletor novo, o servidor passa a assinar com ela e a antiga fica no DNS por alguns dias, até chegarem as mensagens que estavam em trânsito. Também permite que cada serviço que envia em nome do domínio (o servidor próprio, a plataforma de marketing, o sistema de cobrança) tenha a sua chave. Ao migrar o servidor de e-mail de máquina, levar a chave privada junto mantém válido o registro publicado.

DMARC: a política e o alinhamento

O DMARC é um registro TXT em _dmarc que faz duas coisas. Primeiro, exige alinhamento: para passar, o domínio que passou no SPF ou no DKIM precisa ser o mesmo (ou do mesmo domínio organizacional, no modo relaxado) que aparece no "De:". Segundo, diz ao destinatário o que fazer quando a verificação falha:

_dmarc.exemplo.com.br.  TXT  "v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:dmarc@exemplo.com.br"

O campo rua indica para onde os provedores mandam relatórios agregados, com o volume de mensagens que passaram e falharam e de quais servidores elas vieram. O caminho recomendado é começar com p=none, ler os relatórios até ter certeza de que todos os sistemas legítimos passam, e então subir para quarantine e, por fim, reject. Outras etiquetas completam o registro: sp= define uma política diferente para os subdomínios, e np=, uma política para os subdomínios que nem existem, nomes que só um golpista usaria. A etiqueta pct=, que aplicava a política a só uma porcentagem das mensagens, foi removida na revisão do DMARC de 2026, como veremos a seguir.

O DMARC revisado: a RFC 9989

O DMARC nasceu fora do processo de padronização: a RFC 7489, de 2015, foi publicada como documento informativo, por um caminho independente do grupo de trabalho do IETF. Em maio de 2026, o protocolo ganhou uma versão revisada, a RFC 9989, desta vez como padrão do IETF, que torna obsoletas a RFC 7489 e a RFC 9091. Os relatórios agregados e os de falha passaram para documentos próprios, as RFCs 9990 e 9991.

Para quem administra um domínio, quatro mudanças importam. A primeira é o fim do pct=. A experiência mostrou que os provedores só aplicavam com precisão os valores 0 e 100, e que o pct=0 tinha ganhado um uso próprio: sinalizar a intermediários, como listas de discussão, que reescrevessem o remetente das mensagens. A revisão manteve essa função com um nome mais honesto, a etiqueta t= (de testing), com os valores y e n, equivalentes ao antigo 0 e 100. Como a RFC manda ignorar etiquetas desconhecidas, um pct= esquecido no registro é simplesmente desconsiderado por quem segue a versão nova; quem usava pct=0 para testar deve trocá-lo por t=y.

A segunda é a forma de descobrir o domínio organizacional, aquele que define o alinhamento relaxado: em vez de depender de uma lista pública de sufixos mantida fora do DNS, a RFC 9989 define uma busca subindo pela própria árvore de nomes, a "caminhada pela árvore do DNS". A terceira são as etiquetas novas: np=, para subdomínios inexistentes, e psd=, que marca os domínios que funcionam como sufixos públicos.

A quarta é um aviso mais explícito sobre o p=reject. A RFC lembra que encaminhadores, apelidos de função (como um "financeiro@" que repassa para uma pessoa) e listas de discussão costumam quebrar o SPF, e que só a assinatura DKIM sobrevive a esses caminhos; por isso, quem publica reject precisa assinar tudo com DKIM, e não confiar só no SPF. E, para domínios cujos usuários escrevem para listas de discussão, a recomendação passou a ser não publicar reject, ou chegar lá com cuidado: pelo menos um mês em p=none, outro tanto em quarantine, comparando os relatórios. Para um domínio que só envia notas, boletos e avisos de sistemas, o reject continua sendo o objetivo; para o domínio que a equipe usa no dia a dia, a decisão merece mais calma.

Como ler um relatório DMARC

Os relatórios agregados chegam uma vez por dia, de cada grande provedor, como um arquivo XML compactado anexado a um e-mail. Cada bloco do relatório diz, para um endereço IP de origem, quantas mensagens chegaram e qual foi o resultado:

<record>
  <row>
    <source_ip>198.51.100.25</source_ip>
    <count>48</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>exemplo.com.br</header_from></identifiers>
</record>

A leitura útil é sempre a mesma: de quais IPs saem mensagens com o seu domínio, e quais deles falham? Um IP desconhecido que falha em tudo é provavelmente falsificação, e o DMARC está fazendo o trabalho dele. Um IP de um serviço que a empresa contratou e que falha no alinhamento é um sistema legítimo mal configurado, e precisa ser corrigido antes de endurecer a política. Ler XML à mão cansa; há serviços e ferramentas que juntam os relatórios num painel.

MTA-STS e TLS-RPT: cifrar a entrega de verdade

SPF, DKIM e DMARC dizem se a mensagem é legítima, mas não protegem o caminho. Entre servidores de e-mail, a criptografia é oportunista: o servidor de destino anuncia que aceita TLS (o comando STARTTLS), e o remetente o usa se o anúncio chegar. Quem está no meio da rede pode apagar esse anúncio, e a mensagem segue em texto aberto, ou desviar a entrega para outro servidor, já que ninguém confere o certificado. O MTA-STS, da RFC 8461, de 2018, fecha essa brecha usando o DNS e a web juntos.

O domínio publica um registro TXT em _mta-sts, com a versão e um identificador da política, e serve a política propriamente dita por HTTPS, num endereço fixo, o mta-sts. seguido do domínio, no caminho /.well-known/mta-sts.txt:

_mta-sts.exemplo.com.br.  TXT  "v=STSv1; id=20261030T120000"

# https://mta-sts.exemplo.com.br/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.exemplo.com.br
max_age: 604800

A política lista os servidores MX válidos e diz o que fazer quando a conexão não passa na verificação: em enforce, o remetente não entrega a mensagem a um servidor sem TLS válido; em testing, entrega e relata; none desliga a política. O max_age diz por quantos segundos o remetente pode guardar a política, e o id do registro TXT avisa quando ela mudou, sem que o remetente precise baixar o arquivo a cada mensagem. Por usar HTTPS e certificados comuns, o MTA-STS não exige DNSSEC; a RFC reconhece o limite: um atacante que bloqueie a primeira descoberta da política ainda consegue rebaixar a entrega.

O companheiro dele é o TLS-RPT, da RFC 8460, também de 2018: um registro TXT em _smtp._tls com um endereço para relatórios (v=TLSRPTv1; rua=mailto:tls@exemplo.com.br). Os remetentes passam a mandar, em geral uma vez por dia, um resumo em JSON com o número de sessões que deram certo e as que falharam, e o motivo de cada falha, como certificado vencido ou STARTTLS ausente. O caminho seguro é o mesmo do DMARC: publicar em testing, ler os relatórios e só então passar para enforce.

O que os grandes provedores exigem

Desde 2024, Google e Yahoo exigem de quem envia grandes volumes SPF e DKIM configurados, DMARC publicado e alinhamento, além de facilidade para cancelar inscrições. Mesmo para volumes pequenos, as três camadas, junto com um DNS reverso (PTR) coerente com o nome do servidor de envio, fazem diferença real na taxa de entrega.

O DNS como banco de consulta: listas de bloqueio

O DNS também é usado no sentido contrário, por quem recebe e-mails. As listas de bloqueio de spam, as DNSBL, publicam os endereços de servidores que enviam spam como nomes numa zona especial. Para saber se o IP 198.51.100.25 está numa lista, o servidor de e-mail inverte os números e pergunta pelo nome 25.100.51.198.lista.exemplo. Se o nome não existe (NXDOMAIN), o IP está limpo. Se existe, a resposta é um endereço do bloco 127.0.0.x, em que o último número codifica o motivo da listagem.

O truque é engenhoso porque herda tudo o que o DNS já tem: cache, distribuição e velocidade. O cuidado é que as listas limitam o volume de consultas gratuitas, e algumas recusam consultas vindas de resolvedores públicos, respondendo com um código especial de "resolvedor bloqueado". Um servidor de e-mail que usa o 8.8.8.8 pode estar recebendo esse código sem perceber, e a lista deixa de funcionar em silêncio. Os servidores sérios combinam várias listas com pesos, de modo que um IP só é recusado quando listas confiáveis concordam, e também consultam listas de permissão, que reduzem a pontuação de servidores conhecidos.

Segurança no DNS

Como quase toda comunicação começa com uma consulta DNS, quem controla as respostas controla para onde as pessoas vão. Os principais riscos:

• Envenenamento de cache. Um atacante tenta fazer um resolvedor aceitar uma resposta falsa, que passa a ser entregue a todos os usuários dele até o TTL vencer. Portas de origem aleatórias e identificadores imprevisíveis dificultaram muito o ataque; o DNSSEC o impede.
• DNSSEC. Cada zona assina os próprios registros, e a zona de cima publica um resumo da chave da zona de baixo (registro DS), formando uma cadeia de confiança que vai até a raiz. Um resolvedor que valida DNSSEC rejeita respostas adulteradas. A configuração exige cuidado na troca de chaves e de provedor, e um erro deixa o domínio inacessível para quem valida.
• Privacidade. O DNS tradicional trafega em texto aberto, e qualquer um no caminho vê quais nomes cada aparelho consulta. O DNS sobre TLS (DoT) e o DNS sobre HTTPS (DoH) cifram a conversa entre o aparelho e o resolvedor.
• Sequestro do domínio. Quem entra na conta do registrador pode trocar os servidores NS e assumir o domínio inteiro: site, e-mail e certificados. Senha forte, autenticação em dois fatores, contatos atualizados e renovação automática são a primeira linha de defesa.
• Subdomínio abandonado. Um CNAME que aponta para um serviço que foi desativado (uma página num serviço de hospedagem, por exemplo) pode ser "reivindicado" por outra pessoa nesse serviço, que passa a servir conteúdo no seu subdomínio. Apague os registros quando desligar o serviço.
• Amplificação. Resolvedores abertos para a internet podem ser usados em ataques de negação de serviço, porque respostas grandes são enviadas a um endereço falsificado. Um resolvedor de empresa deve atender só a rede da empresa.
• Domínios parecidos. Golpistas registram nomes que imitam o seu, trocando letras (gothor por g0thor) ou usando caracteres de outros alfabetos que parecem iguais. Nenhuma configuração de DNS impede isso; monitorar registros parecidos e orientar a equipe, sim.

DNSSEC por dentro

O DNSSEC não cifra nada: as respostas continuam legíveis. Ele acrescenta assinaturas, para que o resolvedor tenha certeza de que a resposta veio do dono da zona e não foi alterada. Quatro tipos de registro fazem o trabalho:

A validação sobe a árvore. O resolvedor confere a assinatura do registro A com a chave da zona exemplo.com.br; confere que essa chave corresponde ao registro DS publicado em .br; confere a assinatura desse DS com a chave do .br; e assim até a raiz, cuja chave o resolvedor já conhece de fábrica, como a âncora de confiança. Muitas zonas usam duas chaves: uma de assinatura de chaves (KSK), a que o DS aponta, e uma de assinatura da zona (ZSK), que pode ser trocada com frequência sem mexer na zona de cima.

O ponto delicado é a troca de provedor ou de chave. Se o DS publicado no .br deixa de corresponder à chave da zona, os resolvedores que validam passam a responder SERVFAIL para o domínio inteiro, enquanto os que não validam continuam funcionando, o que torna o problema confuso: "para mim abre, para o cliente não". A ordem segura na troca de provedor é desligar o DNSSEC (remover o DS no registrador), esperar o TTL do DS, migrar, e só então ativar de novo com as chaves do provedor novo. O dig +dnssec mostra as assinaturas, e o indicador ad na resposta de um resolvedor validador confirma que a cadeia fechou.

Provar que um nome não existe: NSEC e NSEC3

Assinar uma resposta positiva é simples: o registro existe, e a assinatura dele também. A resposta negativa é mais difícil, porque não há registro para assinar, e as assinaturas são feitas antes, e não a cada consulta. A solução do DNSSEC é assinar os intervalos vazios. Com os nomes da zona em ordem, cada registro NSEC diz "depois de compras vem loja, e entre eles não há nada". Quem pergunta por contato recebe esse NSEC assinado, prova de que o nome não existe.

O efeito colateral é que, seguindo os NSEC de um em um, qualquer pessoa consegue listar todos os nomes da zona. A RFC 5155, de 2008, diz isso sem rodeios: é trivial enumerar o conteúdo de uma zona perguntando por nomes que não existem. O NSEC3 responde com resumos criptográficos dos nomes no lugar dos nomes: a cadeia continua provando a inexistência, mas mostra só resumos, e descobrir o nome por trás de cada um exige tentar palavras de um dicionário. A RFC prevê um sal, acrescentado ao nome antes do resumo para impedir tabelas prontas, e iterações extras, que encarecem as tentativas, ao custo de mais processamento para servidores e resolvedores. Prevê também a opção opt-out, pensada para zonas enormes cheias de delegações sem assinatura, como as de domínios de topo, que deixa essas delegações fora da cadeia.

Vale ter clareza sobre o alcance: o NSEC3 dificulta a enumeração, mas não a impede para nomes previsíveis, como www, mail ou vpn. Nomes no DNS público são, por natureza, públicos, e nenhum deles deve ser tratado como segredo.

A troca da chave da raiz

A âncora de confiança de todo resolvedor que valida DNSSEC é a chave de assinatura de chaves da raiz, a KSK da raiz. Ela foi trocada pela primeira vez em outubro de 2018, depois de um adiamento de um ano, e a segunda troca aconteceu em outubro de 2026. A chave nova, chamada KSK-2024 e identificada pela etiqueta 38696, foi publicada na zona raiz em 11 de janeiro de 2025, para que os resolvedores tivessem tempo de aprendê-la. Em 11 de outubro de 2026, às 14h em UTC, ela passou a ser a única a assinar a raiz, e a ICANN informou, em 15 de outubro, que a troca foi concluída como planejado, enquanto avaliava relatos de problemas num número limitado de sistemas. A revogação da chave anterior está prevista para janeiro de 2027.

Os resolvedores aprendem a chave nova sozinhos pelo procedimento da RFC 5011, que exige observar uma chave nova por 30 dias antes de confiar nela automaticamente. O risco está nos que não fazem isso: equipamentos com a âncora gravada de fábrica e nunca atualizados, servidores restaurados de imagens antigas, configurações com a chave fixada à mão. Um resolvedor validador sem a KSK-2024 deixa de conseguir validar a raiz, e a ICANN alertou que ele passaria a ter falhas de DNS. Quem mantém um resolvedor próprio deve conferir se a etiqueta 38696 está na configuração da âncora de confiança.

Cifrar as consultas: DoT e DoH

O DNS sobre TLS usa uma porta própria, a 853, e por isso é fácil de identificar e, numa rede corporativa, de controlar. O DNS sobre HTTPS viaja na porta 443, misturado ao tráfego web comum, e é difícil de distinguir. Os navegadores e os sistemas operacionais modernos oferecem os dois. Para uma pessoa numa rede pública, é um ganho claro de privacidade; para uma empresa que filtra domínios maliciosos no resolvedor interno, um navegador que fala DoH direto com um resolvedor externo contorna o filtro. As políticas dos navegadores para empresas permitem definir qual resolvedor DoH usar, ou desligá-lo.

Ferramentas para investigar

Quando "o site não abre" ou "o e-mail não chega", consultar o DNS diretamente separa o problema de DNS dos outros:

dig exemplo.com.br A +short                 # o endereço IPv4
dig exemplo.com.br MX +short                # quem recebe os e-mails
dig exemplo.com.br TXT +short               # SPF e verificações
dig _dmarc.exemplo.com.br TXT +short        # a política DMARC
dig @1.1.1.1 exemplo.com.br A               # perguntando a um resolvedor específico
dig exemplo.com.br NS +short                # quem é o autoritativo
dig -x 203.0.113.10 +short                  # o DNS reverso de um IP

Comparar a resposta do servidor autoritativo com a de um resolvedor público mostra se o problema é a configuração ou um cache antigo. Para e-mail, o próprio Gmail mostra o resultado de SPF, DKIM e DMARC de cada mensagem em "Mostrar original", o que é o teste mais rápido depois de uma mudança.

Lendo a saída completa do dig

Sem o +short, o dig mostra a mensagem inteira, e cada parte conta alguma coisa:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4127
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;exemplo.com.br.            IN  A

;; ANSWER SECTION:
exemplo.com.br.     287     IN  A   203.0.113.10

;; Query time: 14 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

O status é o código de resposta da tabela do começo do artigo. Os flags mostram que é uma resposta (qr), que houve recursão (rd ra) e que o resolvedor validou o DNSSEC (ad); a ausência de aa indica que a resposta veio de cache, e o TTL de 287 segundos mostra quanto falta para ela vencer. O Query time alto na primeira consulta e baixo nas seguintes é o cache funcionando. E a linha SERVER diz a quem você perguntou, detalhe que evita muita conclusão errada.

No Windows, sem instalar nada, o PowerShell faz o mesmo: Resolve-DnsName exemplo.com.br -Type MX consulta um tipo específico, e -Server 1.1.1.1 escolhe o resolvedor. O velho nslookup, presente em todos os sistemas, também funciona, com uma saída menos detalhada.

Um diagnóstico passo a passo

Um caso típico: a empresa trocou a hospedagem do site na sexta-feira, e na segunda alguns clientes dizem que o site "está fora do ar", enquanto para a equipe ele abre normalmente.

1. Pergunte ao autoritativo. dig exemplo.com.br NS +short mostra os servidores; dig @ns1.provedor-dns.exemplo exemplo.com.br A mostra o que eles respondem. Se o endereço já é o novo, a configuração está certa e o problema está em algum cache ou em outro registro.
2. Pergunte a vários resolvedores. Repita a consulta em @1.1.1.1, @8.8.8.8 e no resolvedor do provedor do cliente, se souber qual é. Um deles com o endereço antigo e um TTL alto na resposta explica tudo: falta esperar ou, na próxima vez, baixar o TTL antes.
3. Confira o IPv6. dig exemplo.com.br AAAA +short. Um AAAA esquecido, ainda apontando para a hospedagem antiga, faz quem tem IPv6 cair no servidor velho. É comum em redes móveis e de fibra, que entregam IPv6 por padrão, e explica por que "no celular não abre, no Wi-Fi do escritório abre".
4. Teste o DNSSEC. Se um resolvedor validador responde SERVFAIL e a mesma consulta com +cd (que desliga a validação) funciona, o DS do domínio não corresponde às chaves do provedor novo.
5. Descarte o seu próprio cache. Antes de concluir que "para mim funciona", limpe o cache do navegador e do sistema, ou teste por outra rede, como o celular fora do Wi-Fi.
6. Só então olhe além do DNS. Se todos os resolvedores respondem o endereço certo, o problema é outro: o servidor web, o certificado, o firewall.

Erros comuns

• Mudar um registro sem baixar o TTL antes, e descobrir que a migração vai levar um dia.
• Dois registros SPF no mesmo domínio, o que invalida os dois, ou um SPF com mais de dez consultas.
• Esquecer um sistema que envia e-mail em nome do domínio (o ERP, a plataforma de marketing, o sistema de boletos) ao endurecer o SPF e o DMARC.
• **Ir direto para p=reject** sem passar um tempo lendo relatórios.
• CNAME no apex ou CNAME junto com outros registros no mesmo nome.
• MX apontando para um IP, ou para um nome que não tem registro A.
• Registro AAAA sem o serviço escutar em IPv6. Quem chega por IPv6 encontra a porta fechada ou outro serviço.
• Deixar CNAMEs apontando para serviços desativados.
• Domínio vencido. Parece improvável até acontecer: sem renovação automática, o site e o e-mail saem do ar juntos.
• Conta do registrador sem dois fatores, guardada no e-mail de uma pessoa que saiu da empresa.
• Esquecer o ponto final num nome completo ao editar uma zona à mão.
• Trocar de provedor de DNS com DNSSEC ligado, sem remover o DS antes.
• Usar um resolvedor público num servidor de e-mail que consulta listas de bloqueio, que podem recusar essas consultas.

Boas práticas

• Use renovação automática e autenticação em dois fatores no registrador, com contatos de um grupo da empresa, e não de uma pessoa.
• Documente a zona: cada registro, para que serve e quem pediu.
• Baixe o TTL antes de qualquer mudança planejada.
• Publique SPF, DKIM e DMARC para todo domínio que envia e-mail, e DMARC com p=reject também nos domínios que não enviam, para que ninguém os use em golpes.
• Leia os relatórios DMARC, especialmente depois de contratar um serviço novo que envia e-mails.
• Configure o DNS reverso dos servidores de e-mail com o nome que eles usam.
• Remova registros de serviços desligados.
• Mantenha A e AAAA coerentes com os serviços: se publica IPv6, teste por IPv6.
• Tenha pelo menos dois servidores autoritativos, em redes diferentes.
• Publique um registro CAA com as autoridades que emitem os seus certificados.

Perguntas frequentes

Quanto tempo leva para uma mudança de DNS valer? No servidor autoritativo, vale na hora. Para o resto do mundo, até o TTL antigo do registro vencer em cada cache. Com TTL de 300 segundos, são minutos; com TTL de um dia, até 24 horas. Na troca de servidores NS, conte com o TTL definido pelo registro do domínio de topo, que costuma ser de horas.

Trocar de provedor de DNS derruba o site? Não, se a zona completa for criada e conferida no provedor novo antes da troca dos NS. Durante a transição, os dois provedores respondem a mesma coisa, e não importa qual o resolvedor consultar. O cuidado extra é o DNSSEC.

Posso ter o site num lugar e o e-mail em outro? Pode, e é comum. O registro A do domínio aponta para a hospedagem do site; o MX aponta para o provedor de e-mail. Basta que o SPF, o DKIM e o DMARC autorizem quem realmente envia os e-mails.

Usar um resolvedor público deixa a internet mais rápida? Às vezes. Os resolvedores públicos costumam ter caches enormes e boa infraestrutura, mas a distância de rede também conta, e o do provedor pode estar mais perto. O ganho mais certo é a validação DNSSEC e, em alguns, o filtro de domínios maliciosos.

Preciso de DNSSEC? Ele protege contra respostas falsificadas e é cada vez mais comum; o .br oferece suporte e vários provedores o ativam com um clique. O custo é operacional: trocas de chave e de provedor exigem cuidado. Para domínios com operações financeiras, o benefício costuma compensar.

**O que é o arquivo hosts e quando usar?** É uma lista local de nomes e endereços, consultada antes do DNS. Serve para testar um site novo antes de mudar o DNS: aponta-se o nome para o endereço do servidor novo só no seu computador. Esquecer a linha lá depois é causa clássica de "só no meu computador está diferente".

Como usamos o DNS na Gothor

O DNS sustenta tudo o que a Gothor coloca no ar, do site ao e-mail. Os cuidados deste artigo fazem parte da nossa rotina: os registros de autenticação de e-mail (SPF, DKIM e DMARC) configurados para que as mensagens enviadas em nome da empresa cheguem à caixa de entrada e para que ninguém consiga se passar por nós.

Resumo

• O DNS é um banco de dados distribuído e hierárquico que associa nomes a endereços e a muitas outras informações. Pergunta e resposta usam o mesmo formato, com um código de resposta (NOERROR, NXDOMAIN, SERVFAIL) que orienta o diagnóstico.
• A árvore começa na raiz, passa pelos domínios de topo e chega aos domínios, com a responsabilidade delegada por registros NS e, quando preciso, registros de cola.
• Uma consulta passa pelos caches do aparelho e por um resolvedor recursivo, que, se precisar, pergunta à raiz, ao domínio de topo e ao servidor autoritativo.
• A, AAAA, CNAME, MX, TXT, NS, SOA, CAA e PTR são os registros do dia a dia; CNAME não vai no apex, PTR fica com o dono do IP e o número de série do SOA sempre aumenta.
• Nada "propaga": caches guardam respostas até o TTL vencer. Baixe o TTL antes de mudar.
• O DNS também distribui tráfego, e A e AAAA precisam corresponder ao que o servidor realmente atende.
• SPF diz quem pode enviar, DKIM assina as mensagens e DMARC exige alinhamento com o "De:" e define a política. Listas de bloqueio usam o próprio DNS como banco de consulta.
• O DMARC foi revisado na RFC 9989, de 2026: o pct= saiu, o t=y entrou. O MTA-STS obriga o TLS na entrega dos e-mails.
• Nomes internos ficam num subdomínio próprio ou no .internal, nunca num sufixo inventado nem no .local.
• DNSSEC protege a integridade das respostas com uma cadeia de assinaturas até a raiz, cuja chave foi trocada em outubro de 2026, DoT e DoH protegem a privacidade, e a conta do registrador protege o domínio inteiro.

Para ir além

• O que é DNS, no centro de aprendizado da Cloudflare, e como o DNSSEC funciona.
• RFC 1034 e RFC 1035, os conceitos e a especificação do DNS.
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC, de 2026) e a anterior, RFC 7489.
• RFC 8461 (MTA-STS) e RFC 8460 (TLS-RPT).
• RFC 9460 (registros SVCB e HTTPS), RFC 8659 (CAA), RFC 8555 (ACME) e os tipos de desafio da Let's Encrypt.
• RFC 8914 (erros estendidos) e RFC 5155 (NSEC3).
• A troca da KSK da raiz, na ICANN, com o comunicado de 15 de outubro de 2026 e o guia de preparação.
• Resolução da ICANN que reservou o .internal, RFC 8375 (home.arpa) e RFC 6762 (multicast DNS e o .local).
• Diretrizes para remetentes de e-mail do Google.
• Registro.br, o registro dos domínios .br.
• Servidores raiz e a zona raiz na IANA.
• RFC 8484 (DNS sobre HTTPS) e RFC 7858 (DNS sobre TLS).
• RFC 9156, sobre a minimização das perguntas, e RFC 8305, sobre o Happy Eyeballs.