Ich frage mich, ob es eine Möglichkeit gibt, einen DNS-Server abzufragen und das Caching (mit dig) zu umgehen . Oft ändere ich eine Zone auf dem DNS-Server und möchte überprüfen, ob sie von meiner Workstation aus korrekt aufgelöst wird. Aber da der Server aufgelöste Anfragen zwischenspeichert, bekomme ich oft die alten. Ein Neustart oder -laden des Servers ist nicht wirklich nett.
Antworten:
Sie können die @Syntax verwenden, um die Domäne von einem bestimmten Server aus nachzuschlagen. Wenn der DNS-Server für diese Domäne autorisierend ist, ist die Antwort kein zwischengespeichertes Ergebnis.
dig @ns1.example.com example.com
Sie können die autorisierenden Server finden, indem Sie nach den NSDatensätzen für eine Domain fragen :
dig example.com NS
+norecursewird empfohlen. +recurseWenn diese Option standardmäßig aktiviert ist, ändert sich gelegentlich die Art und Weise, in der ein DNS-Server Ihre Frage vollständig interpretiert.
+traceaber achten Sie auf Caching. Andrew B hat eine gute Erklärung dafür verfasst, wie Caching Sie austricksen kann, wenn Sie darauf warten, dass Nameserver geändert werden.
dig @8.8.8.8 example.com. Die Aufzeichnungen erscheinen dort viel schneller.
Das DNS-Protokoll enthält keinen Mechanismus, mit dem ein Nameserver zur Antwort gezwungen werden kann, ohne seinen Cache zu verwenden. Dig selbst ist kein Nameserver, sondern lediglich ein Tool, das Ihre Anfrage mithilfe von Standard-DNS-Anfragen an die von Ihnen konfigurierten Nameserver weiterleitet. DNS enthält eine Möglichkeit, einen Server anzuweisen, keine Rekursion zu verwenden, aber dies ist nicht das, was Sie möchten. Dies ist nur sinnvoll, wenn Sie einen autorisierenden Nameserver direkt abfragen möchten.
Wenn Sie verhindern möchten, dass ein Nameserver aus dem Cache antwortet, können Sie dies nur durch Ändern der Konfiguration auf dem Nameserver tun. Wenn Sie den Nameserver jedoch nicht steuern, ist dies unmöglich.
Sie können jedoch dig veranlassen, die konfigurierten Nameserver zu umgehen und eine eigene rekursive Anforderung auszuführen, die auf die Stammserver zurückgeht. Verwenden Sie dazu die +traceOption.
dig example.com +trace
In der Praxis ist das Ergebnis auch dann nicht veraltet, wenn auf diesen Servern internes Caching verwendet wird, da nur die autorisierenden Server und nicht der lokale Caching-Resolver abgefragt werden. Der zusätzliche Vorteil der Verwendung +tracebesteht darin, dass Sie alle separaten Anforderungen sehen können, die entlang des Pfads gestellt wurden.
+norecursejust" verwenden, wird der Nameserver angewiesen, alle darin enthaltenen Informationen (einschließlich etwaiger zwischengespeicherter Informationen) zurückzugeben, damit diese nicht korrekt sind. +tracefunktioniert, weil es der Rekursionskette bis zu einem autorisierenden Server folgt.
+norecurseEmpfehlung zu entfernen , da sie das Problem verwirrt.
Hier ist etwas Wichtiges zu beachten, von dem ich bemerke, dass viele Leute es nie mit einbeziehen, wenn sie davon sprechen, +tracedass +traceder dig-Client den Trace ausführt und nicht der DNS-Server, der in Ihrer Konfiguration (/etc/resolv.conf) angegeben ist. Mit anderen Worten, Ihr dig-Client funktioniert wie ein rekursiver DNS-Server, wenn Sie danach fragen. Aber - wichtig ist, dass Sie keinen Cache haben.
Weitere Details - Wenn Sie also bereits nach einem mxDatensatz mit gefragt haben dig -t mx example.comund Ihre /etc/resolv.conf 8.8.8.8 lautet, wird das zwischengespeicherte Ergebnis zurückgegeben , wenn Sie irgendetwas in der TTL der Zone tun. In gewisser Weise haben Sie Ihre DNS-Ergebnisse bei Google für die TTL Ihrer Zone vergiftet, wenn Sie nach etwas über Ihre eigene Zone suchen und wie Google sie sieht. Nicht schlecht, wenn Sie eine kurze TTL haben, etwas Müll, wenn Sie eine 1-stündige haben.
Während +traceSie also sehen können, was WÜRDE, wenn Sie Google zum ERSTEN Mal fragen und es keinen zwischengespeicherten Eintrag gibt, werden Sie möglicherweise eine falsche Vorstellung davon haben, dass Google allen das Gleiche mitteilt wie Ihr +traceErgebnis, welches Dies ist nicht der Fall, wenn Sie zuvor gefragt haben und eine lange TTL haben, da diese vom Cache bis zum Ablauf der TTL verwendet wird. DANN entspricht sie der +traceoffenbarten TTL .
Kann nicht zu viel Detail IMO haben.
dig mydomain.com +tracegibt mir nur die resolvdstummelergebnisse aus 127.0.0.53. Siehe github.com/systemd/systemd/issues/5897
+tracedig beginnt der Trace mit dem angegebenen Nameserver (z. B. 8.8.8.8, falls Sie diesen konfiguriert haben) für die erste Suche (die Root-Zone), danach werden jedoch die zurückgegebenen Nameserver für weitere Abfragen verwendet. Wenn also Ihr konfigurierter Nameserver nicht funktioniert oder auf eine Anfrage nach den Root-Nameservern nicht richtig reagiert, können Probleme auftreten (wie im obigen Kommentar).
In dieser Bash werden die DNS-Einträge von example.com vom ersten aufgelisteten Nameserver durchsucht:
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
Hier ist das Gleiche wie ein Alias für einen .zshrc (und wahrscheinlich .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; }
Hier ist die Ausgabe für / .:
☀ 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
Diese Lösung ist kompliziert genug, um sich zu erinnern, aber einfach genug, um das Problem nicht zu beheben. digist nicht meine Spezialität - Verbesserungen erwünscht :-)