Como consultar registros DNS

O DNS é o sistema que traduz nomes de domínio em endereços IP. Quando algo dá errado, um site que não carrega, um e-mail que nunca chega, um certificado SSL que falha, verificar os registos DNS é quase sempre o primeiro passo de depuração. Compreender o que cada tipo de registo faz, como as consultas circulam pelo sistema e onde olhar quando os resultados divergem transforma falhas misteriosas em problemas solucionáveis.

Uma breve história do DNS

Antes do DNS, cada computador na internet inicial partilhava um único ficheiro chamado HOSTS.TXT, mantido no Stanford Research Institute. Cada site descarregava o ficheiro periodicamente para conhecer os endereços IP das outras máquinas. O sistema funcionava quando a rede tinha algumas centenas de hosts. Não escalava.

Em 1983, Paul Mockapetris publicou as RFC 882 e RFC 883, que descreviam um sistema de nomenclatura hierárquico e distribuído: o Domain Name System. As especificações foram refinadas em 1987 em RFC 1034 (conceitos e funcionalidades) e RFC 1035 (implementação e especificação), que permanecem os documentos fundadores hoje. Em vez de um único ficheiro gigante, o espaço de nomes foi dividido em zonas, cada uma gerida pelos seus próprios servidores autoritativos, com um pequeno conjunto de servidores raiz no topo da árvore.

O DNS tem sido estendido constantemente desde então. Os registos AAAA (RFC 3596, 2003) adicionaram suporte a IPv6. DNSSEC (RFC 4033 a 4035, 2005) adicionou assinaturas criptográficas para proteger contra falsificação. DNS-over-TLS (RFC 7858, 2016) e DNS-over-HTTPS (RFC 8484, 2018) cifraram as consultas para que bisbilhoteiros e caixas intermediárias não as pudessem ver ou alterar. Cada camada do sistema mantém compatibilidade retroativa, e é por isso que um protocolo de quarenta anos ainda faz funcionar a web moderna.

Tipos de registos DNS

Existem dezenas de tipos de registos DNS, mas um punhado cobre a grande maioria das consultas reais. Saber o que cada um faz torna a triagem mais rápida.

A, AAAA, CNAME e MX respondem à maioria das perguntas do dia a dia. TXT, NS, SOA e CAA aparecem durante configuração e auditorias de segurança. SRV e NAPTR importam para VoIP, XMPP e outros protocolos de descoberta de serviços. PTR importa para servidores de correio, pois a maioria dos filtros de spam rejeita remetentes sem DNS reverso válido.

Como consultar registos DNS

1. Introduza um domínio: escreva qualquer nome de domínio (por exemplo, example.com) na ferramenta de consulta. Também pode introduzir um subdomínio como mail.example.com se quiser registos específicos dessa etiqueta.
2. Selecione um tipo de registo: escolha A, AAAA, MX, TXT, CNAME, NS, SOA ou CAA. A ferramenta também suporta consultar todos os tipos comuns de uma vez para uma visão rápida.
3. Reveja os resultados, a resposta lista cada registo correspondente com o seu valor, TTL (quanto tempo os resolvedores o podem cachear) e quaisquer campos extra como prioridade MX ou números de série SOA.
4. Compare com o esperado: se acabou de alterar um registo, verifique que o novo valor aparece. Se está a depurar um terceiro, compare o que vê com o que dizem ter configurado.

Depurar problemas reais com DNS

Site não carrega? Verifique os registos A e AAAA. Se faltam, o domínio não está ligado; se apontam para um IP antigo, o tráfego está a chegar a um servidor que já não aloja o site. Confirme também que os registos NS correspondem aos servidores de nomes listados pelo registador, pois um desencontro significa que toda a zona está a ser servida de uma fonte desatualizada.

E-mail não chega? Verifique primeiro os registos MX; MX em falta ou incorretos significam que nada pode ser entregue. Depois verifique os registos TXT para SPF (v=spf1), DKIM (default._domainkey ou similar) e DMARC (_dmarc.example.com). Os fornecedores de e-mail modernos rejeitam ou colocam em quarentena as mensagens que falham estas verificações, por isso um registo em falta pode mandar silenciosamente as suas mensagens para spam.

Erros de certificado SSL? Verifique se o registo A aponta para o servidor onde o certificado está instalado. Se o site está atrás de uma CDN, o registo A deve resolver para a borda da CDN, não para a origem. Verifique também os registos CAA; um CAA que liste apenas uma autoridade certificadora bloqueará todas as outras de emitir, mesmo quando o proprietário do domínio espera que funcionem.

Verificação de domínio falha? Google Workspace, Microsoft 365, Cloudflare e a maioria das plataformas SaaS pedem que adicione um registo TXT para provar a propriedade do domínio. Consulte os registos TXT para confirmar que a string exata está presente, incluindo quaisquer aspas ou prefixos que a plataforma exigiu.

A propagação DNS parece lenta? Depois de alterar registos, os resolvedores em todo o mundo continuam a servir valores em cache até o TTL expirar. Baixar o TTL para 300 segundos no dia anterior a uma mudança planeada torna a transição muito mais rápida. A ferramenta de consulta mostra o TTL atual ao lado de cada registo, para que possa prever quanto tempo os valores desatualizados ainda vão persistir.

