Consultar o DNS com dig e nslookup

Módulo 8: Segurança e resolução de problemas · Tempo de leitura: 10 minutos

Objetivo de aprendizagem: Depois desta lição, será capaz de consultar registos com dig e nslookup, interrogar um servidor de nomes específico e ler o resultado.

Conceitos-chave: dig, nslookup, Resolve-DnsName, +short, @server, +trace, secções ANSWER e AUTHORITY, estado NOERROR, NXDOMAIN, SERVFAIL, dig -x

Porquê consultar por conta própria?

Um painel mostra o que você preencheu. O que o resto do mundo vê pode ser diferente: talvez outra entidade esteja a gerir o DNS, ou talvez ainda esteja guardada uma resposta antiga numa cache. Com um programa de consulta, faz a mesma pergunta que um browser ou um servidor de correio, e vê a resposta real.

Existem três programas comuns:

Não tem uma janela de comandos à mão? Pode fazer exatamente o mesmo com uma ferramenta dig online (lição 8.3).

A sua primeira pergunta com dig

Abra o Terminal de comando (macOS/Linux) e escreva:

$ dig example.com A

O resultado, em versão reduzida, tem este aspeto:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                  IN      A

;; ANSWER SECTION:
example.com.           2847    IN      A       192.0.2.10

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)

O que deve ler:

• status: a palavra mais importante. Veja a tabela abaixo.
• flags: ad significa que o resolver verificou a resposta com DNSSEC (lição 8.1).
• ANSWER SECTION: os próprios registos. As colunas são as mesmas que numa zona: nome, TTL, classe, tipo, valor.
• TTL (aqui 2847): quantos segundos esta resposta ainda fica na cache do resolver. Se na zona estivesse 3600, então a resposta já tem 753 segundos. Se voltar a perguntar, verá o número a diminuir.
• SERVER: a que resolver perguntou. Em casa, é frequentemente o seu router.

Os três estados que precisa de conhecer

Variantes úteis

Apenas a resposta com +short:

$ dig +short MX example.com
10 mail.example.com.
20 mail2.example.com.

Interrogar outro resolver ou diretamente um servidor de nomes com @. Este é o truque mais importante em caso de problemas. Se perguntar diretamente ao servidor de nomes autoritativo, obtém sempre a resposta mais recente, sem cache:

$ dig +short NS example.com
ns1.hosting.example.
ns2.hosting.example.

$ dig +short A www.example.com @ns1.hosting.example
192.0.2.20

$ dig +short A www.example.com @9.9.9.9
192.0.2.10

Aqui vê de imediato o que se passa: o servidor de nomes já dá o endereço novo (.20), o resolver público ainda tem o antigo na cache (.10). Não precisa de fazer nada, apenas esperar que o TTL expire (módulo 6).

Outros tipos: coloque o tipo depois do nome.

$ dig +short TXT example.com
"v=spf1 a mx include:_spf.hosting.example ~all"
"google-site-verification=AbC123..."

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

$ dig +short CNAME shop.example.com
shops.platform.example.

Seguir todo o trajeto com +trace. O dig faz então o mesmo que um resolver: primeiro a root, depois o TLD, depois o servidor autoritativo (lição 1.4):

$ dig +trace example.com A
.                 518400  IN  NS  a.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53
com.              172800  IN  NS  a.gtld-servers.net.
;; Received 708 bytes from 198.41.0.4#53(a.root-servers.net)
example.com.      172800  IN  NS  ns1.hosting.example.
;; Received 412 bytes from 192.5.6.30#53(a.gtld-servers.net)
example.com.      3600    IN  A   192.0.2.10
;; Received 57 bytes from 198.51.100.53#53(ns1.hosting.example)

Com +trace vê quais os servidores de nomes que a registry realmente indica. Isto é útil quando tem dúvidas se uma alteração de servidor de nomes já foi aplicada.

