DNS ferramentas
Uma referência prática de tipos de registro DNS, TTL e cronograma de cutover, delegação e registros TXT de e-mail — mais qual ferramenta de consulta usar quando um nome não resolve.
1 ferramentas
O DNS é uma hierarquia de caches, não um banco de dados
Quando você «muda um registro DNS», está editando uma zona em um conjunto de
nameservers autoritativos — e quase ninguém lê essa zona. As respostas dos seus
usuários vêm de resolvedores recursivos (o do provedor de acesso, o 8.8.8.8,
um resolvedor corporativo, o endpoint DoH do próprio navegador), cada um
guardando uma cópia que expira no seu próprio cronograma. Existe uma resposta
autoritativa e N aproximações em cache dela — mais o seu próprio notebook, cujo
cache do sistema operacional e cujo /etc/hosts passam por cima de tudo.
A resolução começa na raiz: um resolvedor frio pergunta a um servidor raiz sobre
www.example.com, é encaminhado aos nameservers de .com e depois aos
registros NS que o registrador publicou para example.com. Cada elo dessa
cadeia de delegação é, ele mesmo, um registro em cache com o seu próprio TTL, e
o conjunto NS no TLD normalmente fica em cache de 1 a 2 dias — que é
exatamente por que trocar de provedor de DNS não se comporta em nada como
mudar um registro A.
«Propagação», portanto, é um nome enganoso: nada é empurrado, as respostas
antigas apenas expiram — inclusive as negativas. NXDOMAIN fica em cache pelo
intervalo derivado do SOA da zona (comumente 300–3600 s), então um nome pode
parecer inexistente por minutos depois de você criá-lo.
Tipos de registro que você realmente mexe
| Tipo | Guarda | Uso típico | Cuidado com |
|---|---|---|---|
A | um endereço IPv4 | nome → host | múltiplos A = round-robin, não failover |
AAAA | um endereço IPv6 | pilha dupla | AAAA quebrado quebra clientes que preferem IPv6 |
CNAME | outro nome | CDN, endpoints SaaS | ilegal no ápice; exclui outros registros |
MX | host de e-mail + prioridade | e-mail de entrada | número menor ganha; um host, nunca um IP |
TXT | strings de forma livre | SPF, DKIM, DMARC, verificação | 255 caracteres por string; chaves longas são fatiadas |
NS | nameservers delegados | delegação da zona | o conjunto no pai é o que conta |
SOA | temporizadores da zona, serial | TTL de cache negativo | MINIMUM define a duração do NXDOMAIN |
PTR | nome de um endereço | DNS reverso, reputação do remetente | in-addr.arpa (IPv4) / ip6.arpa (IPv6); pertence a quem detém o IP |
CAA | ACs autorizadas | controle de emissão | verificado na emissão, não no handshake TLS |
DS / DNSKEY | âncoras DNSSEC | delegação assinada | DS desatualizado depois de um rollover de chave = falha total |
TTL, cutovers e janelas de rollback
Escolha os TTLs pela rapidez com que você pode precisar se mover: 60 para um
registro que talvez seja reapontado em minutos, 300–900 durante uma
migração, 3600 em regime estável, 86400 para NS e MX que você nunca
toca. TTLs curtos não são de graça — eles multiplicam o volume de consultas e
encurtam a folga que protege você se os servidores autoritativos ficarem
inalcançáveis.
O rollback importa tanto quanto o cutover: um TTL em cache é um piso para a recuperação, então um TTL de 300 s mantém os últimos resolvedores apontando para um endpoint morto por cinco minutos depois de você publicar. Dois eventos assim por mês são cerca de 10 minutos de indisponibilidade, e a Calculadora SLA mostra se isso cabe — 99,99% permite 4,3 minutos por mês de 30 dias. Mais sobre orçamento na página do kit para SRE.
O que SPF, DKIM e DMARC provam, cada um
| Mecanismo | Publicado como | Um pass prova | Não prova |
|---|---|---|---|
| SPF | TXT no domínio, v=spf1 … | que o IP que conectou pode enviar pelo domínio do MAIL FROM do envelope | nada sobre o From: visível; quebra no encaminhamento |
| DKIM | TXT em selector._domainkey.domain, v=DKIM1; p=… | que os cabeçalhos assinados e o corpo não foram alterados desde que d= os assinou | que d= é o seu domínio; cabeçalhos não assinados podem ser adicionados |
| DMARC | TXT em _dmarc.domain, v=DMARC1; p=… | que SPF ou DKIM passou e que aquele domínio está alinhado com o From: | aplicação — p=none apenas pede relatórios |
Dos três, só o registro SPF do ápice é legível com o
DNS Lookup: a aba TXT mostra a string v=spf1 que você
publicou, mas a ferramenta aceita apenas rótulos de hostname, então nomes com
sublinhado como _dmarc.example.com e selector._domainkey.example.com são
rejeitados com Invalid domain format. Leia esses com
dig TXT _dmarc.example.com ou no editor de zona do seu provedor de DNS. O que
um receptor concluiu é uma questão separada, e o
Analisador de Cabeçalhos de E-mail responde a partir dos
cabeçalhos Authentication-Results, Received-SPF, DKIM-Signature e ARC de
uma mensagem entregue. Antes de adicionar um mecanismo ip4:, confirme o
endereço de onde o seu tráfego realmente sai com o
Verificar IP em vez de confiar em um arquivo de configuração.
Se um registro DKIM foi remontado a partir de strings fatiadas, cole o valor de
p= no Base64: ele rejeita caracteres perdidos e preenchimento
quebrado, pegando uma chave corrompida. Mais sobre cabeçalhos de autenticação:
o hub de e-mail.
Qual ferramenta para qual trabalho
Dado um domínio, o DNS Lookup resolve A, AAAA, CNAME,
MX, TXT e NS em uma consulta, imprimindo TYPE / NAME / VALUE / TTL com a
prioridade do MX; as abas de tipo filtram no cliente as linhas já buscadas,
então alternar entre MX e TXT não custa consulta extra. O CNAME não tem
aba própria, então essas linhas — as que dizem que um nome é um alias e não um
endereço — aparecem na visão ALL. Leia a barra de status literalmente: SERVER
é sempre api.sitekits.dev e LATENCY é a ida e volta navegador→API, nem o
resolvedor recursivo que respondeu nem o tempo da consulta DNS. A resolução roda
no servidor via DoH da Cloudflare, que é o que lhe dá um ponto de observação
fora do seu próprio cache; para determinar qual resolvedor respondeu, pergunte
a um diretamente com dig @8.8.8.8 example.com. Se em vez disso você tem uma
URL, o Parseador de URL isola hostname de host (que
inclui a porta), localmente, sem buscar nada.
Quando os registros estão certos mas o conteúdo servido é o errado, já não é DNS: os Cabeçalhos HTTP buscam no servidor e devolvem status, cadeia de redirecionamento e todo cabeçalho de resposta — o suficiente para separar «ainda é o IP antigo» de «IP certo, cache de CDN velho». Nunca recuperam o corpo e recusam endereços privados.
O DNS transporta apenas rótulos ASCII, então o
Conversor IDN mostra a forma xn-- que é realmente
consultada, o que também desmascara sósias homográficos. Valores AAAA que
parecem diferentes muitas vezes não são: a
Compressão IPv6 normaliza as duas grafias e expande os
grupos que um nome ip6.arpa exige. Tire um retrato da zona antes de uma
migração e compare antes/depois no Diff de Texto.
Pegadinhas que custam horas
CNAME no ápice da zona
example.com precisa carregar SOA e NS, e CNAME não pode coexistir com
outros registros em um nome — então CNAME no ápice é inválido, aceite o painel
de controle o que aceitar. ALIAS/ANAME e achatamento são recursos de
provedor, não do protocolo.
Dois registros SPF em vez de um
Um segundo registro TXT v=spf1 no mesmo nome produz um permerror. Junte
todos os mecanismos em um único registro e conte as consultas: include:, a,
mx, ptr, exists e redirect= consomem cada um uma das 10 consultas DNS
que uma avaliação tem direito (RFC 7208 §4.6.4) — um teto que cadeias de
fornecedores empilhadas estouram silenciosamente.
Nomes relativos e pontos finais ausentes
Na sintaxe de arquivo de zona, um destino sem ponto final é relativo, então
www.example.com se torna www.example.com.example.com. — exatamente o que
acontece quando você cola um destino totalmente qualificado em uma interface que
já acrescenta a zona.
Registros órfãos apontando para serviços liberados
Um CNAME ainda apontado para um bucket, plataforma de aplicação ou hostname de
CDN descomissionado pode ser reivindicado por quem registrar aquele nome em
seguida, entregando a um atacante um subdomínio seu — veja o
kit de segurança.