ลำดับการค้นหา DNS ถูกกำหนดอย่างไร


20

ตัวอย่างเช่น: เราได้ลงทะเบียนชื่อโดเมนdomain.comและเพิ่มระเบียนเซิร์ฟเวอร์ชื่อที่เซิร์ฟเวอร์ผู้รับจดทะเบียน:
ns1.domain.com
ns2.domain.com
ns3.domain.com

กว่าที่เรามองขึ้นสำหรับdomain.com เราได้รับ 3 เซิร์ฟเวอร์ชื่อที่อยู่
1. เซิร์ฟเวอร์ใดในเซิร์ฟเวอร์นั้นที่จะถูกขอเพิ่มเติมและเพราะอะไร
2. ลำดับของระเบียน NS ในไฟล์โซนสำคัญหรือไม่
3. กำหนดไว้ในRFCใด ๆหรือไม่?

คำตอบ:


20

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

ตัวอย่างเช่นอันดับแรกเกี่ยวกับระเบียน NS ที่ส่งคืน: อนุญาตให้สุ่มลำดับที่ระเบียนเหล่านั้นถูกส่งคืนได้ดังนั้นลำดับอาจแตกต่างกันในแต่ละครั้งที่คุณขอ ในทางตรงกันข้ามนั่นไม่ได้ทำโดยการใช้งาน DNS ทั้งหมดดังนั้นคุณอาจได้รับรายการสั่งแบบคงที่ ประเด็นคือคุณไม่แน่ใจ

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

มี RFC หลายตัวสำหรับ DNS สองสิ่งที่มีประโยชน์มากกว่าที่ฉันพบคือ:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

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


ฉันได้รับรองคำตอบของคุณ ฉันกำลังจะพูดในสิ่งเดียวกัน แต่คุณเอาชนะฉันไป
Tonny

นอกจากนี้ลูกค้าที่ใช้ getaddrinfo ท้ายด้วยผลลัพธ์ที่เรียงลำดับในขณะที่การเรียกใช้ gethostbyname ก็ดูเหมือนจะสุ่ม ลูกค้าที่ไม่คาดหวังว่าพฤติกรรมดังกล่าวจะทำให้โรบินกลมในบางกรณี
Matt

5

