DNS Cheat Sheet: Guia Rápido para Desenvolvedores e Administradores

DNS raramente chama atenção até que algo pare de funcionar. O deploy sai, a aplicação está rodando normalmente no próprio IP, mas o domínio simplesmente não aponta para lugar nenhum — e de repente todo mundo no time está digitando os mesmos comandos de consulta e tentando adivinhar o valor certo de TTL. Este DNS cheat sheet existe exatamente para esse momento: sem histórico de protocolo, sem mergulho em RFC, apenas os registros, comandos e cenários que aparecem quando você está subindo um servidor, investigando uma queda ou revisando o arquivo de zona de outra pessoa.

O conteúdo foi pensado para dois públicos que se sobrepõem bastante: desenvolvedores que mexem em DNS algumas vezes por projeto e precisam de algo rápido para consultar, e administradores que lidam com isso todos os dias e querem um vocabulário comum com o time. Seja para apontar um domínio novo para um host recém-criado ou para descobrir por que o e-mail continua caindo no spam, o mesmo punhado de tipos de registro e ferramentas resolve a maior parte dos casos. Vale deixar esta página aberta em outra aba; ela foi feita para ser consultada, não lida do início ao fim.

O que vem a seguir se organiza em três blocos: o que os principais registros DNS realmente significam, como uma consulta DNS percorre o caminho entre o navegador e a resposta final, e o que costuma dar errado nesse trajeto. Nada disso exige decorar uma especificação — depois de uma ou duas migrações isso vira quase automático, e esta página serve justamente para encurtar essa curva de aprendizado para quem ainda não passou por isso.

Fundamentos de DNS: Termos que Você Vai Usar de Verdade

Algumas definições antes da tabela de registros, já que boa parte da confusão em DNS vem de misturar esses termos. Um resolver é o serviço — operado pelo seu provedor de internet ou um serviço público como 1.1.1.1 ou 8.8.8.8 — que faz as consultas em seu nome e armazena os resultados em cache. Um servidor autoritativo é aquele que efetivamente guarda o arquivo de zona de um domínio e dá a resposta final. Um arquivo de zona é a lista completa de registros DNS de um domínio, e o TTL (time to live) é por quantos segundos um resolver pode manter um registro em cache antes de consultar de novo.

Essas quatro peças se relacionam mais do que parece. O resolver só pergunta ao servidor autoritativo uma vez por registro e, depois disso, confia na cópia em cache pelo tempo que o TTL permitir — o que significa que uma alteração feita no arquivo de zona já está correta no instante em que é salva, mas continua invisível para quem tem uma resposta em cache até que esse cache expire. Essa lacuna explica boa parte das dúvidas do tipo "já mudei o registro, por que ainda não funcionou".

Com isso esclarecido, aqui está a referência de registros DNS que a maioria das pessoas realmente precisa:

Como uma Consulta DNS Funciona, Passo a Passo

Toda consulta DNS segue mais ou menos o mesmo caminho, seja ela disparada por um navegador, um comando curl ou um servidor de aplicação resolvendo um hostname interno. Entender essa ordem importa, porque boa parte da depuração de DNS consiste em descobrir qual elo dessa cadeia está segurando uma resposta desatualizada ou errada — e a correção muda dependendo se o problema está no cache do navegador, no resolver ou no próprio servidor autoritativo.

1. O cliente verifica primeiro o próprio cache local — navegador e, em seguida, sistema operacional.
2. Se nada estiver em cache, a consulta vai para um resolver recursivo configurado, geralmente o do provedor de internet ou um público.
3. O resolver verifica o próprio cache; se estiver vazio, pergunta a um servidor raiz onde encontrar a resposta.
4. O servidor raiz também não sabe a resposta, mas indica ao resolver o servidor de nomes correto do TLD (por exemplo, os servidores responsáveis por .com).
5. O servidor de nomes do TLD indica ao resolver o servidor autoritativo daquele domínio específico.
6. O servidor autoritativo devolve o registro solicitado — um A, um MX, ou o que tiver sido pedido.
7. O resolver guarda essa resposta em cache pelo TTL do registro e a devolve ao cliente.

