Interroger le DNS avec dig et nslookup

Module 8: Sécurité et résolution de problèmes · Temps de lecture : 10 minutes

Objectif de la leçon : après cette leçon, vous saurez interroger des enregistrements avec dig et nslookup, interroger un serveur de noms précis et lire le résultat.

Notions clés : dig, nslookup, Resolve-DnsName, +short, @server, +trace, sections ANSWER et AUTHORITY, statut NOERROR, NXDOMAIN, SERVFAIL, dig -x

Pourquoi interroger vous-même ?

Un panneau d'administration montre ce que vous avez saisi. Ce que le reste du monde voit peut être différent : peut-être qu'une autre partie gère le DNS, peut-être qu'une ancienne réponse se trouve encore dans un cache. Avec un outil d'interrogation, vous posez la même question qu'un navigateur ou un serveur de messagerie, et vous voyez la vraie réponse.

Il existe trois programmes courants :

Vous n'avez pas de fenêtre de commande sous la main ? Vous pouvez faire exactement la même chose avec un outil dig en ligne (leçon 8.3).

Votre première requête avec dig

Ouvrez Terminal (macOS/Linux) et tapez :

$ dig example.com A

Le résultat ressemble, en version abrégée, à ceci :

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

Ce qu'il faut lire :

• status : le mot le plus important. Voir le tableau ci-dessous.
• flags : ad signifie que le résolveur a vérifié la réponse avec DNSSEC (leçon 8.1).
• ANSWER SECTION : les enregistrements eux-mêmes. Les colonnes sont les mêmes que dans une zone : nom, TTL, classe, type, valeur.
• TTL (ici 2847) : le nombre de secondes pendant lesquelles cette réponse reste encore dans le cache du résolveur. Si la zone indiquait 3600, la réponse a donc déjà 753 secondes. Si vous la redemandez, vous voyez ce chiffre décroître.
• SERVER : le résolveur que vous avez interrogé. Chez vous, c'est souvent votre routeur.

Les trois statuts à connaître

Variantes utiles

Seulement la réponse avec +short :

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

Interroger directement un autre résolveur ou un serveur de noms avec @. C'est l'astuce la plus importante en cas de problème. Si vous interrogez directement le serveur de noms faisant autorité, vous obtenez toujours la réponse la plus récente, sans 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

Ici, vous voyez en un coup d'œil ce qui se passe : le serveur de noms donne déjà la nouvelle adresse (.20), le résolveur public a encore l'ancienne en cache (.10). Vous n'avez donc rien à faire, il suffit d'attendre que la TTL soit écoulée (module 6).

Autres types : indiquez le type après le nom.

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

Suivre tout le trajet avec +trace. dig fait alors lui-même ce que fait un résolveur : d'abord la racine, puis le TLD, puis le serveur faisant autorité (leçon 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)

Avec +trace, vous voyez quels serveurs de noms le registre transmet réellement. C'est pratique si vous doutez qu'un changement de serveur de noms a déjà été appliqué.

Voir DNSSEC avec +dnssec : vous obtenez en plus les signatures RRSIG. Avec +cd, vous désactivez la vérification pour voir si un SERVFAIL vient de DNSSEC.

DNS inversé avec -x (leçon 4.6) :

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

La même chose avec nslookup

nslookup fonctionne sur tous les ordinateurs. Les formes les plus 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

Une seconde adresse après le nom (ici 9.9.9.9) est le serveur que vous interrogez, tout comme @ pour dig. « Non-authoritative answer » signifie simplement que la réponse provient d'un résolveur et non du serveur de noms faisant autorité : c'est normal. Si le nom n'existe pas, nslookup indique Non-existent domain, ce qui équivaut à 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

Vider votre propre cache

Un outil en ligne voit déjà la nouvelle réponse, mais pas encore votre ordinateur ? Alors l'ancienne réponse se trouve dans le cache de votre propre ordinateur ou navigateur.

• Windows : ipconfig /flushdns dans l'Invite de commandes.
• macOS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder dans Terminal.
• Linux avec systemd-resolved : resolvectl flush-caches.
• Navigateur : une fenêtre privée, ou votre téléphone via 4G/5G avec le wifi désactivé.

Vous ne pouvez pas vider vous-même le cache de votre fournisseur d'accès ou de votre routeur ; il faut alors attendre que la TTL s'écoule.

En pratique : à quoi cela ressemble-t-il dans un panneau d'administration

Dans la plupart des panneaux, vous ne pouvez pas exécuter dig. Utilisez donc dig en complément de votre panneau : regardez d'abord dans le panneau ce que vous avez saisi, puis vérifiez avec dig @<votre serveur de noms> que le serveur de noms le diffuse bien réellement, et enfin avec dig @9.9.9.9 si le monde extérieur le voit déjà. Mon WebOké dispose d'un diagnostic DNS qui compare les serveurs de noms entre eux ; d'autres fournisseurs proposent des boutons « vérification DNS » similaires.

Résumé

• dig <nom> <type> pose la même question qu'un navigateur ou un serveur de messagerie ; commencez toujours par lire le statut.
• NOERROR avec réponse est bon signe, NOERROR sans réponse signifie « le nom existe, pas le type », NXDOMAIN signifie « le nom n'existe pas », SERVFAIL signifie « aucune réponse fiable ».
• Avec @server, vous interrogez directement un résolveur précis ou le serveur de noms faisant autorité ; vous voyez ainsi la différence entre une erreur et un cache.
• +short, +trace, +dnssec, +cd et -x sont les variantes dont vous aurez le plus souvent besoin.
• nslookup et Resolve-DnsName font la même chose sous Windows.

Quiz

Exercice

Exercice Z8.2 : dig et nslookup. Avec dig, nslookup ou Resolve-DnsName (ou un outil dig en ligne), interrogez trois éléments :

1. le statut d'un nom qui n'existe pas : bestaat-niet-dnscursus.sidn.nl ;
2. les enregistrements MX de wikipedia.org, directement auprès de l'un des serveurs de noms de wikipedia.org (recherchez-les d'abord) ;
3. la TTL qu'un résolveur public renvoie en ce moment pour l'enregistrement A de sidn.nl (interrogez-la deux fois, à une minute d'intervalle, et notez les deux valeurs).

Saisissez les réponses.

Pour aller plus loin

Ces articles décrivent les étapes chez WebOké ; les commandes fonctionnent partout de la même façon.

• Guide DirectAdmin 18.7: Mon domaine ne fonctionne pas encore après un transfert ou une modification
• Combien de temps dure une modification de nameserver ou de DNS, et que faire si vous ne la voyez pas ?
• Envoyer des e-mails depuis votre VPS et configurer le reverse DNS