Comando dig: consultas DNS no Linux e como ler a saída de +short e +trace

Q: 📌 Que pacote instalo quando aparece dig: command not found?

Nos dois servidores conferidos, o dig estava no pacote bind-utils do AlmaLinux 9 e no pacote bind9-dnsutils do Debian 12. Por isso, instale com [sudo dnf install bind-utils] na família RHEL e com [sudo apt install bind9-dnsutils] na família Debian. Os dois pacotes também instalam o nslookup.

Q: 📌 Como evitar adicionar as mesmas opções toda vez que executo o dig?

Segundo o manual oficial, o dig lê as opções escritas no arquivo .digrc da pasta pessoal e as aplica antes dos argumentos da linha de comando. Com uma linha +short no .digrc, [dig example.com] mostrou só os endereços IP; com -r, o .digrc não foi lido e as linhas de registro saíram completas.

Q: 📌 Como consultar por TCP em vez de UDP?

Com +tcp, a consulta é enviada por TCP. No dig 9.18 do servidor Debian 12, ao adicionar +tcp o fim da linha SERVER mudou de (UDP) para (TCP), e os registros recebidos foram os mesmos.

Ambiente de testeFamília RHELAlmaLinux 9.8dig 9.16conta rootDebian 12 · dig 9.18 conta comumVerificado em 2026-11-04

Comandos de rededigLocalização/usr/bin/dig

Para conferir os registros DNS de um domínio até o cabeçalho de resposta do servidor DNS, use o comando dig. Ao consultar os registros de example.com por tipo em servidores AlmaLinux 9 e Debian 12 e trocar o servidor DNS consultado, verificamos que só o status e os flags do cabeçalho de resposta já bastam para distinguir um nome que não existe, um servidor DNS que não conseguiu dar uma resposta e uma resposta dada diretamente pelo servidor que gerencia os registros.

A saída abaixo foi obtida em um servidor AlmaLinux 9.8 (conta root) e em um servidor Debian 12 (conta comum). O endereço do servidor DNS configurado no servidor foi trocado pelo valor de exemplo 192.0.2.53, e os números de versão do dig também por valores de exemplo.

Sumário

8 min de leitura

1️⃣ Como usar o comando dig

↪️ Como ler a saída padrão

A forma básica é [dig @servidor nome tipo], e o servidor e o tipo podem ser omitidos. Segundo o manual oficial, sem servidor ele consulta o servidor DNS definido em /etc/resolv.conf, e sem tipo consulta o registro A.

dig example.com

; <<>> DiG 9.16.20-RH <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62441
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		62	IN	A	104.20.23.154
example.com.		62	IN	A	172.66.147.243

;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:18 UTC 2026
;; MSG SIZE  rcvd: 72

As linhas que começam com ponto e vírgula são comentários, e as linhas sem ponto e vírgula são os registros realmente recebidos. O que cada seção mostra está abaixo.

Saída	O que mostra
; <<>> DiG 9.16.20-RH <<>> example.com	Versão do dig executada e argumentos digitados
->>HEADER<<- … status: NOERROR, id: 62441	Código de resposta (status) e número da consulta (id)
flags: qr rd ra	Flags do cabeçalho de resposta — se o servidor que respondeu fez consulta recursiva e se é o servidor que gerencia os registros
QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1	Quantidade de registros em cada seção
OPT PSEUDOSECTION · EDNS … udp: 4096	Informações da extensão EDNS e tamanho de resposta (bytes) que pode ser recebido por UDP
QUESTION SECTION	Pergunta enviada — nome, classe (IN), tipo de registro
ANSWER SECTION	Registros recebidos — nome, TTL (segundos), classe, tipo e valor, nessa ordem
Query time: 1 msec	Tempo até a resposta chegar
SERVER: 192.0.2.53#53(192.0.2.53)	Endereço e número da porta do servidor DNS que respondeu
WHEN · MSG SIZE rcvd: 72	Horário da consulta e tamanho da resposta recebida (bytes)

Na linha flags, qr significa resposta, rd pedido de consulta recursiva e ra suporte a consulta recursiva (RFC 1035). Como há ra mas não há aa, essa resposta veio de um servidor DNS que faz consultas recursivas, e não do servidor que gerencia os registros.

