DIG

Introdução
O DIG (Domain Information Groper) é um utilitário que serve para realizarmos pesquisas
de DNS. Ele funciona enviando consultas aos servidores e mostrando as respostas
devolvidas por eles. Só a título de curiosidade, muitas ferramentas do IP-OK usam de
diversas maneiras este aplicativo.

Tipos de registros
Antes de avançarmos para a sintaxe do comando é bom revisarmos os tipos mais
comuns de registros.

• A: Associa um nome a um endereço IP.

• NS: NameServer. Define quais servidores são os autoritativos para o domínio
• SOA: Start-Of-Authority. Detalhes da autoridade do domínio. Descreve o
servidor que tem autoridade sobre a zona, além do contato técnico, número serial
e outros campos de timeout.
• MX: Mail eXchanger. Define os servidores de correio (e prioridade) para o
domínio.
• PTR: Pointer. Retorna o nome associado a um endereço IP.
• CNAME: Canonical NAME. Usados para criar apelidos para o domínio.
• TXT: TeXT. Usados para descrições, comentários, observações de um domínio.
Também são usados para definir configurações de SPF.

Primeiros passos
A sintaxe básica do comando é:

dig @servidor nome tipo

Onde:

• @servidor – é usado para pesquisas em um servidor específico (ex.

ns1.ipok.com.br). Caso o argumento @server não seja informado, os servidores
que constam no /etc/resolv.conf serão usados.
• nome – é o hostname ou domínio que será pesquisado
• tipo – um dos tipos válidos de registros para pesquisa (mx, cname, ns, txt, etc).
Veja um exemplo de saída do comando:

$ dig a ipok.com.br

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> a ipok.com.br

;; global options: +cmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 23616
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ipok.com.br. IN A

;; ANSWER SECTION:
ipok.com.br. 807 IN A 177.66.168.145

;; AUTHORITY SECTION:
ipok.com.br. 86307 IN NS ns2.ipok.com.br.
ipok.com.br. 86307 IN NS ns1.ipok.com.br.

;; ADDITIONAL SECTION:
ns1.ipok.com.br. 86307 IN A 177.66.168.145
ns2.ipok.com.br. 86307 IN A 177.66.168.147

;; Query time: 0 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Qui Jul 14 19:51:17 BRT 2016
;; MSG SIZE rcvd: 113

Opções do comando
O DIG oferece uma série de opções especiais que afetam como as consultas (ou
queries) serão feitas e/ou como o resultado será exibido. Isso é feito utilizando-se um
argumento precedido do sinal “+“. Exemplo:

dig +tcp a ipok.com.br

Em alguns casos, quando a opção é ativa por padrão e se quer desativá-la (por exemplo,
recursividade), usamos o argumento “+no” e a respectiva opção. Exemplo:

dig +norec @ns1.ipok.com.br ipok.com.br a

Exemplos de opções:

• +tcp: Utiliza o protocolo TCP para realizar as queries. Isso significa que a
conexão terá como destino a porta TCP 53 (O padrão é usar o protocolo UDP).
• +rec: Utiliza recursividade. É ativa por padrão. Podemos desativá-la usando o
“+no“.
• +short: Faz com que a saída tenha menos informações adicionais.
• +time=N: Estabelece o timeout da consulta para N segundos.

Faça um teste com a sintaxe:

dig ipok.com.br a

Agora, utilize adicione a opção “+nocmd“, assim:

dig +nocmd ipok.com.br a

Você perceberá que algumas informações de debug do inicio da resposta serão

suprimidos.

Exemplos de uso do DIG

Resolução de nome (A)

$ dig ipok.com.br a

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> ipok.com.br a

;; global options: +cmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 26993
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;ipok.com.br. IN A

;; ANSWER SECTION:
ipok.com.br. 900 IN A 177.66.168.145

;; AUTHORITY SECTION:
ipok.com.br. 36062 IN NS ns1.ipok.com.br.
ipok.com.br. 36062 IN NS ns2.ipok.com.br.

;; ADDITIONAL SECTION:
ns1.ipok.com.br. 70552 IN A 177.66.168.145
ns2.ipok.com.br. 70552 IN A 177.66.168.147

;; Query time: 1 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Qui Jul 14 23:17:34 BRT 2016
;; MSG SIZE rcvd: 124

Pesquisa dos servidores de correio (MX)

$ dig ipok.com.br mx

;; ANSWER SECTION:
ipok.com.br. 900 IN MX 10 mx-
08.mailserverpro.com.br.
Pesquisa dos servidores DNS (NS)

$ dig ipok.com.br ns

;; ANSWER SECTION:
ipok.com.br. 900 IN NS ns1.ipok.com.br.
ipok.com.br. 900 IN NS ns2.ipok.com.br.

Pesquisa da autoridade (SOA)

