บังคับให้ขุดเพื่อแก้ไขโดยไม่ต้องใช้แคช

ฉันสงสัยว่ามีวิธีการสอบถามเซิร์ฟเวอร์ DNS และบายพาสแคช (ด้วยdig) บ่อยครั้งที่ฉันเปลี่ยนโซนบนเซิร์ฟเวอร์ DNS และฉันต้องการตรวจสอบว่ามันแก้ไขอย่างถูกต้องจากเวิร์กสเตชันของฉัน แต่เนื่องจากเซิร์ฟเวอร์แคชแก้ไขคำขอฉันมักจะได้รับคำขอเก่า การรีสตาร์ทหรือโหลดเซิร์ฟเวอร์ไม่ใช่สิ่งที่ดี

คุณสามารถใช้@ไวยากรณ์เพื่อค้นหาโดเมนจากเซิร์ฟเวอร์เฉพาะ หากเซิร์ฟเวอร์ DNS มีสิทธิ์สำหรับโดเมนนั้นการตอบสนองจะไม่เป็นผลการแคช

dig @ns1.example.com example.com

คุณสามารถค้นหาเซิร์ฟเวอร์ที่เชื่อถือได้โดยขอNSบันทึกสำหรับโดเมน:

dig example.com NS

ไม่มีกลไกในโปรโตคอล DNS เพื่อบังคับให้เนมเซิร์ฟเวอร์ตอบสนองโดยไม่ต้องใช้แคช ขุดเองไม่ใช่ nameserver เป็นเพียงเครื่องมือที่ส่งแบบสอบถามของคุณไปยังเซิร์ฟเวอร์ที่คุณกำหนดค่าโดยใช้การร้องขอ DNS มาตรฐาน DNS ไม่รวมถึงวิธีที่จะบอกเซิร์ฟเวอร์จะไม่ใช้การเรียกซ้ำ แต่นี่ไม่ใช่สิ่งที่คุณต้องการ สิ่งนี้มีประโยชน์เมื่อคุณต้องการสอบถามเซิร์ฟเวอร์ที่เชื่อถือได้โดยตรงเท่านั้น

หากคุณต้องการที่จะหยุดเนมเซิร์ฟเวอร์จากการตอบสนองจากแคชคุณสามารถทำได้โดยการเปลี่ยนการกำหนดค่าในเนมเซิร์ฟเวอร์แต่ถ้าคุณไม่ได้ควบคุมเนมเซิร์ฟเวอร์

อย่างไรก็ตามคุณสามารถขุดเพื่อหลีกเลี่ยงเนมเซิร์ฟเวอร์ที่กำหนดค่าและดำเนินการร้องขอซ้ำของตัวเองซึ่งจะกลับไปที่เซิร์ฟเวอร์ราก เมื่อต้องการทำเช่นนี้ใช้+traceตัวเลือก

dig example.com +trace

ในทางปฏิบัติเนื่องจากสิ่งนี้จะทำการค้นหาเซิร์ฟเวอร์ที่เชื่อถือได้เท่านั้นแทนที่จะใช้ตัวแก้ไขแคชในเครื่องของคุณผลลัพธ์จะไม่เก่าแม้ว่าเซิร์ฟเวอร์เหล่านั้นจะใช้การแคชภายใน ประโยชน์ที่เพิ่มขึ้นของการใช้งาน+traceคือคุณจะได้เห็นคำขอทั้งหมดที่แยกจากกันตามเส้นทาง

สิ่งสำคัญที่ควรทราบที่นี่ซึ่งฉันสังเกตเห็นว่าคนจำนวนมากไม่ได้รวมเมื่อพูดถึง+traceคือการใช้+traceหมายความว่าไคลเอ็นต์ขุดจะทำการติดตามไม่ใช่เซิร์ฟเวอร์ DNS ที่ระบุใน config ของคุณ (/etc/resolv.conf) ดังนั้นในคำอื่น ๆ ไคลเอ็นต์ขุดของคุณจะทำงานเหมือนเซิร์ฟเวอร์ DNS แบบเรียกซ้ำคุณควรถามมัน แต่ - ที่สำคัญคุณไม่มีแคช

รายละเอียดเพิ่มเติม - ดังนั้นหากคุณขอmxบันทึกโดยใช้dig -t mx example.comและ /etc/resolv.conf ของคุณคือ 8.8.8.8 การทำอะไรภายใน TTL ของโซนจะส่งคืนผลลัพธ์ที่แคช หากคุณกำลังมองหาบางอย่างเกี่ยวกับโซนของคุณเองและวิธีที่ Google เห็นมันคุณได้รับพิษจากผลลัพธ์ DNS ของคุณด้วย Google สำหรับ TTL ของโซนของคุณ ไม่เลวเลยถ้าคุณมี TTL สั้น ๆ ขยะบ้างถ้าคุณมี 1 ชม.

ดังนั้นในขณะที่+traceจะช่วยให้คุณเห็นสิ่งที่จะเห็นถ้าคุณขอให้ Google เป็นครั้งแรกและไม่มีรายการแคชมันอาจทำให้คุณมีความคิดที่ผิดว่า Google จะบอกทุกคนเช่นเดียวกับ+traceผลลัพธ์ของคุณซึ่ง มันจะไม่เกิดขึ้นถ้าคุณถามก่อนหน้านี้และมี TTL ยาวเนื่องจากจะให้บริการนั้นจากแคชจนกว่า TTL จะหมดอายุ - จากนั้นจะให้บริการเหมือนกับที่คุณ+traceเปิดเผย

ไม่สามารถมีรายละเอียด IMO มากเกินไป

ทุบตีนี้จะขุดรายการ DNS ของ example.com จากเซิร์ฟเวอร์ชื่อที่แสดงรายการแรก:

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

• ขุดค้นแบบสอบถาม DNS ของ google (8.8.8.8) เพื่อรับ nameservers ของ example.com
• ขุดนอกแบบสอบถามเซิร์ฟเวอร์ชื่อแรกของ example.com

นี่คือชื่อแทนสำหรับ. zshrc (และอาจเป็น. 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; }

นี่คือผลลัพธ์สำหรับ /:

☀  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

วิธีนี้มีความซับซ้อนพอที่จะจำไม่ได้ แต่ง่ายพอที่จะแก้ไขปัญหาไม่ได้ digไม่ใช่แบบพิเศษของฉัน - ยินดีต้อนรับการปรับปรุง :-)