15 Exemplos Do Comando dig No Linux

A nossa memória tem uma facilidade maior de memorizar nomes do que IP. É mais fácil memorizar o nome de domínio webmaster.pt do que o IP 65.254.41.45.

Ora, os computadores que temos em casa ou no trabalho, os dispositos de rede, como os switch e os routers, e os servidores comunicam entre si através de IP.

Quando usamos um navegador / browser, um cliente de email ou um cliente de FTP, introduzimos nomes de domínios para acedermos remotamente ao respetivo servidor.

O DNS (Sistema De Nome De Domínios) é um sistema de gestão dos nomes de domínios, com uma estrutura hierárquica, através do qual os navegadores / browsers, os clientes de email, os clientes de FTP, convertem esses nomes de domínios em IP.

Para sabermos como é que um nome de domínio está configurado no Sistema de Nome de Domínios (DNS), podemos usar o comando dig no Linux.

Mas, chega de contemplar a realidade. Vamos mergulhar nela mesmo, experimentando com exemplos práticos do dig.

Vamos começar pela forma mais simples do comando dig:


dig webmaster.pt

; <<>> DiG 9.7.0-P1 <<>> webmaster.pt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61904 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;webmaster.pt. IN A ;; ANSWER SECTION: webmaster.pt. 14358 IN A 65.254.41.45 ;; Query time: 18 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 10:08:24 2013 ;; MSG SIZE rcvd: 46

Podemos estruturar o output do comando dig em várias partes:

• versão do dig
• opções globais do comando
• cabeçalho
• pergunta, com cabeçalho
• resposta, com cabeçalho
• estatísticas

Podemos passar várias opções ao dig para eliminar parte da informação que consta do output do dig.

Se corrermos o dig com a opção +nocmd, eliminamos a linha sobre a versão do dig e a linha das opções globais:


dig +nocmd webmaster.pt
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39491 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;webmaster.pt. IN A ;; ANSWER SECTION: webmaster.pt. 8670 IN A 65.254.41.45 ;; Query time: 17 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Jul 21 22:07:04 2013 ;; MSG SIZE rcvd: 46

Vamos agora correr o dig com a opção +nocomments


dig webmaster.pt +nocomments

; <<>> DiG 9.7.0-P1 <<>> webmaster.pt +nocomments
;; global options: +cmd
;webmaster.pt. IN A
webmaster.pt. 3051 IN A 65.254.41.45
;; Query time: 18 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 10:10:55 2013
;; MSG SIZE rcvd: 46


Eliminamos o cabeçalho inicial e os cabeçalhos de cada secção. Temos um output mais elegante, mas com menos informação.

Podemos adicionar a opção +nostats


dig webmaster.pt +nocomments +nostats

; <<>> DiG 9.7.0-P1 <<>> webmaster.pt +nocomments +nostats
;; global options: +cmd
;webmaster.pt. IN A
webmaster.pt. 14400 IN A 65.254.41.45


O output fez uma dieta visível, dado que, para além dos comentários, não apresentou as estatísticas.

Podemos ainda eliminar todas as partes do output com a excepção da resposta, com as opções +noall +answer


dig +noall +answer webmaster.pt
webmaster.pt. 1933 IN A 65.254.41.45


Mas, se quisermos um output minimalista, experimente a opção +short


dig webmaster.pt +short
65.254.41.45


Direto ao ponto! Existe um registo A do nome de domínio webmaster.pt que aponta para o IP 65.254.41.45. Poderiam existir vários registos A do mesmo nome de domínio a apontar para IP diferentes. Veja o exemplo do nome google.com:


dig google.com +short
173.194.45.3
173.194.45.4
173.194.45.5
173.194.45.6
173.194.45.7
173.194.45.8
173.194.45.9
173.194.45.14
173.194.45.0
173.194.45.1
173.194.45.2


dig registo MX

Para verificarmos qual o host name do servidor de email do nome de domínio webmaster.pt, passamos a opção MX ao comando dig:


dig MX webmaster.pt +noall +answer

