DIG: Uma poderosa ferramenta para suas pesquisas DNS – parte 2

Avançando mais um passo com o DIG

Neste artigo, vamos avançar um pouco mais em relação ao que já falarmos na parte 1. Lá, tivemos uma breve introdução ao aplicativo DIG e alguns exemplos de como usá-lo. Agora, vamos abordar mais detalhes e entender melhor cada pedaço de sua mensagem de saída.

Para quem se interessar, recomendo a leitura de dois documentos. Eles contém muito mais informações do que conseguiremos explorar por aqui e trazem maior riqueza de detalhes quando o assunto é DNS. São eles: RFC1034 – CONCEPTS AND FACILITIES, e RFC1035 – DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION. Vale a leitura naquele final-de-semana chuvoso 🙂

Voltando ao DIG, vamos primeiro apresentar uma resposta-modelo para podermos trabalhar em seguida. Segue:

$ dig 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.

;; 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: 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

Gostaria só de reforçar um detalhe: A sintaxe básica do comando é “dig @servidor nome tipo“. Todas as vezes em que omitimos o @servidor, a lista de servidores que consta no /etc/resolv.conf será usada.

 

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.
    • 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

Pode não parecer tão relevante agora, mas quando falarmos (futuramente) sobre Glue Records, essa informação será essencial.

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 letrinhas (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 (Ver: 4.1.1. Header section formatRFC1035):

      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.

Ufa! Por hora é só!

Melhor parar agora para dar uma respirada e esticar as canelas 🙂

Até a próxima!

Fernando Bertasso Figaro

Criador do Site IP-OK

2 comentários em “DIG: Uma poderosa ferramenta para suas pesquisas DNS – parte 2

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *