Je me demande s'il existe un moyen d'interroger un serveur DNS et de contourner la mise en cache (avec dig ). Souvent, je modifie une zone sur le serveur DNS et je veux vérifier si elle se résout correctement depuis mon poste de travail. Mais comme le serveur met en cache les requêtes résolues, je reçois souvent les anciennes. Le redémarrage ou le chargement du serveur n'est pas vraiment une bonne chose.
Réponses
Trop de publicités?
Vous pouvez utiliser le @ pour rechercher le domaine 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.comVous pouvez trouver les serveurs faisant autorité en demandant l'adresse NS pour un domaine :
dig example.com NS
Jon Erickson
Points
29643
Il n'existe 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 incluent un moyen de dire à un serveur de ne pas utiliser la récursion, mais ce n'est pas ce que vous voulez. Cela n'est utile que lorsque vous voulez interroger directement un serveur de noms faisant autorité.
Si vous souhaitez empêcher un serveur de noms de répondre à partir de son cache, vous ne pourrez 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, obtenir des fouilles pour contournement les serveurs de noms configurés, et effectue sa propre requête récursive qui retourne aux serveurs racine. Pour ce faire, utilisez l'option +trace option.
dig example.com +traceEn pratique, comme cette méthode n'interroge que les serveurs faisant autorité et non votre résolveur de cache local, le résultat ne sera pas périmé, même si ces serveurs utilisent un cache interne. L'avantage supplémentaire de l'utilisation de +trace c'est que vous pouvez voir toutes les demandes distinctes faites le long du chemin.
c0ntr1but3
Points
231
Il y a une chose importante à noter ici, que j'ai remarqué que beaucoup de gens ne mentionnent jamais lorsqu'ils parlent de l'UE. +trace est qu'en utilisant +trace signifie que le client dig effectuera le traçage, et non le serveur DNS spécifié dans votre configuration (/etc/resolv.conf). En d'autres termes, votre client dig fonctionnera comme un serveur DNS récursif, si vous le lui demandez. Mais - et c'est important - vous n'avez pas de cache.
Plus de détails - donc si vous avez déjà demandé une mx enregistrer en utilisant dig -t mx example.com et que votre /etc/resolv.conf est 8.8.8.8, tout ce qui est fait à l'intérieur du TTL de la zone renverra le résultat mis en cache. D'une certaine manière, si vous cherchez quelque chose sur votre propre zone et sur la façon dont Google la voit, vous avez en quelque sorte empoisonné vos résultats DNS avec Google pour le TTL de votre zone. Ce n'est pas si mal si vous avez un TTL court, mais c'est un peu nul si vous avez un TTL d'une heure.
Ainsi, alors que +trace vous aidera à voir ce qui serait vu si vous interrogiez Google pour la PREMIÈRE fois et qu'il n'y avait pas d'entrée en cache, il peut vous donner une fausse idée que Google dira à tout le monde la même chose que ce que votre +trace ce qui ne sera pas le cas si vous l'avez demandé précédemment et que vous avez une longue TTL, car il servira le résultat à partir du cache jusqu'à ce que la TTL expire. +trace révélé.
On ne peut pas avoir trop de détails.
Michael Cole
Points
442
Ce bash va extraire les entrées DNS de example.com à partir du premier serveur de nom listé :
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer- La recherche intérieure interroge le DNS de Google (8.8.8.8) pour obtenir les serveurs de noms de d'exemple.com.
- La recherche extérieure interroge le premier serveur de noms de example.com.
Voici la même chose qu'un alias pour un .zshrc (et probablement un .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 msCette solution est suffisamment compliquée pour ne pas être facile à retenir, mais suffisamment simple pour que le problème ne soit pas réglé. dig n'est pas ma spécialité - les améliorations sont les bienvenues :-)
Jack
Points
11