; <<>> DiG 9.7.0-P1 <<>> MX webmaster.pt +noall +answer
;; global options: +cmd
webmaster.pt. 14400 IN MX 0 webmaster.pt.


Ficamos a saber:

• Perguntamos sobre o nome webmaster.pt.
• O TTL (Time To Live) é 14400 segundos. Exatamente 4 horas.
• Perguntamos pelo tipo de registo MX.
• A prioridade é 0.
• O host name do servidor de mail é webmaster.pt.

Vamos tentar saber os host names dos servidores de mail do google.com:


dig google.com MX +noall +answer

; <<>> DiG 9.7.0-P1 <<>> google.com MX +noall +answer
;; global options: +cmd
google.com. 534 IN MX 50 alt4.aspmx.l.google.com.
google.com. 534 IN MX 10 aspmx.l.google.com.
google.com. 534 IN MX 20 alt1.aspmx.l.google.com.
google.com. 534 IN MX 30 alt2.aspmx.l.google.com.
google.com. 534 IN MX 40 alt3.aspmx.l.google.com.


Caso haja uma falha, a ordem de prioridade é 10, 20, 30, 40 e 50. Se for necessário saber o IP dum destes host names, poderíamos executar o comando:


dig aspmx.l.google.com +short
173.194.78.27


dig registo NS

Os registos NS dum nome de domínio indicam os host names dos servidores que

• guardam os registos de DNS desse nome de domínio
• respondem a perguntas feitas sobre esses registos de DNS

Para conhecermos os registos NS dum domínio, podemos correr o comando:


dig webmaster.pt NS +noall +answer

; <<>> DiG 9.7.0-P1 <<>> webmaster.pt NS +noall +answer
;; global options: +cmd
webmaster.pt. 86400 IN NS ns1.dnsterra.com.
webmaster.pt. 86400 IN NS ns2.dnsterra.com.


• Perguntamos sobre o nome de domínio webmaster.pt.
• O TTL (Time To Live) é 86400 segundos. 24 horas.
• Perguntamos pelo registo NS.
• Existem 2 nameservers, ou seja, 2 servidores de DNS a responder a qualquer query DNS sobre o nome de domínio webmaster.pt.

No caso do google.com, verificamos que o domínio está configurado em 4 servidores de DNS, que respondem a qualquer query DNS com a redundância respetiva.


dig google.com NS +short
ns2.google.com.
ns3.google.com.
ns4.google.com.
ns1.google.com.


O seu computador usa servidores de DNS para converter os domínios a que você tenta aceder no navegador / browser ou no cliente de email para IP. Normalmente, são os dns servers atribuídos pelo seu fornecedor de internet. Também é muito frequente a utilização de DNS servers gratuitos, como os do OpenDNS ou da Google.

DNS gratuitos do OpenDNS


208.67.222.222
208.67.220.220


DNS gratuitos da Google


8.8.8.8
8.8.4.4


Por vezes, para verificar se o DNS dum domínio está bem configurado num dos servidores de DNS desse domínio ou porque existe um cache de DNS e queremos conferir uma alteração dum registo de DNS sem interferências do cache, podemos perguntar diretamente a um dos servidor de DNS do domínio sobre os registo de DNS configurados nesse servidor.

Como vimos anteriormente, o google.com está configurado em 4 servidores de DNS. Vamos fazer uma query a um deles:


dig @ns1.google.com google.com MX +short
40 alt3.aspmx.l.google.com.
10 aspmx.l.google.com.
30 alt2.aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
50 alt4.aspmx.l.google.com.


dig Reverse DNS Lookup

Se quiser fazer um reverse DNS lookup a um IP, para saber qual o respetivo host name, podemos usar o dig com a opção -x

Já conhecemos o registo MX do webmaster.pt. Aponta para o IP 65.254.41.45. Vamos fazer um reverse DNS lookup a esse IP:


dig -x 65.254.41.45 +short
webmaster.pt.


Poderíamos também usar o comando host:


host 65.254.41.45
45.41.254.65.in-addr.arpa domain name pointer webmaster.pt.