É por causa dessa última etapa que uma alteração de registro não vale em todo lugar instantaneamente. Todo resolver que já tinha a resposta antiga em cache continua servindo essa resposta até o TTL vencer, e é isso que torna a propagação de DNS algo imprevisível mesmo quando a alteração em si foi aplicada corretamente. Também vale saber que uma resposta negativa também fica em cache — quando uma consulta DNS falha, essa ausência de resposta é armazenada por um período mais curto, o que explica por que um erro de digitação já corrigido ainda pode falhar por alguns minutos depois do ajuste.

Vantagens e Contrapartidas do Design Baseado em DNS

Depender do DNS para rotear tráfego é conveniente, mas vem com contrapartidas que valem a pena conhecer antes de apostar nele para algo crítico.

Limitações e Riscos que Vale a Pena Conhecer

O DNS não foi desenhado pensando em segurança como prioridade, e parte disso aparece décadas depois. As consultas padrão trafegam por UDP sem criptografia, o que as deixa expostas a inspeção no meio do caminho e, em casos mais raros, a cache poisoning — quando um resolver é enganado e passa a guardar um registro falso. DNSSEC, junto com opções de transporte criptografado como DNS over HTTPS e DNS over TLS, resolve boa parte disso, embora muita configuração por aí ainda rode sem nenhuma dessas proteções.

Existe também o problema do ponto único de falha. Um domínio que depende de um único servidor de nomes, ou de um único provedor de DNS, fica fora do ar assim que essa peça única apresenta problema — não importa o quanto o resto da infraestrutura da aplicação seja sólido. Manter um servidor de nomes secundário, ou dividir o DNS entre dois provedores, elimina esse risco a um custo relativamente baixo.

A má configuração de TTL cria sua própria categoria de dor de cabeça. Deixá-lo alto demais faz uma migração se arrastar por horas ou dias a mais do que precisaria, já que resolvers em cache continuam mandando tráfego para o servidor antigo. Deixá-lo baixo demais faz cada resolver consultar de novo o tempo todo, aumentando a carga desnecessariamente e, em alguns provedores, o custo de cada consulta.

Há um risco mais sutil em quanta confiança se deposita, por padrão, em um provedor de DNS. Mover a hospedagem do DNS para terceiros significa que qualquer mudança futura nos registros DNS — um subdomínio novo, um failover de emergência, um erro de digitação corrigido — passa a depender do painel e da API desse provedor continuarem disponíveis e confiáveis. Times maiores às vezes contornam isso com DNS split-horizon, em que resolvers internos e externos devolvem respostas diferentes para o mesmo hostname, mantendo nomes de serviços internos fora dos arquivos de zona públicos. Isso resolve um problema real, mas também dobra o número de lugares em que um registro precisa ser atualizado corretamente.

Cenários Práticos: o DNS Cheat Sheet na Prática

Apontando um Domínio para uma Nova VPS

Esse é o cenário que praticamente todo mundo enfrenta em algum momento: mover um domínio para um host novo. A ordem segura é reduzir o TTL um dia antes da mudança, criar ou atualizar o registro A (e o AAAA, se o servidor tiver endereço IPv6), e só então confirmar que o novo servidor está respondendo corretamente antes de mexer em qualquer outra coisa. Uma checagem rápida pela linha de comando:

Provedores como a VPS da Serverspace entregam o endereço IP do servidor assim que a instância é criada, e essa é justamente a única informação que o registro A precisa — o resto é só esperar o TTL antigo vencer.

Configurando a Entrega de E-mail

O roteamento de e-mail depende de um registro MX, além de um conjunto de registros TXT — SPF, DKIM e DMARC — que informam aos servidores de e-mail que recebem a mensagem que o domínio realmente autorizou aquele envio. Faltar um deles costuma resultar em mensagens rejeitadas ou jogadas direto no spam.

O SPF lista quais servidores têm permissão para enviar em nome do domínio, o DKIM assina as mensagens de saída para que quem recebe consiga verificar que não foram alteradas no caminho, e o DMARC diz aos servidores receptores o que fazer quando uma dessas checagens falha. Os três juntos são, hoje, o mínimo que a maioria dos provedores de caixa de entrada espera antes de confiar em um domínio.

Verificando a Propriedade de um Domínio