การใช้งานทั่วไปที่ฉันได้เห็นในระดับลูกค้าเช่น ISPs ทั่วโลกเป็นดังนี้:

  1. บางคน (เช่นผู้สมัครสมาชิกบรอดแบนด์) ขอให้เซิร์ฟเวอร์ DNS ของ ISP ทำการแก้ไขระเบียน A สำหรับ foo.example.com
  2. ISP ตรวจสอบแคชของตัวเองและหากบันทึกนั้นถูกแคชและยังถือว่าเป็น "สด" ก็จะส่งคืนผ่านแคชทันที ( นี่เป็นวิธีที่แคช DNS ทั้งหมดทำงานเพื่อไม่ให้เซิร์ฟเวอร์ DNS ของไซต์นั้นสงสัย )
  3. หากพวกเขาไม่ได้มีการบันทึกแคชนั้นหรือหากแคชถูกพิจารณาว่า "เก่า / ล้าสมัย" ISP จะรู้ว่าต้องแก้ไขระเบียนล่าสุดอีกครั้ง
  4. ตอนนี้ ISP จำเป็นต้องทราบว่าเซิร์ฟเวอร์ชื่อใดที่จะสอบถามเกี่ยวกับระเบียนล่าสุด
  5. ISP เริ่มต้นด้วยการตรวจสอบรายการแคชของเนมเซิร์ฟเวอร์ที่เชื่อถือได้สำหรับโดเมน (นี่คือ ns1.example.com, ns2.example.com และอื่น ๆ พร้อมกับ IP) หากบันทึกเหล่านั้นยังถือว่าสดอยู่ก็จะข้ามไปขั้นตอนที่ 8
  6. หากระเบียนเนมเซิร์ฟเวอร์แคชถูกพิจารณาว่าหมดอายุหรือหากไม่มีเร็กคอร์ดแคชสำหรับโดเมนนั้น ISP จะทำการสอบถามผู้ใช้ root-nameservers ของ TLD (เช่นการลงทะเบียน. com หากเป็นโดเมน. com) เพื่อรับ คู่ชื่อ / IP ของเนมเซิร์ฟเวอร์ที่ทันสมัยที่สุดสำหรับ example.com ( คุณสามารถลองด้วยตัวคุณเองผ่าน "dig @ b.gtld-servers.net example.com" เพื่อดูว่าเนมเซิร์ฟเวอร์สำหรับ TLD ของคุณรู้เกี่ยวกับโดเมนของคุณ - หากโดเมนของคุณอยู่ใน TLD com / net / etc ปกติอื่น ๆ TLD จะต้องค้นหาเซิร์ฟเวอร์รูทที่เกี่ยวข้อง )
  7. เนมเซิร์ฟเวอร์รากสำหรับ TLD จะส่งคืนเนมเซิร์ฟเวอร์ตามลำดับที่ถูกต้องที่ระบุโดยคุณเสมอ ไม่มีการสุ่มขึ้น พวกเขายังส่งคืน IP สำหรับแต่ละ nameserver สิ่งนี้เรียกว่า "GLUE" และเป็นสิ่งที่ช่วยให้อินเทอร์เน็ตในการแก้ปัญหา "ไก่และไข่" ของวิธีการแก้ไขชื่อโฮสต์เนมเซิร์ฟเวอร์เป็น IP ก่อนที่จะรู้อะไรเกี่ยวกับโดเมน นอกจากนี้ส่วนใหญ่ของพวกเขา (เช่น com / net / etc registries ซึ่งเป็นรายการที่ใหญ่ที่สุด) ใช้เวลาแคช 2 วันเพื่อที่พวกเขาจะไม่ได้รับการตอกตลอดเวลาด้วย "รายการเซิร์ฟเวอร์ชื่อสำหรับโดเมน X คืออะไร" การร้องขอ นี่คือแหล่งที่มาของความรู้ทั่วไปที่คุณต้องรอ 2 วันจนกว่าคุณจะสามารถพูดได้อย่างปลอดภัยว่าเซิร์ฟเวอร์ชื่อใหม่ของคุณเป็นที่รู้จักทั่วโลกหลังจากที่คุณ '
  8. เมื่อ ISP รู้จักเซิร์ฟเวอร์ชื่อของ example.com และ IP ของพวกเขาเช่น ns1.example.com, ns2.example.com, ns3.example.com ISP จะเลือกเซิร์ฟเวอร์สุ่มจากรายการนั้นและส่งแบบสอบถามออก ( นี่เป็นสิ่งที่ดีสำหรับพวกเขาพวกเขาไม่ต้องการเซิร์ฟเวอร์ DNS ทั้งหมดของไซต์ที่เป็นปัญหาและพวกเขาช่วยเพิ่มเติมเกี่ยวกับการทำโหลดบาลานซ์โดยไม่ต้องค้นหาเนมเซิร์ฟเวอร์รายการแรกเสมอ )
  9. หาก ISP ไม่ได้รับการตอบกลับจากเนมเซิร์ฟเวอร์ดังกล่าวภายในระยะเวลาที่กำหนดไว้จะทำการสอบถามอีกครั้งในรายการ
  10. เมื่อมีการตอบสนอง ISP จะจัดเก็บไว้ในแคชภายในเครื่องของตนเอง สำหรับระยะเวลาที่แคชจะยังคงอยู่ แต่ละระเบียนที่ส่งคืนโดยเซิร์ฟเวอร์ DNS ใด ๆ จะมีเวลา "soft expiry" (เป็นวินาที) ที่เกี่ยวข้องกับมันซึ่งเป็นระยะเวลาที่ลูกค้าสอบถาม (เช่นเซิร์ฟเวอร์ DNS ของ ISP) ได้รับอนุญาตให้แคชระเบียนนั้นก่อนที่จะพิจารณา " ยังคงใช้งานได้ แต่อาจล้าสมัยแบบสอบถามใหม่ควรเกิดขึ้นถ้าเป็นไปได้เพื่อให้แน่ใจว่าจะไม่มีการเปลี่ยนแปลง " นอกจากนี้ยังมีเวลา "hard expiry" ซึ่งระบุไว้ในบันทึก "SOA" (เริ่มต้นของผู้มีอำนาจ) ของแต่ละ nameserver (คุณสามารถดูของคุณผ่าน "dig @ ns1.example.com example.com -t soa") ซึ่ง ระบุขีด จำกัด "ระดับโลก" สำหรับระเบียนทั้งหมดที่ส่งคืนโดยเซิร์ฟเวอร์นั้น หลังจากที่แคชใด ๆ ควรลบเร็กคอร์ดที่แคชไว้แม้ว่าชื่อเซิร์ฟเวอร์จะหยุดทำงานและไม่สามารถค้นหาเร็กคอร์ดอีกครั้งได้ โดยปกติแล้วหมดอายุอ่อนอยู่ที่ใดก็ได้จาก 30 นาทีถึง 5 ชั่วโมงและมักจะหมดอายุยากระหว่าง 1-3 สัปดาห์
  11. หลังจากนั้นงานที่ครบถ้วนสมบูรณ์ในที่สุด ISP ก็มีระเบียน DNS ล่าสุดและสามารถส่งคืนไปยังผู้สมัครสมาชิกการสืบค้นบรอดแบนด์ซึ่งไม่มีใครรู้ว่างานขนาดใหญ่เกิดขึ้นหลังฉาก!

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

