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.
Réponses:
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
+norecurseest recommandé. +recurseest activé par défaut changera parfois la façon dont un serveur DNS interprète entièrement votre question.
+tracemais méfiez-vous de la mise en cache. Andrew B a expliqué comment la mise en cache peut vous tromper en attendant que les serveurs de noms changent.
dig @8.8.8.8 example.com. les enregistrements y apparaissent beaucoup plus rapidement.
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.
+norecurseindique simplement au serveur de noms de renvoyer toutes les informations dont il dispose (y compris les informations mises en cache, le cas échéant), ce qui n’est pas correct. +tracefonctionnera car il suivra la chaîne de récursion jusqu’à un serveur faisant autorité.
+norecurserecommandation car elle confondait le problème.
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.
dig mydomain.com +traceme retourne simplement le resolvdstub qui en résulte 127.0.0.53. Voir github.com/systemd/systemd/issues/5897
+tracedig commence la trace en utilisant le serveur de noms spécifié (par exemple, 8.8.8.8 si c'est ce que vous avez configuré) pour la première recherche (la zone racine), mais utilise ensuite les serveurs de noms renvoyés pour d'autres requêtes. Ainsi, si votre serveur de noms configuré ne fonctionne pas ou ne répond pas correctement à une requête pour les serveurs de noms racine, vous pouvez avoir des problèmes (comme dans le commentaire ci-dessus).
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
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 :-)