O 62 da seção ANSWER é o TTL, o tempo restante (segundos) em que o registro pode ficar em cache. Ao perguntar o mesmo nome ao 8.8.8.8 logo depois, saiu 300, ou seja, o número variava conforme o momento em que cada servidor DNS guardou o registro em cache.

Se você fizer a mesma consulta com o comando nslookup , o código de resposta e o TTL não aparecem na saída padrão. As diferenças entre as saídas dos dois comandos estão abaixo.

Comparação	dig	nslookup
Código de resposta	Sempre no status da linha HEADER	Só em caso de erro, como linha server can't find
TTL	Em cada linha de registro de ANSWER	Só com -debug
Servidor DNS que respondeu	Linha SERVER no fim	Linhas Server · Address no topo
Código de saída com NXDOMAIN	0	1

A versão do dig instalada é conferida com -v. Era 9.16 no servidor AlmaLinux 9 e 9.18 no servidor Debian 12.

dig -v

DiG 9.16.20-RH

2️⃣ Consultar registros com o dig

↪️ A, AAAA, MX, NS, TXT, CNAME, SOA

Se você escrever um tipo de registro depois do nome, só esse registro é consultado. O valor que cada tipo guarda e os resultados consultados neste artigo estão abaixo.

Variante	O que guarda	Resultado da consulta
A	endereço IPv4	example.com → 104.20.23.154 e mais 1
AAAA	Endereço IPv6	example.com → 2606:4700:10::6814:179a e mais 1
MX	Servidor de e-mail e prioridade	example.com → 0 . (não recebe e-mail)
NS	Servidores de nomes que gerenciam os registros	example.com → hera · elliott.ns.cloudflare.com.
TXT	Valor de texto sem formato fixo (SPF etc.)	example.com → v=spf1 -all e mais 1
CNAME	Apelido de outro nome	www.github.com → github.com.
SOA	Servidor de nomes principal da zona e valores de tempo	example.com → elliott.ns.cloudflare.com. …
PTR	Nome ligado a um endereço IP (reverso)	-x 8.8.8.8 → dns.google.

Servidores de e-mail são conferidos pelo registro MX. Ao consultar o MX de example.com, a seção ANSWER mostrou uma única linha [0 .].

dig example.com MX

; <<>> DiG 9.16.20-RH <<>> example.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.			IN	MX

;; ANSWER SECTION:
example.com.		300	IN	MX	0 .

;; Query time: 5 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:23 UTC 2026
;; MSG SIZE  rcvd: 55

0 é a prioridade, e um MX com só um ponto no lugar do nome do servidor de e-mail é um Null MX, que indica que o domínio não recebe e-mail (RFC 7505). Escrever o tipo em minúsculas, mx, deu o mesmo resultado.

Para ver só as linhas de registro, adicione [+noall +answer]. Segundo o manual oficial, +noall desliga todas as seções de saída e +answer liga de novo só a seção ANSWER.

dig example.com NS +noall +answer

example.com.		12192	IN	NS	hera.ns.cloudflare.com.
example.com.		12192	IN	NS	elliott.ns.cloudflare.com.

example.com tinha dois servidores de nomes. Esses dois são os servidores de nomes autoritativos que gerenciam diretamente os registros de example.com.

dig example.com TXT +noall +answer

example.com.		300	IN	TXT	"v=spf1 -all"
example.com.		300	IN	TXT	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"

Um registro TXT pode guardar um valor de texto sem formato fixo. v=spf1 -all é um valor SPF que diz que nenhum servidor pode enviar e-mail com este nome de domínio.

dig www.github.com CNAME +noall +answer

www.github.com.		291	IN	CNAME	github.com.

www.github.com era um apelido (CNAME) de github.com. Ao consultar o mesmo nome sem tipo, o registro A de github.com veio logo depois da linha CNAME.

Com +multiline, o registro SOA ganha um comentário com o nome e o tempo ao lado de cada número e fica mais fácil de ler.

dig example.com SOA +multiline +noall +answer

example.com.		1765 IN	SOA elliott.ns.cloudflare.com. dns.cloudflare.com. (
				2418004112 ; serial
				10000      ; refresh (2 hours 46 minutes 40 seconds)
				2400       ; retry (40 minutes)
				604800     ; expire (1 week)
				1800       ; minimum (30 minutes)
				)

