O site deixou de abrir para metade dos clientes, os emails caem no spam, ou mudou-se o servidor ontem e ainda há quem veja a versão antiga. Muitas vezes o problema está no DNS, o sistema que traduz nomes como example.com em endereços IP. E a ferramenta para o ver por dentro é o dig.
Neste guia percorremos o dig (domain information groper) de ponta a ponta: ler a resposta completa, pedir cada tipo de registo, escolher o servidor e seguir uma resolução desde a raiz, moldar a saída para scripts e fazer consultas inversas. Os exemplos usam endereços de documentação; use-o sempre em domínios seus ou com autorização.
Veja o guia em vídeo
Prefere ver antes de experimentar? No canal HJFR-IT no YouTube mostramos o dig opção a opção, com o resultado de cada comando no ecrã — narrado em português e com legendas.
O que faz o dig
O dig envia uma pergunta a um servidor de nomes e mostra a resposta tal como chega, sem interpretações. Por omissão pergunta ao servidor definido em /etc/resolv.conf e pede o registo A (endereço IPv4). Em Debian e Ubuntu vem no pacote bind9-dnsutils.
dig [@servidor] [opções] nome [tipo] [+modificadores]
dig example.com # registo A, servidor do resolv.conf
dig example.com MX # outro tipo de registo
dig @192.0.2.53 example.com # outro servidorAlém das opções com hífen (-x, -f), há os modificadores com o sinal de mais (+short, +trace), que aceitam a forma negativa com no (+nostats).
A consulta básica e a anatomia da resposta
A forma mais simples é dig seguido do domínio. A resposta é verbosa, mas cada bloco conta uma parte da história:
$ dig example.com
; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32036
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 3600 IN A 192.0.2.10
;; Query time: 51 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Sat Oct 24 10:15:12 WEST 2026
;; MSG SIZE rcvd: 56As secções da resposta
- HEADER — comece pelo
status:NOERROR,NXDOMAIN(o nome não existe) ouSERVFAIL(o servidor não conseguiu responder). Asflagsdizem como a resposta foi obtida:rd/ra(recursão pedida e disponível),aa(resposta autoritativa),ad(validada com DNSSEC). - QUESTION SECTION — repete o que perguntámos: nome, classe (
IN) e tipo. - ANSWER SECTION — o registo encontrado. O número antes do
INé o TTL: os segundos durante os quais a resposta pode ficar em cache antes de ser pedida de novo. - Estatísticas — o
Query timediz quanto demorou e oSERVERquem respondeu. Servida pela cache, uma segunda consulta demora quase zero e mostra o TTL a descer.
+short: só o essencial
Quando só interessa o valor, o +short corta tudo e devolve apenas os dados de cada registo, um por linha — a forma ideal para scripts:
$ dig +short example.com
192.0.2.10
IP=$(dig +short example.com)Tipos de registo
O DNS não guarda só endereços. Para pedir outro tipo, escreva-o depois do domínio:
A/AAAA— endereço IPv4 (o tipo por omissão) / IPv6.MX— servidores de email, com uma prioridade à frente: o número mais baixo é o preferido.NS— servidores de nomes autoritativos, os que guardam a versão oficial da zona.TXT— texto livre: SPF, DMARC (em_dmarc.domínio), chaves DKIM (emseletor._domainkey.domínio) e verificações de propriedade.CNAME— um alias para outro nome; o resolver segue-o e devolve a cadeia.SOA— dados administrativos da zona (primário, responsável, série, temporizadores).ANY— todos os tipos de uma vez; muitos servidores limitam-no (RFC 8482) e respondem quase em branco.
$ dig +short example.com MX
10 mail.example.com.
20 mx2.example.org.
$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
$ dig +short www.example.com
srv-web01.example.org.
203.0.113.80Escolher o servidor e seguir a resolução
@servidor: comparar respostas
O @ seguido de um IP ou de um nome escolhe a quem perguntar, ignorando o resolv.conf. Se dois resolvers públicos dão respostas diferentes para o mesmo nome, uma alteração de DNS ainda está a propagar-se ou há uma cache desatualizada.
dig +short @198.51.100.53 example.com # 192.0.2.10
dig +short @203.0.113.53 example.com # 198.51.100.10 (ainda o endereço antigo)
dig @ns1.example.com example.com # o autoritativo: flag aa, sem cachePerguntar ao servidor autoritativo dá a verdade sem cache: flag aa e TTL completo. O aviso recursion requested but not available é normal — um autoritativo não faz recursão.
+trace: o DNS em câmara lenta
Com o +trace, o dig faz ele próprio a resolução completa: pergunta aos servidores raiz, que delegam nos do domínio de topo (com.), que delegam nos do domínio, até à resposta final. Cada linha Received … from diz quem respondeu — é assim que se descobre onde a cadeia de delegação falha.
$ dig +trace example.com
. 518400 IN NS a.root-servers.net.
;; Received 525 bytes from 10.0.0.53#53(10.0.0.53) in 3 ms
com. 172800 IN NS a.gtld-servers.net.
;; Received 1170 bytes from 198.51.100.1#53(a.root-servers.net) in 12 ms
example.com. 172800 IN NS ns1.example.com.
;; Received 132 bytes from 192.0.2.30#53(a.gtld-servers.net) in 20 ms
example.com. 3600 IN A 192.0.2.10
;; Received 56 bytes from 192.0.2.53#53(ns1.example.com) in 16 msControlar a saída
Entre a saída completa e o +short há um meio-termo: o +noall desliga todas as secções e o +answer volta a ligar só a resposta, que mantém o nome, o TTL e o tipo.
$ dig +noall +answer example.com MX
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 mx2.example.org.+nocomments— tira os comentários: cabeçalho, flags e títulos das secções.+noquestion— tira a pergunta.+stats/+nostats— mostra ou esconde as estatísticas do fim.+nocmd— esconde a linha inicial com a versão e o comando.+multiline— parte registos longos, como o SOA, num campo por linha, com comentários.
$ dig +noall +answer +multiline example.com SOA
example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
2026102401 ; serial
7200 ; refresh (2 hours)
3600 ; retry (1 hour)
1209600 ; expire (2 weeks)
300 ; minimum (5 minutes)
)Consultas inversas e opções especiais
O -x faz a consulta inversa: do IP para o nome, através do registo PTR. O dig constrói sozinho o nome com o IP ao contrário em in-addr.arpa. Revela a quem pertence um endereço visto nos registos, se este tiver PTR; senão, a resposta é NXDOMAIN.
$ dig +noall +answer -x 192.0.2.25
25.2.0.192.in-addr.arpa. 86400 IN PTR mail.example.com.+tcp— força TCP em vez de UDP, para respostas que não cabem num pacote UDP, como transferências de zona.+dnssec— pede as assinaturas DNSSEC (RRSIG) e liga a flagdo; com a flagad, confirma que a resposta foi validada contra falsificação.-f ficheiro— processa em lote uma lista de consultas, uma por linha, com a mesma sintaxe da linha de comandos.
$ cat consultas.txt
example.com MX
www.example.com
-x 192.0.2.25
$ dig +noall +answer -f consultas.txtdig em cibersegurança
Investigar um email suspeito. Perante uma mensagem que parece vir do seu domínio, o dig responde à triagem inicial: quem recebe o correio (MX), quem pode enviar (SPF, em TXT), que política se aplica a quem falha (_dmarc) e se a chave DKIM publicada corresponde à assinatura. Um dig -x ao IP dos cabeçalhos Received mostra de onde saiu.
Detetar desvios e sequestro de DNS. Um resolver que contradiz o autoritativo pode ter só uma cache por expirar — ou estar adulterado. Comparar respostas com @, seguir a delegação com +trace (um NS alterado no domínio de topo pode indicar uma conta comprometida no agente de registo) e confirmar a flag ad são verificações rápidas numa resposta a incidentes.
Rever a sua própria superfície de ataque. Audite as zonas que gere: CNAME a apontar para serviços desativados (que outra pessoa pode ocupar), TXT esquecidos que revelam sistemas internos, e autoritativos que aceitam transferências de zona a qualquer um. O teste dig @ns1.example.com example.com AXFR deve terminar em Transfer failed.; se devolver a zona inteira, a configuração tem de ser corrigida.
Experimente no simulador interativo
O simulador recria uma rede com o resolver 10.0.0.53, dois resolvers públicos e a zona fictícia example.com, cujo site mudou há pouco de endereço. À esquerda vê o caminho de cada consulta, a resposta e os registos das zonas, com o pedido realçado; à direita, o terminal. Repare no TTL a descer quando a resposta vem da cache. Demonstrar tudo segue o vídeo, Anterior e Seguinte navegam passo a passo e Repor estado volta ao início.
Erros comuns e boas práticas
- Tomar a cache pela verdade: depois de uma alteração, o resolver local pode servir o valor antigo até o TTL expirar. Para ver o que está publicado, pergunte ao autoritativo com
@. - Diagnosticar com
+short: esconde ostatus; uma saída vazia tanto pode serNXDOMAINcomo um nome sem registos desse tipo. - Esquecer que o tipo por omissão é A:
dig example.comnão diz nada sobre o email; peçaMXouTXTexplicitamente. - Procurar o DMARC no sítio errado: está em
_dmarc.domínio, e o DKIM emseletor._domainkey.domínio. - Confiar no
ANYpara inventariar: muitos servidores limitam-no. Peça os tipos um a um ou use-fcom uma lista. - Mudar registos sem baixar o TTL antes: numa migração, reduza o TTL (por exemplo, para 300 s) com a antecedência do TTL antigo, faça a mudança e volte a subi-lo depois.
Conclusão
O dig é a ferramenta definitiva para o DNS: ler a resposta e o TTL, pedir cada tipo de registo, comparar servidores com @, seguir a delegação com +trace, limpar a saída com +noall +answer e fazer consultas inversas com -x. Se o DNS responde bem mas o serviço continua a falhar, o passo seguinte é testar o pedido com o curl e o wget; para ver as consultas DNS a passar na rede, pacote a pacote, veja o artigo sobre o tcpdump.
Workshop — Linha de Comandos Linux
Quer passar da leitura à prática, com exercícios reais e acompanhamento? No workshop Linha de Comandos Linux da HJFR trabalha estes e outros comandos da série — da administração do dia a dia à resposta a incidentes.
Este artigo faz parte da série «Comandos Linux, um a um» do blog HJFR — fique atento aos próximos comandos.