Forcer la résolution à 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 de zone sur le serveur DNS et je veux vérifier si la résolution est correcte à partir de mon poste de travail. Mais puisque le serveur met en cache les requêtes résolues, je récupère souvent les anciennes. Redémarrer ou charger le serveur n'est pas vraiment une bonne chose.

Vous pouvez utiliser la @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 NSenregistrements d'un domaine:

dig example.com NS

Le protocole DNS ne prévoit aucun mécanisme 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, à l'aide de requêtes DNS standard. DNS ne comprend une façon de dire un serveur de ne pas utiliser la récursivité, mais ce n'est pas ce que vous voulez. Ce n'est utile que lorsque vous souhaitez 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, cela est impossible.

Vous pouvez toutefois obtenir dig pour contourner les serveurs de noms configurés et exécuter sa propre requête récursive qui renvoie aux serveurs racine. Pour ce faire, utilisez l' +traceoption.

dig example.com +trace

En pratique, dans la mesure où 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 de l'utilisation +traceest que vous obtenez de voir toutes les demandes séparées effectuées le long du chemin.

Un point important à noter ici, et que je remarque que beaucoup de gens n’incluent jamais, +tracec’est que l’utilisation de +tracemoyens signifie que le client Dig effectuera 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 lui demandez. Mais surtout, vous n'avez pas de cache.

Plus de détails - donc si vous avez déjà demandé un mxenregistrement en utilisant dig -t mx example.comet que votre fichier /etc/resolv.conf est 8.8.8.8, toute action dans la durée de vie de la zone renverra le résultat mis en cache. En un sens, si vous recherchez quelque chose à propos de votre propre zone et de la façon dont Google la voit, vous avez en quelque sorte empoisonné vos résultats DNS avec Google pour la durée de vie de votre zone. Pas mal si vous avez un TTL court, un peu nul si vous avez une heure.

Ainsi, même si +tracecela vous aidera à voir ce qui SERAIT vu si vous demandiez à Google pour la PREMIÈRE fois et qu'il n'avait pas d'entrée en mémoire cache, cela peut vous donner une idée fausse que Google dira à tout le monde la même chose que votre +tracerésultat, lequel ce ne sera pas le cas si vous aviez déjà demandé et si vous avez une longue durée de vie, car cela servira cela depuis le cache jusqu'à l'expiration de la durée de vie - ALORS cela servira la même chose que ce que vous avez +tracerévélé.

Vous ne pouvez pas avoir trop de détails IMO.

Cette bash va extraire les entrées DNS d’exemple.com à partir de son premier serveur de noms:

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer

• Le noyau interne interroge le DNS de Google (8.8.8.8) pour obtenir les serveurs de noms example.com.
• Le serveur externe de prénoms example.com interroge le serveur externe.

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 assez simple pour que le problème ne soit pas résolu. dign'est pas ma spécialité - améliorations bienvenues :-)