serial é um número de série que aumenta a cada alteração dos registros; refresh, retry e expire são valores de tempo que um servidor de nomes secundário usa para sincronizar os registros com o principal. minimum é o tempo em que uma resposta sobre um nome ou registro inexistente pode ficar em cache.

Quando você só precisa dos valores, adicione +short. No registro A ficaram só os endereços IP, e no MX só a prioridade e o nome do servidor de e-mail.

dig +short example.com

172.66.147.243
104.20.23.154

dig google.com MX +short

10 smtp.google.com.

Se você adicionar +stats depois de [+noall +answer], aparecem também o tempo da consulta e a linha do servidor que respondeu. No dig 9.18 do servidor Debian 12, o modo de envio da consulta, (UDP), apareceu no fim da linha SERVER; o dig 9.16 do servidor AlmaLinux 9 não mostrava isso.

dig example.com +noall +answer +stats

example.com.		235	IN	A	172.66.147.243
example.com.		235	IN	A	104.20.23.154
;; Query time: 0 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Thu Oct 29 00:10:26 UTC 2026
;; MSG SIZE  rcvd: 72

3️⃣ Escolher o servidor DNS no dig e consulta reversa

↪️ @servidor, aa, -x

Se você escrever @ e um servidor DNS antes do nome, esse servidor é consultado no lugar do servidor DNS configurado no servidor. Ao perguntar ao 8.8.8.8, a linha SERVER mudou para 8.8.8.8 e ad foi adicionado aos flags.

dig @8.8.8.8 example.com

; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61431
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		300	IN	A	104.20.23.154
example.com.		300	IN	A	172.66.147.243

;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE  rcvd: 72

ad é o flag que indica que o servidor que respondeu verificou as assinaturas DNSSEC e considerou confiáveis os registros da resposta (RFC 4035). As respostas do servidor DNS configurado no servidor não tinham ad.

Se você escrever depois de @ um servidor de nomes vindo da consulta NS, pergunta diretamente ao servidor que gerencia os registros de example.com.

dig @elliott.ns.cloudflare.com example.com

; <<>> DiG 9.16.20-RH <<>> @elliott.ns.cloudflare.com example.com
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61828
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		300	IN	A	172.66.147.243
example.com.		300	IN	A	104.20.23.154

;; Query time: 4 msec
;; SERVER: 2606:4700:58::a29f:2ce4#53(2606:4700:58::a29f:2ce4)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE  rcvd: 72

Desta vez apareceu aa nos flags, confirmando que o servidor de nomes autoritativo respondeu diretamente. Como esse servidor não oferece consulta recursiva, que busca nomes passando por outros servidores, o ra sumiu e a linha [WARNING: recursion requested but not available] foi adicionada.

(6 servers found) significa que o nome do servidor de nomes foi resolvido em três endereços IPv4 e três IPv6. A linha SERVER mostrou, entre eles, o endereço IPv6 que enviou a resposta.

Se você escrever um endereço IP depois de -x, o dig consulta o registro PTR e encontra o nome ligado a esse endereço.

dig -x 8.8.8.8 +noall +answer

8.8.8.8.in-addr.arpa.	300	IN	PTR	dns.google.

O dig consultou um nome formado ao escrever 8.8.8.8 de trás para a frente e adicionar in-addr.arpa, e o valor PTR, dns.google., era o nome de 8.8.8.8.

4️⃣ O caminho de delegação do dig +trace

↪️ Dos servidores de nomes raiz aos servidores de nomes de example.com

Com +trace, o dig pergunta em ordem a partir dos servidores de nomes raiz e mostra, etapa por etapa, para qual servidor o nome foi delegado. Segundo o manual oficial, +trace também pede as linhas de assinatura DNSSEC, por isso +nodnssec foi adicionado para ver só o caminho de delegação.

dig +trace +nodnssec example.com

; <<>> DiG 9.16.20-RH <<>> +trace +nodnssec example.com
;; global options: +cmd
.			86333	IN	NS	j.root-servers.net.
.			86333	IN	NS	g.root-servers.net.
.			86333	IN	NS	b.root-servers.net.
.			86333	IN	NS	e.root-servers.net.
.			86333	IN	NS	k.root-servers.net.
.			86333	IN	NS	f.root-servers.net.
.			86333	IN	NS	l.root-servers.net.
.			86333	IN	NS	m.root-servers.net.
.			86333	IN	NS	h.root-servers.net.
.			86333	IN	NS	c.root-servers.net.
.			86333	IN	NS	d.root-servers.net.
.			86333	IN	NS	a.root-servers.net.
.			86333	IN	NS	i.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 1 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
;; Received 836 bytes from 2001:7fd::1#53(k.root-servers.net) in 30 ms

example.com.		172800	IN	NS	hera.ns.cloudflare.com.
example.com.		172800	IN	NS	elliott.ns.cloudflare.com.
;; Received 359 bytes from 2001:503:d414::30#53(f.gtld-servers.net) in 66 ms

example.com.		300	IN	A	104.20.23.154
example.com.		300	IN	A	172.66.147.243
;; Received 72 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 3 ms

Em cada etapa, a última linha [Received … from] mostra o servidor que enviou essa resposta. Os servidores consultados nas quatro etapas e o que foi recebido estão abaixo.

Nível	Servidor consultado	O que veio
1	Servidor DNS configurado no servidor (192.0.2.53)	13 servidores de nomes raiz (.)
2	k.root-servers.net	13 servidores de nomes .com (gtld-servers.net)
3	f.gtld-servers.net	2 servidores de nomes de example.com
4	elliott.ns.cloudflare.com	2 registros A de example.com

A saída do +trace é como o rastreamento de uma carta registrada.

O registro A da última etapa foi enviado diretamente pelo servidor de nomes de example.com, então é o valor atual, sem passar por cache. Logo depois de trocar os servidores de nomes, confira primeiro na etapa 3 se os servidores .com respondem com os novos servidores de nomes.

5️⃣ Erros de resposta e opções do dig

↪️ NXDOMAIN, SERVFAIL, connection timed out

🔲 Erros de resposta

Ao consultar um nome que não existe, o status sai como NXDOMAIN. .invalid é um domínio de topo reservado para nunca ser usado de verdade, por isso serviu para conferir essa resposta.

dig example.invalid

; <<>> DiG 9.16.20-RH <<>> example.invalid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23779
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.invalid.		IN	A

;; AUTHORITY SECTION:
invalid.		10800	IN	SOA	localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE  rcvd: 96

ANSWER era 0, e a seção AUTHORITY trazia o registro SOA daquela zona. O último número do SOA, 10800, é o tempo (segundos) em que essa resposta pode ficar em cache.

no-such-host.example.com terminou com status NOERROR e ANSWER 0 em vez de NXDOMAIN. É uma resposta sem código de erro em que só faltam registros, por isso confira o status e o número de ANSWER juntos.

dig no-such-host.example.com

; <<>> DiG 9.16.20-RH <<>> no-such-host.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;no-such-host.example.com.	IN	A

;; AUTHORITY SECTION:
example.com.		1800	IN	SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800

;; Query time: 7 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE  rcvd: 115

SERVFAIL é o código de resposta que indica que o servidor DNS não conseguiu montar uma resposta (RFC 1035). Ao perguntar ao 8.8.8.8 sobre dnssec-failed.org, um domínio público para testar falhas de validação DNSSEC, saiu SERVFAIL junto com uma linha EDE.

dig @8.8.8.8 dnssec-failed.org

; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57521
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;dnssec-failed.org.		IN	A

;; Query time: 333 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:41 UTC 2026
;; MSG SIZE  rcvd: 97

EDE é um código de erro estendido que acrescenta o motivo do erro (RFC 8914). 9 (DNSKEY Missing) significa que não foi encontrada uma DNSKEY que combine com o registro DS da zona superior, e o 8.8.8.8 devolveu SERVFAIL em vez de um endereço para um nome cuja assinatura não conseguia verificar.

Quando o servidor DNS não responde, a saída termina com [connection timed out; no servers could be reached], sem linha de status. Ao perguntar ao 192.0.2.1, um endereço para exemplos de documentação, com [+timeout=2 +tries=1], essa linha apareceu depois de 2 segundos.

dig @192.0.2.1 example.com +timeout=2 +tries=1

