Forcer Dig à résoudre sans utiliser le cache
Je me demande s'il existe un moyen d'interroger un serveur DNS et de contourner la mise en cache (avec Dig). Souvent, je change une zone sur le serveur DNS et je veux vérifier si elle se résout correctement à partir de mon poste de travail. Mais comme le serveur met en cache les requêtes résolues, j'obtiens souvent les anciennes. Redémarrer ou charger le serveur n'est pas vraiment quelque chose de bien.
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 les enregistrements NS pour un domaine:
Dig example.com NS
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 inclut 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 depuis 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, cela est impossible .
Vous pouvez cependant obtenir Dig pour contourner les serveurs de noms configurés et effectuer sa propre requête récursive qui revient aux serveurs racine. Pour ce faire, utilisez le +trace option.
Dig example.com +trace
Dans la pratique, car cela interrogera uniquement les serveurs faisant autorité plutôt que votre résolveur de mise en cache local, le résultat ne sera pas périmé même si ces serveurs utilisent la mise en cache interne. L'avantage supplémentaire d'utiliser +trace signifie que vous pouvez voir toutes les demandes distinctes faites le long du chemin.
Quelque chose d'important à noter ici, que je remarque que beaucoup de gens n'incluent jamais lorsqu'ils parlent de +trace est que l'utilisation de +trace signifie que le client Dig fera la trace, pas 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 demandez. Mais - surtout, vous n'avez pas de cache.
Plus de détails - donc si vous avez déjà demandé un enregistrement mx en utilisant Dig -t mx example.com et votre /etc/resolv.conf est 8.8.8.8 puis faire quoi que ce soit à l'intérieur du TTL de la zone retournera le résultat mis en cache. D'une certaine manière, si vous cherchez quelque chose à propos de 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 de détritus si vous en avez une heure.
Alors, tandis que +trace vous aidera à voir ce qui SERAIT vu si vous demandiez à Google pour la première fois et qu'il n'y avait aucune 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 votre TTL est long, car il servira cela du cache jusqu'à ce que le TTL expire - ALORS il servira le même chose que votre +trace révélé.
Ne peut pas avoir trop de détails OMI.
Cette bash va creuser 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 d'exemple.com.
- Le Dig externe interroge le serveur de prénom 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 être difficile à retenir, mais assez simple pour que le problème ne soit pas résolu. Dig n'est pas ma spécialité - les améliorations sont les bienvenues :-)