Solution 1 :
Vous pouvez utiliser le @ syntaxe pour rechercher le domaine à partir d'un serveur particulier. Si le serveur DNS fait autorité pour ce domaine, la réponse ne sera pas un résultat mis en cache.
dig @ns1.example.com example.com
Vous pouvez trouver les serveurs faisant autorité en demandant le NS enregistrements pour un domaine :
dig example.com NS
Solution 2 :
Il n'y a aucun mécanisme dans le protocole DNS pour forcer un serveur de noms à répondre sans utiliser son cache. Dig lui-même n'est pas un serveur de noms, c'est simplement un outil qui transmet votre requête aux serveurs de noms que vous avez configurés, en utilisant des requêtes DNS standard. DNS fait inclure un moyen de dire à un serveur de ne pas utiliser la récursivité, mais ce n'est pas ce que vous voulez. Cela n'est utile que lorsque vous souhaitez interroger directement un serveur de noms faisant autorité.
Si vous vouliez empêcher un serveur de noms de répondre à partir de son cache, vous ne pourriez le faire qu'en modifiant la configuration sur le serveur de noms , mais si vous ne contrôlez pas le serveur de noms, c'est impossible.
Vous pouvez cependant creuser pour contourner les serveurs de noms configurés, et effectue sa propre requête récursive qui remonte aux serveurs racine. Pour cela, utilisez le +trace option.
dig example.com +trace
En pratique, puisque cela n'interrogera que les serveurs faisant autorité plutôt que votre résolveur de mise en cache local, le résultat ne sera pas obsolète même si ces serveurs utilisent la mise en cache interne. L'avantage supplémentaire d'utiliser +trace est que vous pouvez voir toutes les demandes distinctes faites le long du chemin.
Solution 3 :
Quelque chose d'important à noter ici, que je remarque que beaucoup de gens n'incluent jamais lorsqu'ils parlent de +trace est-ce en utilisant +trace signifie que le client dig fera la trace, pas le serveur DNS spécifié dans votre configuration (/etc/resolv.conf). Donc, en d'autres termes, votre client de fouille fonctionnera comme un serveur DNS récursif, si vous le lui demandez. Mais - surtout, vous n'avez pas de cache.
Plus de détails - donc si vous avez déjà demandé un mx enregistrer en utilisant dig -t mx example.com et votre /etc/resolv.conf est 8.8.8.8 alors faire quoi que ce soit à l'intérieur du TTL de la zone renverra le résultat mis en cache. D'une certaine manière, si vous recherchez quelque chose sur votre propre zone et comment Google la voit, vous avez en quelque sorte empoisonné vos résultats DNS avec Google pour le TTL de votre zone. Pas mal si vous avez un TTL court, un peu nul si vous en avez un de 1h.
Ainsi, alors que +trace vous aidera à voir ce qui SERAIT vu si vous demandiez à Google pour la PREMIÈRE fois et qu'il n'y avait pas d'entrée en cache, cela peut vous donner une fausse idée que Google dira à tout le monde la même chose que votre +trace le résultat était, ce qui ne sera pas le cas si vous l'aviez demandé précédemment et que vous aviez un long TTL, car il le servira du cache jusqu'à ce que le TTL expire - ALORS il servira de la même manière que votre +trace révélé.
Je ne peux pas avoir trop de détails IMO.
Solution 4 :
Ce bash creusera les entrées DNS de example.com à partir de son premier serveur de noms répertorié :
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
- La fouille interne interroge le DNS de Google (8.8.8.8) pour obtenir les serveurs de noms de example.com.
- La fouille externe interroge le premier serveur de noms de example.com.
Voici la même chose qu'un alias pour un .zshrc (et probablement .bashrc) :
# e.g. `checkdns google.com`
checkdns () { dig @$(dig @8.8.8.8 $1 ns +short | head -n1) $1 ANY +noall +answer; ping -c1 $1; }
Voici la sortie pour /. :
☀ checkdns slashdot.org dev
-->Server DNS Query
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.dnsmadeeasy.com. slashdot.org ANY +noall +answer
; (2 servers found)
;; global options: +cmd
slashdot.org. 21600 IN SOA ns0.dnsmadeeasy.com. hostmaster.slashdotmedia.com. 2016045603 14400 600 604800 300
slashdot.org. 86400 IN NS ns3.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns4.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns0.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns2.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns1.dnsmadeeasy.com.
slashdot.org. 3600 IN MX 10 mx.sourceforge.net.
slashdot.org. 3600 IN TXT "google-site-verification=mwj5KfwLNG8eetH4m5w1VEUAzUlHotrNwnprxNQN5Io"
slashdot.org. 3600 IN TXT "v=spf1 include:servers.mcsv.net ip4:216.34.181.51 ?all"
slashdot.org. 300 IN A 216.34.181.45
-->Local DNS Query
PING slashdot.org (216.34.181.45) 56(84) bytes of data.
64 bytes from slashdot.org (216.34.181.45): icmp_seq=1 ttl=242 time=33.0 ms
--- slashdot.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.026/33.026/33.026/0.000 ms
Cette solution est suffisamment compliquée pour ne pas être pratique à retenir, mais suffisamment simple pour que le problème ne soit pas résolu. dig n'est pas ma spécialité - améliorations bienvenues :-)