Ferramentas de terceiros — plataformas de e-mail, CDNs, autoridades certificadoras — costumam pedir um registro TXT com um token específico antes de agir em nome de um domínio. A lógica é simples: qualquer um pode alegar que é dono de um domínio, mas só quem controla o arquivo de zona consegue de fato adicionar um registro nele, então esse token funciona como prova.

Usando CNAME para Subdomínios e Endpoints de CDN

Registros CNAME apontam um hostname para outro, o que é a configuração padrão para um subdomínio servido por uma CDN ou uma plataforma SaaS — blog.example.com apontando para uma plataforma de blog hospedada, por exemplo. A pegadinha comum: um nome não pode ter um CNAME e outro tipo de registro ao mesmo tempo, então adicionar um na raiz do domínio em vez de num subdomínio costuma quebrar coisas de um jeito nada óbvio à primeira vista.

Migrando Entre Provedores de DNS

Trocar quem hospeda sua zona — sair do DNS padrão do registrador e ir para um provedor dedicado, por exemplo — é mais arriscado do que editar um único registro, porque cada registro precisa sobreviver intacto à mudança. A sequência segura: primeiro exportar ou copiar manualmente todos os registros DNS existentes para o novo provedor, conferir cada um contra a zona original, e só depois atualizar os registros de servidor de nomes no registrador para apontar para o novo provedor. Vale manter a zona antiga ativa e intocada por alguns dias após a virada; se algo ficou de fora, ainda dá para comparar em vez de tentar adivinhar quais eram os valores originais.

Rodar esse comando contra os servidores de nomes antigos e novos, antes e depois da troca, é a forma mais rápida de confirmar que a mudança no registrador realmente aconteceu, em vez de simplesmente confiar no que o painel mostrou.

Diagnosticando "O Site Não Carrega"

Quando um domínio não resolve, ou resolve para o lugar errado, nslookup e dig são as primeiras ferramentas a usar.

A flag +trace percorre toda a cadeia de resolução a partir dos servidores raiz, o que é genuinamente útil quando o problema está em algum ponto entre o registrador e o servidor autoritativo, e não no registro em si. Uma consulta simples mostra só a resposta final; um trace mostra exatamente de onde essa resposta veio.

Erros Comuns que Quebram Configurações de DNS

A maioria dos incidentes de DNS tem origem em um punhado pequeno de erros que se repetem. Nenhum deles é exótico — são o tipo de deslize óbvio depois que aconteceu e quase invisível no meio de um deploy.

• Deixar o TTL alto pouco antes de uma migração, o que estende a indisponibilidade para quem já tinha o registro antigo em cache
• Esquecer de atualizar os registros de servidor de nomes no registrador depois de trocar de provedor de DNS, fazendo com que qualquer outra mudança simplesmente não tenha efeito
• Erros de digitação nos valores dos registros — um dígito a mais num endereço IP, ou um ponto final faltando num destino de CNAME
• Deixar de configurar o DNS reverso (PTR) num servidor de e-mail, o que faz mensagens de saída serem marcadas como spam por destinatários mais rigorosos
• Adicionar um registro curinga que acaba sobrepondo, sem querer, subdomínios que alguém já tinha configurado de propósito
• Fazer a virada para um servidor novo antes de confirmar a propagação, e depois depurar um comportamento que parece aleatório mas é só uma mistura de respostas antigas e novas em cache
• Não guardar uma cópia dos registros DNS antigos antes de fazer alterações, o que transforma um rollback em adivinhação em vez de um ajuste de dois minutos
• Testar mudanças a partir de um único dispositivo ou rede e assumir que o resultado vale para todo mundo — um cache local pode esconder um problema que segue bem ativo para outros visitantes

Conclusão

O DNS parece simples até o momento em que um incidente obriga a relembrar seis ferramentas e três siglas de uma vez, quase sempre na hora mais inconveniente possível. Ter um DNS cheat sheet como este à mão — tipos de registro, a cadeia de resolução, os comandos, os pontos de falha mais comuns — transforma esse sufoco em uma consulta de cinco minutos. Para ir além nesses temas, de DNSSEC a failover multirregião, o blog da Serverspace é um próximo passo razoável assim que o básico deste guia estiver dominado.

Perguntas Frequentes