SPF, DKIM e DMARC

Três registos baseados em TXT protegem o e-mail contra falsificação. SPF lista quais servidores estão autorizados a enviar correio pelo seu domínio. DKIM publica uma chave pública que os destinatários usam para verificar a assinatura criptográfica de cada mensagem. DMARC diz aos destinatários o que fazer quando SPF ou DKIM falha: nada, quarentena ou rejeitar. Os três vivem no DNS, os três são consultados em cada mensagem recebida, e um erro de digitação em qualquer um pode paralisar a entregabilidade. Uma ferramenta de consulta DNS é a forma mais rápida de ler o que está realmente publicado, separado do que quer que a interface de configuração afirme.

Aprovisionamento de certificados e CAA

Quando pede um certificado TLS, a autoridade certificadora consulta o DNS para verificar o controlo. A maioria usa o desafio dns-01: pede-lhe para publicar um registo TXT específico em _acme-challenge, depois verifica que apareceu. Os registos CAA adicionam outra camada; declaram quais autoridades podem emitir certificados para o domínio. Um CAA mal configurado pode bloquear renovações legítimas, por isso verifique CAA sempre que um cron do Let's Encrypt deixar de funcionar de repente.

Armadilhas comuns

• Confundir respostas recursivas com autoritativas, o resolvedor do seu ISP pode servir uma cópia em cache que está horas atrás da realidade. A ferramenta de consulta usa o endpoint DNS-over-HTTPS da Cloudflare, que consulta servidores autoritativos diretamente e contorna as caches dos ISP.
• Ignorar o TTL, se o TTL de um registo é 86400 segundos (24 horas), as alterações podem demorar um dia inteiro a serem visíveis em todo o lado. Planeie reduções de TTL um dia antes de qualquer transição.
• CNAME no ápice, os registos CNAME não são permitidos na raiz de uma zona (o próprio example.com). Os fornecedores oferecem registos ALIAS ou ANAME como alternativas, mas não são DNS padrão, por isso o comportamento varia.
• Empilhar vários registos SPF, SPF exige exatamente um registo TXT começando por v=spf1. Dois registos SPF fazem com que os servidores recetores marquem o resultado como PermError, o que afunda a entregabilidade.
• Esquecer o ponto final, em ficheiros de zona, nomes sem ponto final são tratados como relativos à zona, por isso esquecer o ponto transforma mail.example.com em mail.example.com.example.com.
• Misturar registos A IPv4 e IPv6, A é apenas para IPv4. Pôr um endereço IPv6 num registo A (em vez de AAAA) é um erro de configuração que algumas interfaces não detetam.
• Cadeias CNAME em loop, um CNAME apontando para outro CNAME que aponta de volta cria um loop de resolução. Os resolvedores limitam a cadeia a cerca de oito saltos antes de desistir.
• Cache em várias camadas, browser, SO, router e resolvedor cacheiam DNS independentemente. Esvaziar apenas um raramente chega; recorra à ferramenta de consulta para contornar a cadeia completamente.
• Wildcards a mascarar entradas em falta, um registo A wildcard (*.example.com) corresponderá a qualquer subdomínio sem registo explícito, o que pode esconder configurações erradas.
• Confiar em apenas um resolvedor, a propagação é desigual. Consulte vários resolvedores (1.1.1.1, 8.8.8.8, 9.9.9.9) ao verificar uma alteração global.

Outras formas de consultar DNS

A ferramenta de consulta no browser é o caminho mais rápido para a maioria das verificações, mas as ferramentas de linha de comandos dão detalhe mais rico quando precisa.

Cada um tem compromissos. dig +trace percorre a árvore DNS desde as raízes e mostra cada passo, o que é inestimável para provar onde uma cadeia se quebra. nslookup está em todo o lado e serve para verificações rápidas. A ferramenta web ganha em velocidade e em não precisar de terminal de todo.

Privacidade e DNS

As consultas DNS comuns viajam em texto claro, o que significa que o seu ISP e qualquer um na rede podem ver cada domínio que visita. Duas variantes cifradas abordam isto: DNS-over-HTTPS (DoH) envolve as consultas em HTTPS, e DNS-over-TLS (DoT) envolve-as em TLS numa porta dedicada. A ferramenta de consulta usa o endpoint DoH da Cloudflare, por isso a sua consulta ao resolvedor está cifrada em trânsito. O domínio sobre o qual pergunta continua observável pelo próprio resolvedor; se isso o preocupa, execute o seu próprio resolvedor (Unbound, Pi-hole) ou use um serviço pago focado em privacidade que prometa não registar.

As consultas no browser nunca armazenam os seus pedidos nos nossos servidores. O pedido vai do seu browser diretamente para o resolvedor DoH e a resposta renderiza-se do lado do cliente. Não há registo para intimar, nem analítica sobre que domínios verificou, nem nada para vazar numa futura violação. Para uma tarefa tão rotineira como depurar DNS, esse é exatamente o nível de privacidade que o trabalho merece.