dig registo CNAME

O DNS converte nomes de domínios, fáceis de memorizar, em IP, que são os endereços que as máquinas usam para comunicar umas com as outras. Por vezes, temos nomes de domínios que são pseudônimos dum nome de domínio. Isso significa que o registo A deste último nome de domínio também se aplica aos nomes de domínios que são pseudônimos. É mais comum usar a expressão aliases em vez de pseudônimos.

Em vez de criarmos múltiplos registos A para todos estes nomes de domínios, criamos um registo CNAME para todos os pseudônimos e apontamos este registo para o nome de domínio cujo registo A é aplicável.

O nome de domínio webmaster.pt aponta para o IP 65.254.41.45

Os pseudônimos www.webmaster.pt, mail.webmaster.pt, ftp.webmaster.pt também apontam para o mesmo IP. Em vez de criamos registos A para estes subdomínios, criamos registos CNAME que apontam o webmaster.pt.


dig www.webmaster.pt +noall +answer

; <<>> DiG 9.7.0-P1 <<>> www.webmaster.pt +noall +answer
;; global options: +cmd
www.webmaster.pt. 10691 IN CNAME webmaster.pt.
webmaster.pt. 9191 IN A 65.254.41.45

dig mail.webmaster.pt +noall +answer

; <<>> DiG 9.7.0-P1 <<>> mail.webmaster.pt +noall +answer
;; global options: +cmd
mail.webmaster.pt. 14400 IN CNAME webmaster.pt.
webmaster.pt. 9890 IN A 65.254.41.45

dig ftp.webmaster.pt +noall +answer

; <<>> DiG 9.7.0-P1 <<>> ftp.webmaster.pt +noall +answer
;; global options: +cmd
ftp.webmaster.pt. 14400 IN A 65.254.41.45


Qual a vantagem de usar CNAME? Se a logica do DNS é converter um nome de domínio num IP, a utilização de CNAME não torna a pergunta a um servidor de DNS mais lenta? É necessário fazer 2 perguntas em vez duma só. Qual o host name deste nome de domínio? Qual o IP deste host name?

Vamos imaginar que um domínio tem centenas de subdomínios. E há uma alteração de IP. A vantagem é que, no caso duma alteração de IP, apenas precisamos de mudar 1 único IP na zona de DNS do domínio. E, se a cada domínio correspondesse um registo A em vez dum registo CNAME, seria necessário alterar esse mesmo IP centenas de vezes.

Não é possível fazer a alteração do IP em todos esses registos A através dum script, sem que seja necessário alterar cada instância do mesmo IP? Sim. Mas, se considerarmos as ferramentas atualmente existentes, que permitem a alteração de registos na zona de DNS e que são user friendly, a utilização de registos CNAME pode poupar muito tempo no caso da alteração dum IP.

dig TXT record

Para prevenir o email spoofing, muito usado pelos spammers, um nome de domínio pode publicar os hosts que estão autorizados a enviar emails, através dum registo SPF (Sender Policy Framework) no DNS desse nome de domínio.

Assim, quando um servidor de mail recebe um email proveniente dum determinado nome de domínio, pode conferir se o host que enviou esse email está autorizado no registo SPF desse domínio. Caso não esteja, pode rejeitar o email.

Para verificar se um domínio publicou um registo SPF (Sender Policy Framework), podemos perguntar pelos registos TXT:


dig txt webmaster.pt +short
"v=spf1 +a +mx +ip4:65.254.41.45 ?all"


O nome de domínio webmaster.pt autoriza o host 65.254.41.45 a enviar emails.

Dicas Para Usar O Comando dig

Se quiser obter uma resposta abreviada sempre, sem ter que adicionar as opções +noall +answer ao dig, você pode na pasta $HOME/.digrc adicionar a linha

+noall +answer

Experimente:


cd $HOME
touch .digrc
echo "+noall +answer" >> .digrc


E agora teste o comando dig:


dig webmaster.pt
webmaster.pt. 7625 IN A 65.254.41.45