$ dig ipok.com.br soa

;; ANSWER SECTION:
ipok.com.br. 874 IN SOA ns1.ipok.com.br.
postmaster.ipok.com.br. (
2016062806 ; serial
10800 ; refresh (3 hours)
15 ; retry (15 seconds)
604800 ; expire (1 week)
10800 ; minimum (3 hours)
)

Resolução de Dns Reverso (PTR)

$ dig -x 177.66.168.145

;; ANSWER SECTION:
145.168.66.177.in-addr.arpa. 3600 IN PTR ns1.ipok.com.br.

Pesquisa diretamente em um servidor

dig @ns1.ipok.com.br ipok.com.br a

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> @ns1.ipok.com.br

ipok.com.br a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 60553
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;ipok.com.br. IN A

;; ANSWER SECTION:
ipok.com.br. 900 IN A 177.66.168.145

;; AUTHORITY SECTION:
ipok.com.br. 900 IN NS ns2.ipok.com.br.
ipok.com.br. 900 IN NS ns1.ipok.com.br.

;; ADDITIONAL SECTION:
ns1.ipok.com.br. 900 IN A 177.66.168.145
ns2.ipok.com.br. 900 IN A 177.66.168.147

;; Query time: 0 msec

;; SERVER: 177.66.168.145#53(177.66.168.145)
;; WHEN: Qui Jul 14 23:23:56 BRT 2016
;; MSG SIZE rcvd: 124

SEÇÕES
A resposta padrão de uma consulta DNS é organizada em 5 seções: Header, Question,
Answer, Authority e Additional. Algumas delas sempre estão presentes (como a Header
e Question) e as outras podem não ser exibidas caso o servidor que respondeu a consulta
não as tenha preenchido.

Você mesmo pode optar por não mostrar uma ou outra seção específica (por exemplo,
construindo um script, alguma monitoração, teste automático, etc). Para isso, você deve
usar aquele padrão “+[no]argumento” que vimos no artigo anterior.

Por exemplo, se você usar o argumento “+noheader“, a saída do comando omitirá o bloco
referente à seção “Header“, assim como o “+noanswer” omitirá a seção “Answer“. Isso
é possível de ser feito com todas as seções: +noheader, +noquestion, +noanswer,
+noauthority, +noadditional, +noall.

Neste exemplo, a seção “Additional” foi omitida intencionalmente:

$ dig +noadditional ipok.com.br a

;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 60822
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ipok.com.br. IN A

;; ANSWER SECTION:
ipok.com.br. 900 IN A 177.66.168.145

;; AUTHORITY SECTION:
ipok.com.br. 900 IN NS ns2.ipok.com.br.
ipok.com.br. 900 IN NS ns1.ipok.com.br.

;; Query time: 17 msec

;; SERVER: 177.66.168.145#53(177.66.168.145)
;; WHEN: Sat Jul 16 15:25:22 BRT 2016
;; MSG SIZE rcvd: 113
HEADER

A seção “Header” sempre será exibida nas respostas. Ela contém diversas informações a
respeito da consulta, assim como campos de status e de controle. Os principais são:

• status: indica sucesso da consulta (status: NOERROR) ou então o tipo de erro que
ocorreu com a query.
• flags: indicador das opções de recursividade e indicador de autoridade (flags: qr aa rd).
• contadores: na mesma linha das flags, indicam quantos resultados por seção vieram na
resposta.
o QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 60822

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

Mais adiante vou tratar sobre as mensagens de erro e flags.

QUESTION

Esta seção replica a query que foi enviada para consulta. Neste momento, torna-se
somente informativo, baseado no que foi solicitado.

;; QUESTION SECTION:
;ipok.com.br. IN A

ANSWER

Esta seção contém a resposta para a consulta que foi enviada. Esta, assim como as
próximas, tem um conteúdo dinâmico, ou seja, podem conter inúmeros resultados
dependendo do que foi solicitado.

;; ANSWER SECTION:
ipok.com.br. 900 IN A 177.66.168.145

No exemplo que estamos trabalhando, temos somente um único resultado (que é o registro
“A” do domínio ipok.com.br). Compare o resultado da pesquisa “dig hotmail.com a“.

Perceba que a quantidade de registros exibidos equivale ao indicado no campo-contador

‘ANSWER‘ mostrado logo acima. O mesmo vale para todas as seções – todas tem seus
respectivos contadores de resultados.

AUTHORITY

Traz o conjunto de servidores que respondem com “autoridade” pelo domínio. Na

prática, nada mais é do que os registros “NS” publicados na zona de dns original.
Ainda sobre “autoridade”, podemos dizer que os servidores listados nesta seção são
aqueles que possuem a informação original (ou oficial) sobre o domínio e seus registros
(a, soa, ns, cname, etc). Assim, se vamos realizar uma pesquisa através de um servidor
recursivo, o resultado obtido pode ser aquele que ainda está no cache deste próprio
servidor. Já quando consultamos direto os servidores autoritativos, a informação
retornada é a mais atualizada e fiel possível.