Ver DNSSEC com +dnssec: recebe também as assinaturas RRSIG. Com +cd desativa a verificação para perceber se um SERVFAIL se deve ao DNSSEC.

DNS inverso com -x (lição 4.6):

$ dig +short -x 192.0.2.25
mail.example.com.

O mesmo com nslookup

O nslookup funciona em qualquer computador. As formas mais importantes:

C:\> nslookup example.com
Server:  router.lan
Address:  192.168.1.1

Non-authoritative answer:
Name:    example.com
Address:  192.0.2.10

C:\> nslookup -type=mx example.com
example.com    MX preference = 10, mail exchanger = mail.example.com

C:\> nslookup -type=txt _dmarc.example.com 9.9.9.9

Um segundo endereço depois do nome (aqui 9.9.9.9) é o servidor que está a interrogar, tal como o @ no dig. "Non-authoritative answer" significa apenas que a resposta vem de um resolver e não do servidor de nomes autoritativo: isso é normal. Se o nome não existir, o nslookup diz Non-existent domain, o que é o mesmo que NXDOMAIN.

Windows PowerShell: Resolve-DnsName

PS> Resolve-DnsName example.com -Type MX
PS> Resolve-DnsName _dmarc.example.com -Type TXT -Server 9.9.9.9
PS> Resolve-DnsName example.com -Type A -DnsOnly

Limpar a sua própria cache

Uma ferramenta online já vê a resposta nova, mas o seu computador ainda não? Então a resposta antiga está na cache do seu próprio computador ou browser.

• Windows: ipconfig /flushdns na linha de comandos.
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder no Terminal de comando.
• Linux com systemd-resolved: resolvectl flush-caches.
• Browser: uma janela privada, ou o seu telemóvel via 4G/5G com o wifi desligado.

A cache do seu fornecedor ou router não a pode limpar você mesmo; nesse caso, aguarda que o TTL expire.

Na prática: o aspeto num painel

Na maioria dos painéis não é possível executar dig. Por isso, utilize o dig em paralelo com o seu painel: primeiro verifique no painel o que preencheu, depois confirme com dig @<o seu servidor de nomes> se o servidor de nomes realmente divulga esse valor, e por fim com dig @9.9.9.9 se o mundo exterior já o vê. O meu WebOké tem um diagnóstico DNS que compara os servidores de nomes entre si; outras entidades têm botões semelhantes de "verificação de DNS".

Resumo

• dig <nome> <tipo> faz a mesma pergunta que um browser ou um servidor de correio; leia primeiro o estado.
• NOERROR com resposta é bom, NOERROR sem resposta significa "o nome existe, o tipo não", NXDOMAIN significa "o nome não existe", SERVFAIL significa "sem resposta fiável".
• Com @server interroga diretamente um determinado resolver ou o servidor de nomes autoritativo; assim vê a diferença entre um erro e uma cache.
• +short, +trace, +dnssec, +cd e -x são as variantes de que mais vai precisar.
• O nslookup e o Resolve-DnsName fazem o mesmo no Windows.

Quiz

Exercício

Exercício Z8.2: dig e nslookup. Consulte com dig, nslookup ou Resolve-DnsName (ou uma ferramenta dig online) três coisas:

1. o estado de um nome que não existe: bestaat-niet-dnscursus.sidn.nl;
2. os registos MX de wikipedia.org, diretamente num dos servidores de nomes de wikipedia.org (procure-o primeiro);
3. o TTL que um resolver público devolve neste momento para o registo A de sidn.nl (pergunte duas vezes, com um minuto de intervalo, e anote ambos os números).

Preencha as respostas.

Para saber mais

Estes artigos descrevem os passos na WebOké; os comandos funcionam da mesma forma em todo o lado.

• Manual DirectAdmin 18.7: O meu domínio ainda não funciona após uma transferência ou alteração
• Quanto tempo demora uma alteração de nameserver ou DNS, e o que fazer se não a conseguir ver?
• Enviar e-mail a partir do seu VPS e configurar o DNS inverso