Frage Erzwingen Sie das Auflösen, ohne den Cache zu verwenden


Ich frage mich, ob es eine Möglichkeit gibt, einen DNS-Server abzufragen und Caching zu umgehen (mit dig). Oft wechsle ich eine Zone auf dem DNS-Server und ich möchte überprüfen, ob es von meiner Arbeitsstation korrekt aufgelöst wird. Aber da der Server gelöste Anfragen zwischenspeichert, bekomme ich oft die alten. Neustart oder -laden des Servers ist nicht wirklich etwas nettes.


70
2018-03-21 17:15


Ursprung




Antworten:


Du kannst den ... benutzen @ Syntax, um die Domäne von einem bestimmten Server 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 autoritativen Server finden, indem Sie nach dem NS Datensätze für eine Domain:

dig example.com NS

100
2018-03-21 17:21



Oh ok. Ja, ich kannte die @ -Syntax, hatte aber nicht die Idee, stattdessen den autoritativen Server abzufragen. Vielen Dank! - Daniel
Randnotiz: Wenn Sie versuchen zu sehen, welche Antworten ein Caching-Server erhalten würde, +norecurse ist empfohlen. +recurse Ist standardmäßig aktiviert, ändert sich gelegentlich die Art und Weise, wie ein DNS-Server Ihre Frage vollständig interpretiert. - Andrew B
Was ist, wenn Sie darauf warten, dass sich die autoritativen Server ändern? - guaka
@KasperSouren Sprechen Sie über die NS-Datensätze auf den autoritativen Servern oder die Kleber-Datensätze bei den Eltern? Sie können den Elternteil mit finden +trace aber hüte dich vor Caching. Andrew B hat eine gute Erklärung dafür geschrieben, wie Caching Sie austricksen kann, wenn Sie darauf warten, dass Nameserver sich ändern. - Ladadadada
Sie können auch auf Google DNS überprüfen dig @8.8.8.8 example.com. Die Aufzeichnungen erscheinen dort viel schneller. - machineaddict


Es gibt keine zuverlässige Standardmethode, mit der ein Nameserver gezwungen wird, zu antworten, ohne seinen Cache zu verwenden. Dig selbst ist kein Nameserver, es ist einfach ein Tool, das Ihre Anfrage an die Nameserver weitergibt, die Sie konfiguriert haben, indem Sie Standard-DNS-Anfragen verwenden. Dort ist eine Möglichkeit, "Rekursion nicht zu verwenden", aber das ist nicht das, was Sie wollen - es würde einfach jede Suche nach Domainnamen im weiteren Internet verhindern.

Wenn Sie verhindern wollten, dass ein Nameserver aus seinem Cache reagiert, müssten Sie dies erreichen, indem Sie die Konfiguration ändern auf dem Nameserver, aber wenn du den Nameserver nicht kontrollierst, kannst du das nicht tun.

Sie können jedoch graben zu Bypass die konfigurierten Nameserver und führen eine eigene rekursive Anfrage durch, die zu den Root-Servern zurückkehrt. Um dies zu tun, verwenden Sie die +trace Möglichkeit.

dig example.com +trace

Da in der Praxis nur die autorisierenden Server und nicht der lokale Caching-Resolver abgefragt wird, ist das Ergebnis nicht veraltet, selbst wenn diese Server internes Caching verwenden. Der zusätzliche Vorteil der Verwendung +trace ist, dass Sie alle separaten Anforderungen sehen, die entlang des Pfades gestellt werden.


19
2018-05-31 15:00



Verwenden +norecurse teilt dem Nameserver nur mit, dass er alle Informationen zurückgibt, die er hat (einschließlich zwischengespeicherter Informationen, falls vorhanden), so dass dies nicht korrekt ist. +trace funktioniert, weil es der Rekursionskette bis hin zu einem autoritativen Server folgt. - Raman
Beachten Sie, dass ich diese Antwort geändert habe, um den Eintrag zu entfernen +norecurse Empfehlung, da es das Problem verwirrte. - thomasrutter


Etwas Wichtiges, das hier zu beachten ist, das merke ich, dass viele Leute niemals darüber reden +trace ist das verwenden +trace bedeutet, dass der dig-Client die Ablaufverfolgung ausführt, nicht den in Ihrer Konfiguration angegebenen DNS-Server (/etc/resolv.conf). Mit anderen Worten, Ihr dig-Client funktioniert wie ein rekursiver DNS-Server, sollten Sie ihn fragen. Aber - wichtig, Sie haben keinen Cache.

Mehr Details - also wenn du schon nach einem gefragt hast mx aufnehmen mit dig -t mx example.com und Ihre /etc/resolv.conf ist 8.8.8.8 dann wird alles innerhalb der TTL der Zone das zwischengespeicherte Ergebnis zurückgeben. In gewisser Weise haben Sie Ihre DNS-Ergebnisse mit Google für die TTL Ihrer Zone vergiftet, wenn Sie nach etwas über Ihre eigene Zone und wie Google es sieht suchen. Nicht schlecht wenn du eine kurze TTL hast, etwas Quatsch wenn du eine 1h hast.

Also, während +trace wird Ihnen helfen, zu sehen, was gesehen werden würde, wenn Sie Google zum ERSTEN Mal fragen würden und es keinen im Cache gespeicherten Eintrag gäbe, könnte es eine falsche Vorstellung sein, dass Google allen dasselbe sagen wird wie Ihrem +trace Ergebnis war, das es nicht, wenn Sie vorher gefragt hätten und eine lange TTL haben, wie es aus dem Cache dienen wird, bis die TTL abläuft - DANN wird es genauso dienen wie Ihre +traceaufgedeckt.

Kann nicht zu viel Detail IMO haben.


10
2018-05-24 23:10



Hat dig einen eigenen Cache oder verwendet den Betriebssystem-Cache? - CMCDragonkai
Dig hat keinen Cache. Wenn der Upstream-Nameserver jedoch davon profitiert, profitiert er davon. - thomasrutter
dig mydomain.com +trace gibt mir einfach die resolvd Stub Ergebnisse von 127.0.0.53. Sehen github.com/systemd/systemd/issues/5897 - James Bowery
Beim Benutzen +trace graben beginnt die Ablaufverfolgung mit dem angegebenen Nameserver (z. B. 8.8.8.8, falls dies konfiguriert ist) für die erste Suche (die Stammzone), danach werden jedoch die zurückgegebenen Nameserver für weitere Abfragen verwendet. Wenn also Ihr konfigurierter Nameserver nicht funktioniert oder nicht richtig auf eine Abfrage für die Root-Nameserver antwortet, können Sie Probleme haben (wie im obigen Kommentar). - thomasrutter


Diese Bash wird die DNS-Einträge von example.com von seinem ersten aufgelisteten Nameserver graben:

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
  • Das innere dig fragt googles DNS (8.8.8.8) ab, um example.com zu erhalten Nameserver.
  • Das äußere dig fragt den Vornamenserver von example.com ab.

Das gleiche gilt für einen Alias ​​für .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 der Ausgang 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 unpraktisch zu sein, aber einfach genug, um das Problem nicht zu beheben. dig ist nicht meine Spezialität -  Verbesserungen willkommen :-)


1
2018-01-11 17:49