จะทดสอบว่าข้อมูล DNS แพร่กระจายได้อย่างไร?

16

ฉันตั้งค่ารายการ DNS ใหม่สำหรับหนึ่งในโดเมนย่อยของฉัน (ฉันยังไม่ได้ตั้งค่าโฮสต์เสมือน Apache หรืออะไรทำนองนั้น) ฉันจะตรวจสอบว่าข้อมูล DNS แพร่กระจายได้อย่างไร

ฉันคิดว่าฉันสามารถทำได้ง่ายping my.subdomain.comและสมมติว่าหากมันสามารถแก้ไขได้มันจะแสดงที่อยู่ IP ที่ฉันระบุในบันทึก A อย่างไรก็ตามฉันไม่รู้ว่าฉันสมมุติอย่างถูกต้องหรือไม่ วิธีที่ดีที่สุดในการตรวจสอบข้อมูลนี้คืออะไร?

domain-name-system 
— แอนดรู
แหล่งที่มา
3
ไม่ใช่คำถามที่โง่ ไม่ใช่ที่ตรงไปตรงมาเพื่อค้นหาสิ่งนี้
— aseq
1
ฉันเห็นด้วยกับ @aseq ว่านี่ไม่ใช่คำถามที่โง่แต่ "ลองดูแล้วเห็น" ก็ให้คำตอบกับคุณเช่นกัน นอกจากนี้ยังเป็นสิ่งที่ Google สามารถตอบได้อย่างง่ายดายเพียงเล็กน้อยด้วยความพยายามเล็กน้อย (ค้นหาHow to test if DNS information has propagated- ชื่อคำถามเลือดสร้างผลลัพธ์ที่ดีของ Google)
— voretaq7
4
ฉันไม่คิดว่าคุณจะเสียเวลากับคนอื่น คำถามของคุณกระตุ้นการตอบสนองที่มีค่า คุณไม่เคยรู้เลยว่าคำถามง่าย ๆ ที่ดูเหมือนจะเป็น "googled" อาจปรากฏออกมาได้อย่างไร หนึ่งในค่าของฟอรัมนี้คือคำตอบและคำถามสามารถขยายได้อย่างง่ายดาย
— aseq
1
@ ไม่ได้มีอะไรผิดปกติในการถามสิ่งที่พวกเราหลายคนมองว่าเป็นคำถามง่าย ๆ - นี่อาจเป็นผลการค้นหาอันดับต้น ๆ ของ Google สำหรับสตริงนั้นในอีกไม่กี่วันเนื่องจากวิธีการที่เว็บไซต์ได้รับการจัดทำดัชนี / จัดอันดับ โดยทั่วไปแม้ว่า Google จะเป็นที่ที่ดีกว่า (เร็วกว่า) ในการมองหา: หาก Google ไม่ทราบให้ถามที่นี่ (และ Google จะเรียนรู้) :-)
— voretaq7
1
ฉันคิดออกว่าทำไมไม่มีอะไรที่ฉันพยายามทำอยู่ เห็นได้ชัดว่าเครือข่ายของเรามีการกำหนดค่าในลักษณะที่จะต้องเพิ่มโดเมนย่อยใหม่ใน DNS ท้องถิ่นของเราด้วย ดังนั้นโดเมนย่อยสามารถเข้าถึงได้จากโลกภายนอกไม่ใช่ในเครือข่ายของเราที่ฉันทำการทดสอบ = [แต่ใช้nslookupและdigในขณะที่ระบุเซิร์ฟเวอร์ภายนอกทำให้ฉันสามารถตรวจสอบข้อมูล DNS ภายนอกได้
— แอนดรู

คำตอบ:

15

คุณสามารถใช้ dig หรือ nslookup พูดชื่อ (หรือผู้ให้บริการของคุณหากคุณไม่ได้ใช้งานเอง) เนมเซิร์ฟเวอร์คือ ns1.example.com

ใช้ nslookup:

nslookup - ns1.example.com

ที่ประเภทพรอมต์:

my.example.com

ถ้ามันแก้ไขสิ่งที่คุณคาดไว้ก็ใช้งานได้ ควรให้สิ่งที่คุณต้องการ:

Name:   example.com
Address: 192.0.43.10

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

ใช้ขุด:

dig@ns1.example.com my.example.com

คุณควรเห็นบางสิ่งเช่น:

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

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

หากคุณใช้ windows คำสั่งและไวยากรณ์อาจแตกต่างกันเล็กน้อย แต่ก็ค่อนข้างคล้ายกัน

— aseq
แหล่งที่มา
3
+1 หากคุณทำอะไรกับ DNS รับสำเนาของdig(* ระบบ nix มีอยู่แล้วมี Windows หลายรุ่นให้เลือก)
— Chris S
3
-1 ฉันขอโทษ. ฉันเป็นอย่างแท้จริง แต่คำตอบนี้ "เผยแพร่" ตำนานที่บันทึก DNS เผยแพร่ซึ่งแน่นอนที่สุดพวกเขาทำไม่ได้ คำที่คุณกำลังค้นหาคือ "แคช" ซึ่งเป็นสิ่งที่เกิดขึ้นกับระเบียน DNS โดยยึดตาม TTL ของระเบียน เนื่องจาก OP อ้างถึงระเบียน DNS ใหม่จะไม่มีการแคชเกิดขึ้นดังนั้นไคลเอ็นต์ DNS ใด ๆ ที่พยายามแก้ไขระเบียนที่เป็นปัญหาจะได้รับคำตอบ ... ทันที ... เนื่องจากไคลเอ็นต์แคชนั้นไม่สามารถแคชได้ ... หรือเซิร์ฟเวอร์ DNS ลูกค้านั้น ... หรือเซิร์ฟเวอร์ DNS อื่น ๆ ระเบียน DNS จะไม่เผยแพร่ไปที่ "ส่วนที่เหลือของอินเทอร์เน็ต"
— joeqwerty
1
joeqwerty ถูกต้องแน่นอน เซิร์ฟเวอร์ dns จะแคชการโจมตีเป็นค่าบวกหรือค่าลบสำหรับเวลาที่กำหนดไว้ล่วงหน้า อย่างไรก็ตามนอกเหนือจากโพสต์ดั้งเดิมมีเซิร์ฟเวอร์ชื่อสาธารณะหลายแห่งที่คุณสามารถตรวจสอบได้รวมถึง GTE เก่า (4.2.2.1, 4.2.2.2, 4.2.2.3 และ 4.2.2.4) และ google (8.8.8.8, 8.8 4.4) กฎง่ายๆการเปลี่ยนแปลงใหม่อาจใช้เวลานานถึง ttl สำหรับการตีบวกหรือลบ อย่างไรก็ตามมีหลายกรณีที่แอปใช้ตรรกะที่ไม่เหมาะสมและคำตอบแคชเป็นระยะเวลานาน
— bangdang
2
ฉันไม่คิดว่าคุณต้องยึดติดกับคำจำกัดความที่แท้จริงเพื่อให้ได้ประเด็น นอกจากนี้ฉันคิดว่าการเผยแพร่ไม่ใช่คำที่เลวร้ายที่จะใช้ มันครอบคลุมเรื่องในแง่ที่แคชของระเบียน DNS จะกระจายไปยังเซิร์ฟเวอร์ที่กว้างขึ้น การแพร่กระจายนั้นเป็นสิ่งที่เผยแพร่หมายถึง ฉันอัปเดตคำตอบเพื่อสะท้อนความจริงว่ามีบันทึกใหม่ให้ใช้งานได้ทันที
— aseq
1
@aseq มันเป็นคำที่ทำให้เข้าใจผิด และส่วนใหญ่ปรากฎว่าผู้ที่คิด / พูดคุยเกี่ยวกับ DNS ว่า "การเผยแพร่" ไม่ทราบว่า DNS ทำงานอย่างไร พวกเขามักจะระบุอึเช่น "ใช้เวลา 2-3 วันในการเผยแพร่ข้อมูล DNS ของคุณผ่านอินเทอร์เน็ต / Earth" และอื่น ๆ
— poige
7

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

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

— joeqwerty
แหล่งที่มา
ดีใจที่ได้ช่วย ...
— joeqwerty
มีวิธีใดที่จะตรวจสอบว่าฉันป้อน IP ที่ถูกต้องหรือไม่ ฉันแค่อยากจะแน่ใจว่าที่อยู่ IP ที่ฉันใช้นั้นถูกต้อง บางคนที่ฉันคุยด้วยดูเหมือนจะคิดว่าการ ping จะล้มเหลวหากฉันยังไม่ได้ติดตั้ง Apache VHost
— แอนดรู
Ping ไม่ใช่เครื่องมือทดสอบ DNS ขุดและ Nslookup เป็นเครื่องมือทดสอบ DNS ใช้ Dig หรือ Nslookup เพื่อทดสอบระเบียน DNS ใหม่ เคียวรีสำหรับเร็กคอร์ดกับเนมเซิร์ฟเวอร์ของคุณจากนั้นเคียวรีเร็กคอร์ดกับเนมเซิร์ฟเวอร์อื่นเพื่อให้แน่ใจว่าพวกเขากำลังค้นหาเซิร์ฟเวอร์ชื่อของคุณและเซิร์ฟเวอร์ชื่อของคุณตอบสนองด้วยคำตอบที่ถูกต้อง
— joeqwerty
1
"การเผยแผ่" เป็นความคิดที่เกิดขึ้นในกรณีที่ผู้คนไม่สามารถเข้าใจสถานการณ์จริงซึ่งก็คือความชราและการหมดอายุของแคช สิ่งที่จำเป็นต้องได้รับการกล่าวจากผู้ให้บริการ DNS คือ "ข้อมูลของคุณอาจไม่ปรากฏจนกว่าจะถึงเวลา XX ชั่วโมง" คำอธิบายว่าทำไมจึงมีความจำเป็นดังนั้นจึงดูเหมือนว่าผู้ให้บริการ DNS ไม่ได้รับความล่าช้า คนจำนวนมากเกินไป "ไม่สามารถจัดการกับความจริง" "การเผยแผ่" ที่ประกอบขึ้นเป็นเรื่องราวที่มีประสิทธิภาพ DNS ที่แท้จริงจะรู้ว่าสิ่งใดเกิดขึ้นจริงเพราะพวกเขาอ่านรายละเอียดทางเทคนิค
— Skaperen
จริงพอ ... ฉันเกลียดการใช้คำที่ "เผยแพร่" ความเข้าใจผิดเกี่ยวกับวิธีการทำงานของ DNS
— joeqwerty
5

ในขณะที่คำตอบอื่น ๆ นั้นค่อนข้างดีโปรดจำไว้ว่าสิ่งที่เผยแพร่ให้คุณอาจไม่ได้เผยแพร่ให้ฉัน แทนที่จะใช้ DIG หรือ NSlookup และใช้เวลาหนึ่งชั่วโมงในการตรวจสอบเซิร์ฟเวอร์ DNS ทั่วโลกฉันมักจะใช้http://www.whatsmydns.net/เพื่อดูว่าการแพร่กระจายเป็นอย่างไร

— จิมข
แหล่งที่มา
ไม่มีการเผยแพร่ใน DNS คำศัพท์นี้ค่อนข้างเข้าใจผิดสำหรับนักอ่านประเภทเลเซอร์ทุกคนที่ไม่พบว่าตนเองกำลังอ่าน RFC ดังนั้นอย่า <strike> เผยแพร่ </strike> ใช้คำนี้ ;-D
— poige
1
แน่นอนว่ามีการเผยแพร่ใน DNS RFCs เข้าใจว่าผู้อ่านเข้าใจว่าข้อมูลสามารถเผยแพร่เมื่อเซิร์ฟเวอร์ทำการค้นหาและแคช มันชัดเจนโดยเฉพาะอย่างยิ่งเมื่อ lamers อ่าน RFCs แล้วสงสัยว่าทำไมบันทึกบนเซิร์ฟเวอร์ของพวกเขาไม่ตรงกับผลลัพธ์ของการค้นหาจากเซิร์ฟเวอร์อื่น พวกเขาค้นพบว่าการเผยแพร่มีความหมายของ "การแพร่กระจายอย่างกว้างขวาง" (ซึ่งเป็นสิ่งที่จำเป็นต้องตรวจสอบ - การกระจายของระเบียนที่อัปเดต)
— Jim B
ไม่มีการแจกแจงหรือการแพร่กระจาย (ยกเว้นต้นแบบเป็นทาส)
— poige
มันอาจจะเป็นของที่ระลึกจากเมื่อมันเอาบางครั้งใกล้กับวันที่จะได้รับการเปลี่ยนแปลงที่เกิดขึ้นใน .com โดเมนโหลดบนเซิร์ฟเวอร์ราก (ทางกลับเมื่อ .com อยู่บนราก!)
— Cakemox
@ poige- ขอบคุณที่ยืนยันว่าคุณไม่เข้าใจวิธีการแคช DNS ฉันขอแนะนำให้อ่าน RFCs เกี่ยวกับวิธีการทำงานของ DNS และอาจตรวจสอบเว็บไซต์ที่ฉันเชื่อมโยงเพื่อเป็นตัวอย่างในโลกแห่งความเป็นจริง
— Jim B
3

วิธีที่ง่ายที่สุดเพื่อให้แน่ใจว่าเซิร์ฟเวอร์ DNS ที่มีสิทธิ์ของคุณในเส้นทางการมอบหมายของคุณตอบรับอย่างถูกต้องคือการใช้dig +trace:

; <<>> DiG 9.7.3 <<>> +trace www.google.com a
;; global options: +cmd
.           80050   IN  NS  m.root-servers.net.
.           80050   IN  NS  f.root-servers.net.
.           80050   IN  NS  i.root-servers.net.
.           80050   IN  NS  h.root-servers.net.
.           80050   IN  NS  c.root-servers.net.
.           80050   IN  NS  k.root-servers.net.
.           80050   IN  NS  d.root-servers.net.
.           80050   IN  NS  g.root-servers.net.
.           80050   IN  NS  a.root-servers.net.
.           80050   IN  NS  b.root-servers.net.
.           80050   IN  NS  e.root-servers.net.
.           80050   IN  NS  l.root-servers.net.
.           80050   IN  NS  j.root-servers.net.
;; Received 509 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms

com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 127 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from 192.43.172.30#53(i.gtld-servers.net) in 20 ms

www.google.com.     604800  IN  CNAME   www.l.google.com.
www.l.google.com.   300 IN  A   173.194.35.180
www.l.google.com.   300 IN  A   173.194.35.178
www.l.google.com.   300 IN  A   173.194.35.176
www.l.google.com.   300 IN  A   173.194.35.177
www.l.google.com.   300 IN  A   173.194.35.179
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 27 ms

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

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

— Cakemox
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.