ทีนี้สำหรับการสุ่มของขั้นตอนที่ 8 มันจะทำงานในระดับเรคคอร์ด สมมติว่าผู้สมัครสมาชิกบรอดแบนด์ของ ISP นั้นถามเกี่ยวกับระเบียนต่อไปนี้:

  • a foo.example.com
  • A example.com
  • www.example.com
  • MX example.com (ลูกค้า ISP ไม่ควรขอบันทึกนี้ แต่เป็นเพียงตัวอย่าง)

แต่ละระเบียนจะได้รับการจัดการเป็น "เอนทิตี" แยกต่างหากของแคชและค้นหาอย่างอิสระ ดังนั้นสมมติว่าผู้สมัครสมาชิกและ ISP ไม่เคยพบโดเมนมาก่อนและทั้งคู่มีศูนย์แคชที่สมบูรณ์ การค้นหาอาจเป็นดังนี้:

  • foo.example.com ผ่าน ns1.example.com จากนั้นเก็บไว้ในแคช ISP
  • A example.com ผ่าน ns3.example.com จากนั้นเก็บไว้ในแคช ISP
  • www.example.com ผ่าน ns2.example.com จากนั้นเก็บไว้ในแคชของ ISP
  • MX example.com ผ่าน ns3.example.com จากนั้นเก็บไว้ในแคช ISP

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

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

นอกจากนี้ตามที่ Adam C กล่าวถึงเซิร์ฟเวอร์ DNS ระดับ (example.com) เซิร์ฟเวอร์ DNS เองสามารถส่งคืนระเบียน NS และสุ่มลำดับของสิ่งเหล่านั้น เป็นเรื่องธรรมดามากที่เซิร์ฟเวอร์ DNS ปกติจะสุ่มเรคคอร์ด NS ของพวกเขาในกรณีที่มีโอกาสเล็กน้อยที่การใช้ DNS ที่ไม่ดีจะเลือกเซิร์ฟเวอร์ที่ส่งคืนเป็นครั้งแรกเสมอ อย่างไรก็ตามเซิร์ฟเวอร์ชื่อ ROOT TLD (ที่กล่าวถึงก่อนหน้านี้) จะไม่สุ่มรายการและรายการของพวกเขาเป็นสิ่งที่สำคัญจริงๆเมื่อมันมาถึงการแก้ไขโดเมน นั่นเป็นเหตุผลที่การใช้งานส่วนใหญ่เลือกเซิร์ฟเวอร์สุ่มจากรายการเนมเซิร์ฟเวอร์เพื่อหลีกเลี่ยงการชนเซิร์ฟเวอร์เดียวกันเสมอและมากเกินไป

เอาล่ะนั่นคือไพรเมอร์ของคุณในการทำงานของ DNS และสิ่งที่คุณควรจำ

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

Disclaimer: เป้าหมายที่สูงขึ้นในชีวิตกว่าการจัดการ DNS อาจจะใช้ได้ แต่จะขายแยกต่างหากใช้จินตนาการของคุณ ;-)

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