ตัวติดตามและแสดงภาพการสอบถาม DNS

จำลองการแก้ไข DNS แบบเรียกซ้ำตั้งแต่ resolver ของคุณไปยัง authoritative nameserver ดูทุก hop, RTT, TTL และพฤติกรรมการแคช

www.example.com mail.example.com www.google.com github.com api.cloudflare.com www.amazon.com www.wikipedia.org smtp.fastmail.com mx.example.net NXDOMAIN example
ฐานข้อมูลจำลอง: เครื่องมือนี้ใช้ฐานข้อมูล DNS ในตัว (ไม่สามารถสอบถามเครือข่ายจริงจากเบราว์เซอร์ได้) ใช้เครื่องมือสร้างโซน ด้านล่างเพื่อเพิ่มโดเมนที่คุณต้องการทดสอบ
วิธีการทำงาน: Resolver ของคุณจะสอบถาม root nameservers สำหรับ TLD, จากนั้นสอบถาม TLD servers สำหรับ authoritative nameserver, และดึง record แต่ละ hop จะแสดง RTT และสถานะที่ได้รับแคชแล้ว
กำหนด zone กำหนดเอง — จากนั้นสอบถามเหมือนโดเมนอื่น
Format: label type value TTL [priority]
ใช้ @ สำหรับ zone apex. MX records ต้องเพิ่มฟิลด์ priority
Supported types: A, AAAA, MX, NS, TXT, CNAME
1 รันคำสั่งนี้บนระบบของคุณ:
แนะนำ (เชื่อถือได้ที่สุด — ใช้ได้กับทุกโดเมน): dig example.com หรือ Windows / Linux / macOS: nslookup example.com สำหรับเส้นทางการแก้ไขแบบเต็ม (อาจล้มเหลวบน CDN หรือ DNS ที่ซับซ้อน): dig +trace +tries=1 +nodnssec example.com สำหรับการใช้ DNS server สาธารณะเฉพาะ: dig @8.8.8.8 example.com dig @1.1.1.1 example.com ⚠️ หลีกเลี่ยง: dig +trace อย่างเดียว สิ่งนี้ล้มเหลวกับโดเมนหลายแห่ง (CDN-hosted, DNS ตั้งค่าไม่ถูกต้อง) ให้ใช้คำสั่งด้านบนแทน
หมายเหตุ: dig @8.8.8.8 +trace ก็ล้มเหลวเช่นกัน — flag @ มีผลแค่ hop แรกเท่านั้น
2 คัดลอกเอาต์พุตทั้งหมดและวางด้านล่าง:
3 แสดงภาพเส้นทางการสอบถามที่แยกวิเคราะห์แล้ว:
กำลังสอบถาม root nameservers...

เส้นทางการแก้ไข

MISS

บันทึกการแก้ไขทีละขั้นตอน

# Server RTT Query / Response ประเภท

คำตอบสุดท้าย

ตัวจับเวลาแคช TTL

ตัวตรวจสอบข้อความ DNS

ข้อมูลอ้างอิงแนวคิด DNS

Recursive: Stub resolver ของคุณส่ง query หนึ่งครั้งไปยัง recursive resolver (เช่น 8.8.8.8) Resolver นั้นจัดการงานแบบ iterative ทั้งหมดแทนคุณและ ส่งคำตอบสุดท้ายกลับมา

Iterative: Nameserver แต่ละตัวส่ง การอ้างอิง (referral) — "ฉันไม่รู้ แต่ลองใช้เซิร์ฟเวอร์นี้ดู". Recursive resolver จะติดตามการอ้างอิงจนกว่าจะถึง authoritative nameserver

เครื่องมือนี้จำลองการสอบถามแบบ iterative ที่ recursive resolver ทำ ภายใน: root → TLD → authoritative.
ทุก record ของ DNS มี TTL เป็นวินาที Resolver จะแคชคำตอบเป็นระยะเวลานั้น ขณะที่ถูกแคช การสอบถามครั้งต่อไปจะได้รับคำตอบทันที (ไม่มีการ round-trip เครือข่าย)

TTL ทั่วไป:
  • A/AAAA — 300 s (5 นาที) ถึง 3600 s (1 ชม.)
  • MX — โดยทั่วไป 3600 s
  • NS — โดยทั่วไป 86400 s (24 ชม.)
  • TXT (SPF) — โดยทั่วไป 3600 s
TTL ต่ำช่วยให้เปลี่ยน record ได้เร็ว; TTL สูงช่วยลดภาระของ resolver
authoritative nameserver: เก็บข้อมูล zone จริง (A records, MX records, ฯลฯ) สำหรับโดเมน มันจะตอบกลับด้วย AA=1 (Authoritative Answer) ที่ตั้งค่าไว้ในส่วนหัวของ DNS

Recursive (caching) resolver: ไม่ได้เก็บข้อมูล zone มันสอบถาม เซิร์ฟเวอร์อื่นแทนไคลเอนต์ แคชผลลัพธ์ และส่งคำตอบกลับ ตัวอย่าง: 8.8.8.8, 1.1.1.1.
เมื่อโดเมนไม่มีอยู่ authoritative nameserver จะส่งคืน RCODE=NXDOMAIN Resolver จะแคชการตอบสนองเชิงลบนี้เป็นระยะเวลา SOA minimum TTL ของ zone (มักจะเป็น 300–3600 s)

Negative caching (RFC 2308) ป้องกันการสอบถามซ้ำสำหรับชื่อที่ไม่มีอยู่
เมื่อ authoritative nameserver ของ zone อยู่ใน zone นั้นเอง (เช่น ns1.example.com สำหรับ example.com) จะเกิดการพึ่งพาแบบวงกลม TLD zone หลักแก้ปัญหานี้โดยการรวม glue records — A records สำหรับ nameserver ที่ระบุโดยตรง ในการตอบสนองการอ้างอิง โดยข้ามความจำเป็นในการค้นหาเพิ่มเติม