Lösung 1:
Sie können den @ verwenden Syntax zum Nachschlagen der Domäne von einem bestimmten Server. Wenn der DNS-Server für diese Domain autorisierend ist, ist die Antwort kein zwischengespeichertes Ergebnis.
dig @ns1.example.com example.com
Sie können die autoritativen Server finden, indem Sie nach NS fragen Datensätze für eine Domain:
dig example.com NS
Lösung 2:
Es gibt keinen Mechanismus im DNS-Protokoll, um einen Nameserver dazu zu zwingen, zu antworten, ohne seinen Cache zu verwenden. Dig selbst ist kein Nameserver, es ist einfach ein Tool, das Ihre Anfrage unter Verwendung von Standard-DNS-Anfragen an die von Ihnen konfigurierten Nameserver weiterleitet. DNS macht Fügen Sie eine Möglichkeit hinzu, einem Server mitzuteilen, dass er keine Rekursion verwenden soll, aber das ist nicht das, was Sie wollen. Das ist nur nützlich, wenn Sie direkt einen autoritativen Nameserver abfragen möchten.
Wenn Sie verhindern möchten, dass ein Nameserver aus seinem Cache antwortet, können Sie dies nur tun, indem Sie die Konfiguration auf dem Nameserver ändern , aber wenn Sie den Nameserver nicht kontrollieren, ist dies unmöglich.
Sie können jedoch graben, um umzugehen die konfigurierten Nameserver und führt eine eigene rekursive Anfrage durch, die an die Root-Server zurückgeht. Verwenden Sie dazu die +trace Option.
dig example.com +trace
Da dies in der Praxis nur die autoritativen Server und nicht Ihren lokalen Caching-Resolver abfragt, ist das Ergebnis nicht veraltet, selbst wenn diese Server internes Caching verwenden. Der zusätzliche Vorteil der Verwendung von +trace ist, dass Sie alle separaten Anfragen sehen können, die entlang des Pfads gestellt wurden.
Lösung 3:
Hier ist etwas Wichtiges zu beachten, das viele Leute nie erwähnen, wenn sie über +trace sprechen ist das mit +trace bedeutet, dass der Dig-Client die Ablaufverfolgung durchführt, nicht der DNS-Server, der in Ihrer Konfiguration (/etc/resolv.conf) angegeben ist. Mit anderen Worten, Ihr Dig-Client funktioniert also wie ein rekursiver DNS-Server, wenn Sie danach fragen. Aber - wichtig, du hast keinen Cache.
Mehr Details - also wenn Sie schon nach einem mx gefragt haben Aufnahme mit dig -t mx example.com und Ihre /etc/resolv.conf ist 8.8.8.8, dann wird das zwischengespeicherte Ergebnis zurückgegeben, wenn Sie etwas innerhalb der TTL der Zone tun. Wenn Sie etwas über Ihre eigene Zone suchen und wie Google sie sieht, haben Sie in gewisser Weise Ihre DNS-Ergebnisse mit Google für die TTL Ihrer Zone vergiftet. Nicht schlecht, wenn Sie eine kurze TTL haben, etwas Müll, wenn Sie eine 1-Stunden-Zeit haben.
Also, während +trace Ihnen helfen zu sehen, was zu sehen WÜRDE, wenn Sie Google zum ERSTEN Mal fragen würden und es keinen zwischengespeicherten Eintrag hätte, könnten Sie fälschlicherweise glauben, dass Google allen dasselbe mitteilen wird wie Ihr +trace Ergebnis war, was nicht der Fall sein wird, wenn Sie zuvor gefragt haben und eine lange TTL haben, da diese aus dem Cache bereitgestellt wird, bis die TTL abläuft - DANN wird sie genauso bereitgestellt wie Ihr +trace aufgedeckt.
Kann meiner Meinung nach nicht zu viele Details enthalten.
Lösung 4:
Diese Bash gräbt die DNS-Einträge von example.com vom ersten aufgelisteten Nameserver:
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
- Die innere Ausgrabung fragt Googles DNS (8.8.8.8) ab, um die Nameserver von example.com zu erhalten.
- Die äußere Ausgrabung fragt den ersten Nameserver von example.com ab.
Hier ist dasselbe als Alias für eine .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 so kompliziert, dass man sie sich kaum merken kann, aber einfach genug, dass das Problem nicht behoben werden kann. dig ist nicht meine Spezialität -Verbesserungen willkommen :-)