; <<>> DiG 9.16.20-RH <<>> @192.0.2.1 example.com +timeout=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Sem opções, o mesmo endereço deu a mesma linha depois de 15 segundos. Isso porque os padrões do manual oficial são 5 segundos por resposta e 3 tentativas. No dig 9.18 do servidor Debian 12, a linha [communications error to 192.0.2.1#53: timed out] veio primeiro, e a última linha foi [no servers could be reached].

Se um script separa resultados pelo código de saída, leve em conta que NXDOMAIN também dá 0. Ao consultar example.invalid com +short e depois mostrar o código de saída, saiu 0 com resultado vazio, enquanto a consulta ao 192.0.2.1, que não respondeu, deu 9.

dig +short example.invalid; echo $?

Para cada erro de resposta, a linha a conferir na saída e o que conferir em seguida estão abaixo.

Saída	Significado	O que verificar em seguida
status: NXDOMAIN	Esse nome não existe	Grafia e situação de registro do domínio, caminho de delegação com +trace
status: NOERROR · ANSWER: 0	Não há registro desse tipo na resposta	Tipo de registro e configuração de registros do servidor de nomes
status: SERVFAIL	O servidor DNS não conseguiu montar uma resposta	Linha EDE, respostas de outros servidores DNS (@8.8.8.8 · @1.1.1.1)
connection timed out	O servidor DNS não responde	Endereço do servidor DNS e firewall bloqueando a porta 53

🔲 Opções do comando dig

📌 Principais opções: resultados deste artigo

Opção	Tarefa	Resultado neste artigo
@servidor	Consulta o servidor indicado no lugar do servidor DNS configurado no servidor	Com @8.8.8.8 a linha SERVER mudou para 8.8.8.8 e ad foi adicionado aos flags; no servidor de nomes autoritativo, aa
Variante	Consulta só o tipo de registro escrito depois do nome	example.com MX deu uma única linha [0 .]; mx em minúsculas deu o mesmo resultado
-x endereço	Consulta o registro PTR de um endereço IP	-x 8.8.8.8 deu dns.google.
-v	Mostra a versão	9.16 no servidor AlmaLinux 9, 9.18 no servidor Debian 12
-r	Não lê o .digrc da pasta pessoal	Mesmo com +short no .digrc, com -r as linhas de registro saíram completas
+short	Mostra só os valores dos registros	A deu dois endereços IP; google.com MX deu 10 smtp.google.com.
+noall +answer	Desliga todas as seções de saída e liga de novo só ANSWER	example.com NS deixou só as duas linhas de servidores de nomes
+multiline	Divide registros longos como SOA em várias linhas com comentários	Nomes e tempos como serial e refresh aparecem como comentário ao lado de cada número
+stats	Mostra também o tempo da consulta e a linha do servidor que respondeu	No dig 9.18 do servidor Debian 12, (UDP) no fim da linha SERVER
+trace	Pergunta em ordem a partir dos servidores de nomes raiz e mostra o caminho de delegação	Em cada uma das quatro etapas, a última linha [Received … from] mostra o servidor que respondeu
+nodnssec	Não pede os registros de assinatura DNSSEC	Usado com +trace para deixar só o caminho de delegação
+timeout=segundos	Tempo de espera por resposta, padrão 5 segundos	Ao perguntar ao 192.0.2.1 com +timeout=2 +tries=1, [connection timed out] depois de 2 segundos; sem opções, 15 segundos
+tries=vezes	Número de vezes que a consulta é enviada, padrão 3	Com 1 junto de +timeout=2, perguntou só uma vez e terminou depois de 2 segundos
+tcp	Envia a consulta por TCP em vez de UDP	No dig 9.18 do servidor Debian 12, o fim da linha SERVER mudou de (UDP) para (TCP), e os registros foram os mesmos

📎 Outras opções: segundo o manual oficial

Opção	Tarefa
-4	Consulta só por IPv4
-6	Consulta só por IPv6
-t tipo	Define o tipo de registro a consultar
-q nome	Define o nome a consultar, para não confundir com outros argumentos
-p porta	Consulta pela porta indicada em vez da 53
-b endereço	Define o endereço IP de origem de onde a consulta é enviada
-f arquivo	Executa em ordem as consultas escritas uma por linha em um arquivo
+norecurse	Consulta com o pedido de consulta recursiva (RD) desligado
+dnssec	Pede também os registros DNSSEC
+nssearch	Encontra os servidores de nomes autoritativos e mostra o registro SOA de cada um
+nocmd	Mostra a saída sem as linhas de versão e opções do início
+nocomments	Mostra a saída sem linhas de comentário como o cabeçalho de resposta e os nomes das seções
+ttlunits	Mostra o TTL nas unidades s, m, h, d e w
+retry=vezes	Número de reenvios sem contar a primeira consulta, padrão 2

🔲 Simulador do comando dig

No simulador abaixo, você pode digitar o dig por conta própria trocando o tipo de registro, o servidor DNS e as opções de saída.

Simulador do comando digdig 9.16

[root@server work]#

Funciona só no seu navegador; as respostas vêm de um DNS virtual com valores de consultas reais, e ↑↓ traz de volta os comandos digitados antes.

🔢 FAQ & conteúdo recomendado

Nos dois servidores conferidos, o dig estava no pacote bind-utils do AlmaLinux 9 e no pacote bind9-dnsutils do Debian 12. Por isso, instale com [sudo dnf install bind-utils] na família RHEL e com [sudo apt install bind9-dnsutils] na família Debian. Os dois pacotes também instalam o nslookup.

Segundo o manual oficial, o dig lê as opções escritas no arquivo .digrc da pasta pessoal e as aplica antes dos argumentos da linha de comando. Com uma linha +short no .digrc, [dig example.com] mostrou só os endereços IP; com -r, o .digrc não foi lido e as linhas de registro saíram completas.

Com +tcp, a consulta é enviada por TCP. No dig 9.18 do servidor Debian 12, ao adicionar +tcp o fim da linha SERVER mudou de (UDP) para (TCP), e os registros recebidos foram os mesmos.

🔝 Comandos Linux

🔗 Conteúdo recomendado

Propagação de DNS Tempo de propagação de DNS após trocar os servidores de nomes: medições por resolvedor e verificação de DNSSEC Artigo que registrou a cada 5 minutos as respostas de 7 resolvedores depois da troca de servidores de nomes e verificou por que o DNSSEC precisa ser desligado antes da mudança. Ver post →

Desligar o DNSSEC para trocar os servidores de nomes (estado ativado)

Exemplo de consulta WHOIS de domínio (naver)

Ferramentas · Domínio Consulta WHOIS de domínio · verificação de nameservers Ferramenta de consulta que mostra na hora, no seu navegador, os dados de registro, os servidores de nomes e os registros DNS de um domínio digitado.

Conferir um registro A com o uso básico do comando host – igual ao comando nslookup

Rede · DNS Comando host no Linux | comando de consulta DNS O comando host, para encontrar o endereço IP de um nome de host ou converter um endereço IP em nome de host.

DNS · Conceitos Servidor de nomes e DNS: diferenças & os 4 principais tipos de registro DNS Artigo que resume como servidores de nomes e DNS se diferenciam e o que guarda cada um dos quatro tipos de registro DNS mais usados.

🪐ReferênciasDocumentação oficial / RFC

📡dig — manual oficial do BIND 9 (ISC) 📡dig(1) — manual do bind9-dnsutils no Debian 12 📡RFC 1035 — formato das mensagens DNS e flags do cabeçalho (IETF) 📡RFC 4035 — DNSSEC e o flag AD (IETF) 📡RFC 7505 — Null MX para domínios que não recebem e-mail (IETF) 📡RFC 8914 — Extended DNS Errors(EDE) (IETF) 📡RFC 2606 — nomes reservados example.com e .invalid (IETF)

ℹ️ Aviso de afiliados
O conteúdo deste site contém links de afiliados. Quando um visitante compra um produto ou serviço por meio de um desses links, o site recebe uma comissão do vendedor. O valor que o comprador paga^{(em promoções, ele diminui ↓)} não aumenta por causa disso. Preços, descontos e informações de estoque valem para o momento em que o texto foi escrito e podem ter mudado, por isso confirme com o vendedor antes de comprar. Os produtos são escolhidos e avaliados por critérios próprios, e o recebimento de comissão não influencia a ordem de apresentação nem o conteúdo das avaliações.