;; AUTHORITY SECTION:
ipok.com.br. 86172 IN NS ns1.ipok.com.br.
ipok.com.br. 86172 IN NS ns2.ipok.com.br.

ADDITIONAL

É uma seção que traz informações auxiliares ou adicionais à pesquisa. No exemplo

trabalhado, podemos ver que o resultado já traz os endereços IP dos servidores de DNS
para o domínio.

;; ADDITIONAL SECTION:
ns1.ipok.com.br. 900 IN A 177.66.168.145
ns2.ipok.com.br. 900 IN A 177.66.168.147

FLAGS – Recursividade e Autoridade

Conforme comentei anteriormente, o bloco “Flags” nos sinaliza a respeito de atributos

como autoridade e recursividade.

;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 60822

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

Este conjunto de letras (aa, rd, ra, etc), são indicadores do estado (ligado/desligado) de
um conjunto independente de bits que compõe a seção “Header“. Ela tem a seguinte
estrutura:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Portanto, o que vemos consolidado como “Flags” na saída do comando são os estados
dos bits acima destacados (com exceção de Opcode e RCODE). Seus significados são:
 • QR: especifica se a mensagem é uma query (0) ou uma resposta (1). Como estamos
avaliando somente as respostas, este bit sempre estará ligado (consequentemente,
sempre veremos a string “qr” no campo “flags“).
• AA: Authoritative Answer. Especifica que o servidor que respondeu à solicitação é
autoritativo para este domínio.
• TC: Truncation. Especifica que a mensagem de resposta está truncada.
• RD: Recursion Desired. Especifica que a query é recursiva, ou seja, que as requisições
devem ser encaminhadas a outros servidores até que o servidor autoritativo seja
encontrado. Por padrão, o DIG sempre envia consultas com este bit ligado.
• RA: Especifica que o servidor que respondeu à requisição suporta consultas recursivas.
• Z: Reservado para uso futuro.

Exemplos de uso de “flags” – servidor autoritativo

$ dig @ns1.ipok.com.br ipok.com.br a

;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 36408
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

Aqui, o servidor respondeu que é o autoritativo para o domínio pesquisado (“aa“). Veja
também que nossa query enviou o bit de recursividade ligado (“rd“, que é ligado por
padrão no DIG). Porém, apesar de solicitarmos recursividade, o servidor não respondeu
de volta com a opção “ra“, ou seja, esse servidor não aceita consultas recursivas. Isso se
prova também com a mensagem de aviso retornada: “recursion requested but not
available“.

Exemplos de uso de “flags” – servidor recursivo

Veja a diferença quando realizamos a consulta para um servidor que aceita recursividade:

$ dig @8.8.8.8 ipok.com.br a

;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 58672
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

Agora, como este servidor não é o autoritativo para o domínio (8.8.8.8 – google-public-
dns-a.google.com, é o dns público do Google), então não temos o bit “aa” ligado. Em
contrapartida, temos o “rd” e o “ra” ligados, uma vez que este servidor aceita consultas
recursivas.

STATUS – Tratamento de erro nas consultas

Vamos voltar um pouco no tópico sobre “Flags” e retomar um campo que não tratamos
naquele momento: “RCODE – Response Code“. Este campo é preenchido pelo servidor
ao enviar sua resposta. Este campo é interpretado pelo DIG e formatado no bloco de
“status:”, também na seção “Header“.

Os valores mais comuns para este campo, são:

• NOERROR (0): Nenhum erro encontrado, ou seja, sucesso.

• SERVFAIL (2): Houve algum problema com o servidor, que não conseguiu processar a
query.
• NXDOMAN (3): Significa que o domínio pesquisado não existe.
• REFUSED (5): O servidor rejeitou a solicitação.

Observação: O status ou nome do erro é exibido no campo ‘status:’. Já o valor entre

parênteses é o valor binário no campo “RCODE”.

Como exemplos do status de sucesso, você pode observar todas as queries utilizadas ao
longo deste artigo. Todas elas foram executadas com o status “NOERROR“.

Exemplo de erro “NXDOMAIN“

$ dig ipok.com.brx a

;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NXDOMAIN, id: 21673
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

Obviamente o domínio “ipok.com.brx” não existe!

Exemplo de erro “REFUSED“

$ dig @ns1.ipok.com.br amazon.com a

;; Got answer:
;; >>HEADER<< opcode: QUERY, status: REFUSED, id: 50871
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Neste caso, estamos enviando uma solicitação para um servidor que não possui
autoridade sobre o domínio pesquisado. Como este servidor não aceita recursividade,
então ele rejeita a solicitação.