เรามาทำลายมันกันหน่อย
ระเบียน NS ในโซน TLD (ตัวอย่างเช่นexample.com NS ...ในcom) เป็นบันทึกการมอบหมาย
ระเบียน A และ AAAA ในโซน TLD (ตัวอย่างเช่นns1.example.com A ...ในcom) เป็นบันทึกกาว
ระเบียน NS ในโซนนั้น (นั่นคือexample.com NS ...ในexample.com) เป็นระเบียนผู้มีอำนาจ
ระเบียน A และ AAAA ในโซนนั้น ( ns1.example.com A ...ในexample.com) เป็นระเบียนที่อยู่ธรรมดาและเรียบง่าย
เมื่อ (recursive) จำแนกเริ่มออกไปกับแคชข้อมูลโซนของคุณและไม่เพียงแคชเขตราก (ซึ่งจะใช้ในการบูตขั้นตอนการแก้ไขชื่อ) มันเป็นครั้งแรกที่จะไปแล้ว. เซิร์ฟเวอร์จะตอบสนองกับการตอบสนองต่อส่วนผู้มีอำนาจซึ่งโดยทั่วไปกล่าวว่า "ผมไม่ทราบ แต่ดูที่นี่สำหรับคนที่ไม่รู้" เช่นเดียวกับเซิร์ฟเวอร์สำหรับทำเกี่ยวกับ การตอบแบบสอบถามนี้ไม่ได้มีสิทธิ์และไม่รวมส่วนคำตอบที่เติม มันอาจรวมถึงสิ่งที่เรียกว่าเพิ่มเติมcom.com.comส่วนที่ให้การแมปที่อยู่สำหรับชื่อโฮสต์ใด ๆ ที่เซิร์ฟเวอร์เฉพาะรู้เกี่ยวกับ (จากบันทึกกาวหรือในกรณีของตัวแก้ปัญหาแบบเรียกซ้ำจากข้อมูลแคชก่อนหน้านี้) ตัวแก้ไขจะใช้การตอบสนองการมอบหมายนี้แก้ไขชื่อโฮสต์ของระเบียน NS หากจำเป็นและดำเนินการค้นหาเซิร์ฟเวอร์ DNS ที่ได้รับมอบอำนาจ กระบวนการนี้อาจทำซ้ำหลายครั้งถ้าคุณมีลำดับชั้นของคณะผู้แทนลึก แต่ในที่สุดก็ส่งผลในการตอบสนองการสอบถามกับ "คำตอบเผด็จการ" ชุดธง
สิ่งสำคัญคือต้องทราบว่าตัวแก้ไข (โดยทั่วไปแล้วหวังว่า) จะไม่พยายามทำลายชื่อโฮสต์ที่ได้รับการแก้ไขเพื่อถามเกี่ยวกับมันทีละชิ้น แต่จะส่งไปยังเซิร์ฟเวอร์ "ดีที่สุด" ที่รู้ เนื่องจากเซิร์ฟเวอร์ชื่อที่มีสิทธิ์โดยเฉลี่ยบนอินเทอร์เน็ตนั้นไม่มีสิทธิ์สำหรับชื่อ DNS ส่วนใหญ่ที่ถูกต้องการตอบสนองจึงเป็นการตอบสนองที่ไม่ได้รับอนุญาตซึ่งชี้ไปยังเซิร์ฟเวอร์ DNS อื่น
ตอนนี้เซิร์ฟเวอร์ไม่จำเป็นต้องตั้งชื่อในการมอบหมายหรือบันทึกอำนาจใด ๆ ที่จะมีสิทธิ์สำหรับโซน พิจารณาตัวอย่างของกรณีของเซิร์ฟเวอร์ต้นแบบส่วนตัว ในกรณีนั้นมีเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ซึ่งมีเฉพาะผู้ดูแลระบบของเซิร์ฟเวอร์ DNS ทาสสำหรับโซนเท่านั้นที่ทราบ เซิร์ฟเวอร์ DNS มีสิทธิ์สำหรับโซนหากผ่านกลไกบางอย่างในความเห็นของมันจะมีความรู้ที่ครบถ้วนและแม่นยำเกี่ยวกับโซนดังกล่าว เซิร์ฟเวอร์ DNS ที่มีสิทธิ์ตามปกติสามารถกลายเป็นไม่มีสิทธิ์ได้หากไม่สามารถเข้าถึงเซิร์ฟเวอร์ต้นแบบที่กำหนดค่าภายในเวลาที่กำหนดเป็นเวลาหมดอายุในระเบียน SOA
ควรพิจารณาเฉพาะคำตอบที่เชื่อถือได้เท่านั้น ทุกอย่างอื่นเป็นทั้งการมอบหมายหรือข้อผิดพลาดบางอย่าง การมอบหมายไปยังเซิร์ฟเวอร์ที่ไม่มีสิทธิ์เรียกว่าการมอบสิทธิ์ "lame" และหมายความว่าตัวแก้ไขจะต้องย้อนกลับไปหนึ่งขั้นตอนและลองใช้เซิร์ฟเวอร์ DNS ที่มีชื่ออื่น หากไม่มีเซิร์ฟเวอร์ชื่อที่สามารถเข้าถึงได้อย่างมีสิทธิ์ในการมอบหมายการระบุชื่อล้มเหลว (ไม่เช่นนั้นจะช้ากว่าปกติ)
นี้เป็นสิ่งสำคัญเพราะทุกข้อมูลที่ไม่ใช่เผด็จการจะต้องไม่ถูกเก็บไว้ เป็นไปได้อย่างไรที่เซิร์ฟเวอร์ที่ไม่ได้รับอนุญาตไม่มีภาพเต็ม ดังนั้นเซิร์ฟเวอร์ที่เชื่อถือได้จะต้องสามารถตอบคำถามที่ว่า "ใครควรจะเป็นผู้มีอำนาจและเพื่ออะไร" นั่นคือข้อมูลที่จัดทำโดยระเบียน NS ในโซน
มีกรณีขอบจำนวนหนึ่งซึ่งสิ่งนี้สามารถสร้างความแตกต่างได้อย่างจริงจังโดยมีศูนย์กลางอยู่ที่ป้ายชื่อโฮสต์หลายแห่งภายในโซนเดียว (อาจเป็นเรื่องธรรมดาเช่นกับโซน DNS ย้อนกลับโดยเฉพาะสำหรับช่วง IP แบบไดนามิกขนาดใหญ่) หรือเมื่อรายชื่อเซิร์ฟเวอร์แตกต่างกัน โซนหลักและโซนที่มีปัญหา (ซึ่งน่าจะเป็นข้อผิดพลาด แต่สามารถทำได้โดยเจตนาเช่นกัน)
คุณสามารถดูวิธีการทำงานในรายละเอียดเพิ่มเติมโดยใช้digและคุณสมบัติ+norec(ไม่ต้องเรียกซ้ำ) และ@คุณสมบัติตัวระบุเซิร์ฟเวอร์ สิ่งต่อไปนี้เป็นภาพประกอบของการทำงานของเซิร์ฟเวอร์ DNS การแก้ไขที่เกิดขึ้นจริง การค้นหาระเบียน A สำหรับการunix.stackexchange.comเริ่มต้นเช่นa.root-servers.net:
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
ดูอย่างใกล้ชิดflagsเช่นเดียวกับการนับต่อส่วน qrคือการตอบคำถามและaaเป็นคำตอบที่เชื่อถือได้ โปรดสังเกตว่าคุณได้รับมอบสิทธิ์ให้กับcomเซิร์ฟเวอร์เท่านั้น ทำตามการมอบหมายด้วยตนเอง (ในชีวิตจริงตัวแก้ไขแบบเรียกซ้ำจะใช้ที่อยู่ IP จากส่วนเพิ่มเติมหากมีให้หรือเริ่มต้นการจำแนกชื่อแยกต่างหากของหนึ่งในเซิร์ฟเวอร์ชื่อที่ระบุชื่อหากไม่มี IP ที่ระบุไว้ในการตอบสนองการมอบหมาย ข้ามส่วนนั้นและย้อนกลับไปที่ตัวแก้ไขปกติของระบบปฏิบัติการเพื่อดูตัวอย่าง):
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
ตอนนี้คุณจะเห็นว่าstackexchange.comได้รับมอบหมายให้ (ในหมู่คนอื่น ๆ ) ns1.serverfault.comและคุณยังไม่ได้รับคำตอบที่เชื่อถือได้ ทำตามการมอบหมายอีกครั้ง:
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
บิงโก! เราได้รับคำตอบเนื่องจากaaมีการตั้งค่าสถานะและมีที่อยู่ IP เหมือนกับที่เราต้องการค้นหา อย่างน้อยก็น่าสังเกตว่าอย่างน้อยในเวลาที่ฉันเขียนโพสต์นี้รายการเซิร์ฟเวอร์ชื่อที่ได้รับมอบหมายและรายการที่ได้รับมอบอำนาจนั้นแตกต่างกันแสดงว่าทั้งสองไม่จำเป็นต้องเหมือนกัน สิ่งที่ฉันได้อธิบายไว้ข้างต้นนั้นเป็นงานที่ทำโดยตัวแก้ไขใด ๆ ยกเว้นตัวแก้ไขที่ใช้งานจริงใด ๆ ก็จะแคชการตอบสนองไปพร้อมกันดังนั้นจึงไม่จำเป็นต้องไปที่เซิร์ฟเวอร์หลักทุกครั้ง
ดังที่คุณเห็นจากตัวอย่างด้านบนบันทึกการมอบหมายและกาวนั้นมีจุดประสงค์ที่แตกต่างจากบันทึกอำนาจและที่อยู่ในโซน
แคชการแก้ไขชื่อเซิร์ฟเวอร์โดยทั่วไปจะทำการตรวจสอบสติบางอย่างกับข้อมูลที่ส่งคืนเพื่อป้องกันการวางยาพิษของแคช ยกตัวอย่างเช่นมันอาจปฏิเสธที่จะแคชคำตอบการตั้งชื่อเซิร์ฟเวอร์สิทธิ์สำหรับcomจากแหล่งอื่นที่ไม่ใช่หนึ่งที่ได้รับการตั้งชื่อตามเขตปกครองเป็น deleged comไปหา รายละเอียดขึ้นอยู่กับเซิร์ฟเวอร์ แต่มีจุดประสงค์เพื่อแคชให้มากที่สุดเท่าที่จะเป็นไปได้ในขณะที่ไม่เปิดประตูโรงนาเพื่ออนุญาตให้เซิร์ฟเวอร์ชื่อสุ่มใด ๆ บนอินเทอร์เน็ตแทนที่ระเบียนผู้แทนสำหรับสิ่งใด ๆ