Commande dig : requêtes DNS sous Linux et lecture des sorties +short et +trace
Pour vérifier les enregistrements DNS d'un domaine jusqu'à l'en-tête de réponse du serveur DNS, on utilise la commande dig. En interrogeant les enregistrements de example.com par type sur des serveurs AlmaLinux 9 et Debian 12, et en changeant de serveur DNS interrogé, nous avons constaté que status et flags dans l'en-tête de réponse suffisent à distinguer un nom inexistant, un serveur DNS qui n'a pas pu fournir de réponse et une réponse donnée directement par le serveur qui gère les enregistrements.
Les sorties ci-dessous proviennent d'un serveur AlmaLinux 9.8 (compte root) et d'un serveur Debian 12 (compte standard). L'adresse du serveur DNS configuré sur le serveur a été remplacée par la valeur d'exemple 192.0.2.53, et les numéros de version de dig par des valeurs d'exemple.
1️⃣ Utiliser la commande dig
La forme de base est [dig @serveur nom type], et le serveur comme le type peuvent être omis. D'après le manuel officiel, sans serveur, dig interroge le serveur DNS défini dans /etc/resolv.conf, et sans type, il demande l'enregistrement A.
dig example.com; <<>> DiG 9.16.20-RH <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62441
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 62 IN A 104.20.23.154
example.com. 62 IN A 172.66.147.243
;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:18 UTC 2026
;; MSG SIZE rcvd: 72Les lignes qui commencent par un point-virgule sont des commentaires ; celles qui n'en ont pas sont les enregistrements réellement reçus. Ce que montre chaque section figure ci-dessous.
| Sortie | Ce qu'elle affiche |
|---|---|
| ; <<>> DiG 9.16.20-RH <<>> example.com | Version de dig exécutée et arguments saisis |
| ->>HEADER<<- … status: NOERROR, id: 62441 | Code de réponse (status) et numéro de requête (id) |
| flags: qr rd ra | Indicateurs de l'en-tête de réponse — si le serveur qui a répondu a fait une recherche récursive, et s'il gère les enregistrements |
| QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 | Nombre d'enregistrements dans chaque section |
| OPT PSEUDOSECTION · EDNS … udp: 4096 | Informations de l'extension EDNS et taille de réponse (octets) acceptée en UDP |
| QUESTION SECTION | Question envoyée — nom, classe (IN), type d'enregistrement |
| ANSWER SECTION | Enregistrements reçus — nom, TTL (secondes), classe, type et valeur, dans cet ordre |
| Query time: 1 msec | Temps écoulé avant l'arrivée de la réponse |
| SERVER: 192.0.2.53#53(192.0.2.53) | Adresse et numéro de port du serveur DNS qui a répondu |
| WHEN · MSG SIZE rcvd: 72 | Heure de la requête et taille de la réponse reçue (octets) |
Dans la ligne flags, qr signifie réponse, rd récursion demandée et ra récursion disponible (RFC 1035). Avec ra mais sans aa, cette réponse vient d'un serveur DNS qui effectue des recherches récursives, et non du serveur qui gère les enregistrements.
Le 62 de la section ANSWER est le TTL, c'est-à-dire le temps restant (secondes) pendant lequel l'enregistrement peut rester en cache. En posant juste après la même question à 8.8.8.8, on obtenait 300 : le nombre variait selon le moment où chaque serveur DNS l'avait mis en cache.
Si vous faites la même requête avec la Commande nslookup , le code de réponse et le TTL n'apparaissent pas dans la sortie par défaut. Les différences entre les sorties des deux commandes sont les suivantes.
| Comparaison | dig | nslookup |
|---|---|---|
| Code de réponse | Toujours dans status de la ligne HEADER | Seulement en cas d'erreur, sous forme de ligne server can't find |
| TTL | Sur chaque ligne d'enregistrement de ANSWER | Seulement avec -debug |
| Serveur DNS qui a répondu | Ligne SERVER tout en bas | Lignes Server · Address tout en haut |
| Code de sortie pour NXDOMAIN | 0 | 1 |
La version de dig installée se vérifie avec -v. C'était 9.16 sur le serveur AlmaLinux 9 et 9.18 sur le serveur Debian 12.
dig -vDiG 9.16.20-RH2️⃣ Interroger des enregistrements avec dig
Si vous écrivez un type d'enregistrement après le nom, seul cet enregistrement est interrogé. La valeur que contient chaque type et les résultats obtenus dans cet article figurent ci-dessous.
| Type | Contenu | Résultat de la requête |
|---|---|---|
| A | adresse IPv4 | example.com → 104.20.23.154 et 1 autre |
| AAAA | Adresse IPv6 | example.com → 2606:4700:10::6814:179a et 1 autre |
| MX | Serveur de messagerie et priorité | example.com → 0 . (n'accepte aucun e-mail) |
| NS | Serveurs de noms qui gèrent les enregistrements | example.com → hera · elliott.ns.cloudflare.com. |
| TXT | Valeur texte sans format imposé (SPF, etc.) | example.com → v=spf1 -all et 1 autre |
| CNAME | Alias d'un autre nom | www.github.com → github.com. |
| SOA | Serveur de noms principal de la zone et valeurs de temps | example.com → elliott.ns.cloudflare.com. … |
| PTR | Nom associé à une adresse IP (inverse) | -x 8.8.8.8 → dns.google. |
Les serveurs de messagerie se vérifient avec l'enregistrement MX. La requête MX sur example.com a renvoyé une seule ligne [0 .] dans la section ANSWER.
dig example.com MX; <<>> DiG 9.16.20-RH <<>> example.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN MX
;; ANSWER SECTION:
example.com. 300 IN MX 0 .
;; Query time: 5 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:23 UTC 2026
;; MSG SIZE rcvd: 550 est la priorité, et un MX qui n'a qu'un point à la place du nom du serveur de messagerie est un Null MX, qui indique que le domaine n'accepte aucun e-mail (RFC 7505). Le type écrit en minuscules, mx, a donné le même résultat.
Pour ne voir que les lignes d'enregistrement, ajoutez [+noall +answer]. D'après le manuel officiel, +noall désactive toutes les sections de sortie et +answer réactive uniquement la section ANSWER.
dig example.com NS +noall +answerexample.com. 12192 IN NS hera.ns.cloudflare.com.
example.com. 12192 IN NS elliott.ns.cloudflare.com.example.com avait deux serveurs de noms. Ce sont les serveurs de noms faisant autorité qui gèrent directement les enregistrements de example.com.
dig example.com TXT +noall +answerexample.com. 300 IN TXT "v=spf1 -all"
example.com. 300 IN TXT "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"Un enregistrement TXT peut contenir une valeur texte sans format imposé. v=spf1 -all est une valeur SPF qui indique qu'aucun serveur n'a le droit d'envoyer des e-mails au nom de ce domaine.
dig www.github.com CNAME +noall +answerwww.github.com. 291 IN CNAME github.com.www.github.com était un alias (CNAME) de github.com. En interrogeant le même nom sans type, l'enregistrement A de github.com a suivi la ligne CNAME.
Avec +multiline, un enregistrement SOA reçoit à côté de chaque nombre un commentaire avec le nom et la durée, ce qui le rend plus lisible.
dig example.com SOA +multiline +noall +answerexample.com. 1765 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. (
2418004112 ; serial
10000 ; refresh (2 hours 46 minutes 40 seconds)
2400 ; retry (40 minutes)
604800 ; expire (1 week)
1800 ; minimum (30 minutes)
)serial est un numéro de série qui augmente à chaque modification des enregistrements ; refresh, retry et expire sont des valeurs de temps qu'utilise un serveur de noms secondaire pour aligner ses enregistrements sur le principal. minimum est la durée pendant laquelle une réponse sur un nom ou un enregistrement inexistant peut rester en cache.
Quand seules les valeurs vous intéressent, ajoutez +short. Pour l'enregistrement A, il ne restait que les adresses IP, et pour le MX, la priorité et le nom du serveur de messagerie.
dig +short example.com172.66.147.243
104.20.23.154dig google.com MX +short10 smtp.google.com.Si vous ajoutez +stats après [+noall +answer], le temps de requête et la ligne du serveur qui a répondu s'affichent aussi. Avec dig 9.18 sur le serveur Debian 12, le mode d'envoi de la requête, (UDP), apparaissait en fin de ligne SERVER ; dig 9.16 sur le serveur AlmaLinux 9 ne l'indiquait pas.
dig example.com +noall +answer +statsexample.com. 235 IN A 172.66.147.243
example.com. 235 IN A 104.20.23.154
;; Query time: 0 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Thu Oct 29 00:10:26 UTC 2026
;; MSG SIZE rcvd: 723️⃣ Choisir le serveur DNS avec dig et recherche inverse
Si vous écrivez @ et un serveur DNS avant le nom, c'est ce serveur qui est interrogé au lieu du serveur DNS configuré sur le serveur. Avec 8.8.8.8, la ligne SERVER est passée à 8.8.8.8 et ad s'est ajouté à flags.
dig @8.8.8.8 example.com; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61431
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE rcvd: 72ad est l'indicateur signalant que le serveur qui a répondu a vérifié les signatures DNSSEC et jugé fiables les enregistrements de la réponse (RFC 4035). Les réponses du serveur DNS configuré sur le serveur n'avaient pas ad.
Si vous écrivez après @ un serveur de noms obtenu par la requête NS, vous interrogez directement le serveur qui gère les enregistrements de example.com.
dig @elliott.ns.cloudflare.com example.com; <<>> DiG 9.16.20-RH <<>> @elliott.ns.cloudflare.com example.com
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61828
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154
;; Query time: 4 msec
;; SERVER: 2606:4700:58::a29f:2ce4#53(2606:4700:58::a29f:2ce4)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE rcvd: 72Cette fois, aa est apparu dans flags, ce qui confirme que le serveur de noms faisant autorité a répondu directement. Comme ce serveur ne prend pas en charge la recherche récursive, qui trouve les noms en passant par d'autres serveurs, ra a disparu et la ligne [WARNING: recursion requested but not available] s'est ajoutée.
(6 servers found) signifie que le nom du serveur de noms a été résolu en trois adresses IPv4 et trois adresses IPv6. La ligne SERVER indiquait celle de ces adresses IPv6 qui a envoyé la réponse.
Si vous écrivez une adresse IP après -x, dig interroge l'enregistrement PTR pour trouver le nom associé à cette adresse.
dig -x 8.8.8.8 +noall +answer8.8.8.8.in-addr.arpa. 300 IN PTR dns.google.dig a interrogé un nom formé en écrivant 8.8.8.8 à l'envers et en ajoutant in-addr.arpa, et la valeur PTR obtenue, dns.google., était le nom de 8.8.8.8.
4️⃣ Le chemin de délégation de dig +trace
Avec +trace, dig interroge dans l'ordre à partir des serveurs de noms racine et affiche, étape par étape, à quel serveur le nom a été délégué. D'après le manuel officiel, +trace demande aussi les lignes de signature DNSSEC ; +nodnssec a donc été ajouté pour ne voir que le chemin de délégation.
dig +trace +nodnssec example.com; <<>> DiG 9.16.20-RH <<>> +trace +nodnssec example.com
;; global options: +cmd
. 86333 IN NS j.root-servers.net.
. 86333 IN NS g.root-servers.net.
. 86333 IN NS b.root-servers.net.
. 86333 IN NS e.root-servers.net.
. 86333 IN NS k.root-servers.net.
. 86333 IN NS f.root-servers.net.
. 86333 IN NS l.root-servers.net.
. 86333 IN NS m.root-servers.net.
. 86333 IN NS h.root-servers.net.
. 86333 IN NS c.root-servers.net.
. 86333 IN NS d.root-servers.net.
. 86333 IN NS a.root-servers.net.
. 86333 IN NS i.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 1 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 836 bytes from 2001:7fd::1#53(k.root-servers.net) in 30 ms
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.
;; Received 359 bytes from 2001:503:d414::30#53(f.gtld-servers.net) in 66 ms
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Received 72 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 3 msÀ chaque étape, la dernière ligne [Received … from] indique le serveur qui a envoyé cette réponse. Les serveurs interrogés aux quatre étapes et ce qui a été reçu figurent ci-dessous.
| Niveau | Serveur interrogé | Reçu |
|---|---|---|
| 1 | Serveur DNS configuré sur le serveur (192.0.2.53) | 13 serveurs de noms racine (.) |
| 2 | k.root-servers.net | 13 serveurs de noms .com (gtld-servers.net) |
| 3 | f.gtld-servers.net | 2 serveurs de noms de example.com |
| 4 | elliott.ns.cloudflare.com | 2 enregistrements A de example.com |
La sortie de +trace ressemble au suivi d'une lettre recommandée.
L'enregistrement A de la dernière étape a été envoyé directement par le serveur de noms de example.com : c'est donc la valeur actuelle, sans passer par un cache. Juste après un changement de serveurs de noms, vérifiez d'abord à l'étape 3 si les serveurs .com répondent avec les nouveaux serveurs de noms.
5️⃣ Erreurs de réponse et options de dig
🔲 Erreurs de réponse
Si vous interrogez un nom qui n'existe pas, status indique NXDOMAIN. .invalid est un domaine de premier niveau réservé pour ne jamais être réellement utilisé ; il a donc servi à vérifier cette réponse.
dig example.invalid; <<>> DiG 9.16.20-RH <<>> example.invalid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23779
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.invalid. IN A
;; AUTHORITY SECTION:
invalid. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE rcvd: 96ANSWER valait 0, et la section AUTHORITY contenait l'enregistrement SOA de la zone. Le dernier nombre du SOA, 10800, est la durée (secondes) pendant laquelle cette réponse peut rester en cache.
no-such-host.example.com s'est terminé avec status NOERROR et ANSWER 0 au lieu de NXDOMAIN. C'est une réponse sans code d'erreur où seuls les enregistrements manquent : vérifiez donc status et le nombre sous ANSWER ensemble.
dig no-such-host.example.com; <<>> DiG 9.16.20-RH <<>> no-such-host.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;no-such-host.example.com. IN A
;; AUTHORITY SECTION:
example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800
;; Query time: 7 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE rcvd: 115SERVFAIL est le code de réponse indiquant que le serveur DNS n'a pas pu produire de réponse (RFC 1035). En interrogeant 8.8.8.8 sur dnssec-failed.org, un domaine public servant à tester les échecs de validation DNSSEC, on a obtenu SERVFAIL accompagné d'une ligne EDE.
dig @8.8.8.8 dnssec-failed.org; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57521
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;dnssec-failed.org. IN A
;; Query time: 333 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:41 UTC 2026
;; MSG SIZE rcvd: 97EDE est un code d'erreur étendu qui précise la cause de l'erreur (RFC 8914). 9 (DNSKEY Missing) signifie qu'aucune DNSKEY correspondant à l'enregistrement DS de la zone parente n'a été trouvée ; pour un nom dont il ne pouvait pas vérifier la signature, 8.8.8.8 a renvoyé SERVFAIL au lieu d'une adresse.
Quand le serveur DNS ne répond pas, la sortie se termine par [connection timed out; no servers could be reached], sans ligne status. En interrogeant 192.0.2.1, une adresse réservée aux exemples de documentation, avec [+timeout=2 +tries=1], cette ligne est apparue au bout de 2 secondes.
dig @192.0.2.1 example.com +timeout=2 +tries=1; <<>> DiG 9.16.20-RH <<>> @192.0.2.1 example.com +timeout=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reachedSans option, la même adresse a donné la même ligne au bout de 15 secondes. En effet, les valeurs par défaut du manuel officiel sont de 5 secondes par réponse et 3 tentatives. Avec dig 9.18 sur le serveur Debian 12, la ligne [communications error to 192.0.2.1#53: timed out] est apparue d'abord, et la dernière ligne était [no servers could be reached].
Si un script trie les résultats selon le code de sortie, tenez compte du fait que NXDOMAIN renvoie aussi 0. Après une requête +short sur example.invalid, l'affichage du code de sortie a donné 0 avec un résultat vide, tandis que la requête vers 192.0.2.1, restée sans réponse, a donné 9.
dig +short example.invalid; echo $?0Pour chaque erreur de réponse, la ligne à vérifier dans la sortie et ce qu'il faut vérifier ensuite figurent ci-dessous.
| Sortie | Signification | À vérifier ensuite |
|---|---|---|
| status: NXDOMAIN | Ce nom n'existe pas | Orthographe et état d'enregistrement du domaine, chemin de délégation avec +trace |
| status: NOERROR · ANSWER: 0 | Aucun enregistrement de ce type dans la réponse | Type d'enregistrement et configuration des enregistrements du serveur de noms |
| status: SERVFAIL | Le serveur DNS n'a pas pu produire de réponse | Ligne EDE, réponses d'autres serveurs DNS (@8.8.8.8 · @1.1.1.1) |
| connection timed out | Le serveur DNS ne répond pas | Adresse du serveur DNS et pare-feu bloquant le port 53 |
🔲 Options de la commande dig
📌 Options principales : résultats de cet article
| Option | Rôle | Résultat dans cet article | |
|---|---|---|---|
| @serveur | Interroge le serveur indiqué au lieu du serveur DNS configuré sur le serveur | Avec @8.8.8.8, la ligne SERVER passe à 8.8.8.8 et ad s'ajoute à flags ; avec le serveur de noms faisant autorité, aa | |
| Type | N'interroge que le type d'enregistrement écrit après le nom | example.com MX donne une seule ligne [0 .] ; mx en minuscules donne le même résultat | |
| -x adresse | Interroge l'enregistrement PTR d'une adresse IP | -x 8.8.8.8 donne dns.google. | |
| -v | Affiche la version | 9.16 sur le serveur AlmaLinux 9, 9.18 sur le serveur Debian 12 | |
| -r | Ne lit pas le .digrc du dossier personnel | Même avec +short dans .digrc, -r affiche les lignes d'enregistrement complètes | |
| +short | N'affiche que les valeurs des enregistrements | A donne deux adresses IP ; google.com MX donne 10 smtp.google.com. | |
| +noall +answer | Désactive toutes les sections de sortie puis réactive uniquement ANSWER | example.com NS ne laisse que les deux lignes de serveurs de noms | |
| +multiline | Répartit les longs enregistrements comme SOA sur plusieurs lignes avec des commentaires | Des noms et durées comme serial et refresh s'ajoutent en commentaire à côté de chaque nombre | |
| +stats | Affiche aussi le temps de requête et la ligne du serveur qui a répondu | Avec dig 9.18 sur le serveur Debian 12, (UDP) en fin de ligne SERVER | |
| +trace | Interroge dans l'ordre à partir des serveurs de noms racine et affiche le chemin de délégation | À chacune des quatre étapes, la dernière ligne [Received … from] indique le serveur qui a répondu | |
| +nodnssec | Ne demande pas les enregistrements de signature DNSSEC | Utilisé avec +trace pour ne garder que le chemin de délégation | |
| +timeout=secondes | Temps d'attente pour une réponse, 5 secondes par défaut | Avec +timeout=2 +tries=1 vers 192.0.2.1, [connection timed out] après 2 secondes ; sans option, 15 secondes | |
| +tries=nombre | Nombre d'envois de la requête, 3 par défaut | Réglé sur 1 avec +timeout=2, dig n'a interrogé qu'une fois et s'est arrêté après 2 secondes | |
| +tcp | Envoie la requête en TCP au lieu d'UDP | Avec dig 9.18 sur le serveur Debian 12, la fin de la ligne SERVER passe de (UDP) à (TCP) et les enregistrements restent identiques |
📎 Autres options : selon le manuel officiel
| Option | Rôle | |
|---|---|---|
| -4 | Interroge uniquement en IPv4 | |
| -6 | Interroge uniquement en IPv6 | |
| -t type | Indique le type d'enregistrement à interroger | |
| -q nom | Indique le nom à interroger, pour qu'il ne soit pas confondu avec d'autres arguments | |
| -p port | Interroge le port indiqué au lieu du port 53 | |
| -b adresse | Indique l'adresse IP source depuis laquelle la requête est envoyée | |
| -f fichier | Exécute dans l'ordre les requêtes écrites une par ligne dans un fichier | |
| +norecurse | Interroge avec la demande de récursion (RD) désactivée | |
| +dnssec | Demande aussi les enregistrements DNSSEC | |
| +nssearch | Trouve les serveurs de noms faisant autorité et affiche l'enregistrement SOA de chacun | |
| +nocmd | Affiche sans les lignes de version et d'options du début | |
| +nocomments | Affiche sans les lignes de commentaire comme l'en-tête de réponse et les noms de section | |
| +ttlunits | Affiche le TTL en unités s, m, h, d et w | |
| +retry=nombre | Nombre de renvois sans compter la première requête, 2 par défaut |
🔲 Simulateur de la commande dig
Dans le simulateur ci-dessous, vous pouvez saisir dig vous-même en changeant le type d'enregistrement, le serveur DNS et les options de sortie.
🔢 FAQ & contenus recommandés
Outils · domaines
Recherche WHOIS de domaine · vérification des serveurs de noms
Un outil de recherche qui affiche directement dans votre navigateur les informations d'enregistrement, les serveurs de noms et les enregistrements DNS d'un domaine saisi.
Réseau · DNS
Commande host sous Linux | commande de requête DNS
La commande host, pour trouver l'adresse IP d'un nom d'hôte ou retrouver le nom d'hôte d'une adresse IP.
ℹ️ Mention d'affiliation
Le contenu de ce site contient des liens d'affiliation. Lorsqu'un visiteur achète un produit ou un service via l'un de ces liens, le site perçoit une commission du vendeur. Le montant payé par l'acheteur(il baisse lors des promotions ↓), lui, n'augmente pas. Les prix, remises et stocks indiqués correspondent à la date de rédaction et peuvent différer ; vérifiez-les donc auprès du vendeur avant d'acheter. Les produits sont choisis et évalués selon nos propres critères, et les commissions n'influencent ni l'ordre de présentation ni le contenu des évaluations.