นี่คือตัวอย่างกฎของ bailiwick ที่ฉันไม่เข้าใจ:
กำลังแก้ไข อะโดบี.เน็ต จาก สุทธิ. เซิร์ฟเวอร์ TLD ให้:
;; ส่วนผู้มีอำนาจ:
อะโดบี.เน็ต. 172800 ใน NS ns1.omtrdc.net
อะโดบี.เน็ต. 172800 ใน NS ns2.omtrdc.net
;; ส่วนเพิ่มเติม:
ns1.omtrdc.net. 172800 ใน 66.235.157.6
ns2.omtrdc.net. 172800 ใน 66.235.157.7
และกำลังแก้ไข ns1.omtrdc.net. ให้:
;; ส่วนผู้มีอำนาจ:
omtrdc.net. 172800 ใน NS ns201.adobe.net
omtrdc.net. 172800 ใน NS ns202.adobe.net
;; ส่วนเพิ่มเติม:
ns201.adobe.net. 172800 ใน A 204.74.108.252
ns202.adobe.net. 172800 ใน A 204.74.109.252
หากส่วนเพิ่มเติมไม่น่าเชื่อถือในทั้งสองกรณี จะนำไปสู่การวนซ้ำ
ตามที่ฉันเข้าใจ bailiwick มีกฎสองข้อ:
ns1.omtrdc.net. ไม่ใช่ส่วนย่อยของ อะโดบี.เน็ต.ดังนั้น IP ในส่วนเพิ่มเติมจึงไม่สามารถเชื่อถือได้อย่างไรก็ตามฉันได้เห็นการใช้งานบางอย่างที่พวกเขาเชื่อถือได้เพราะ ns1.omtrdc.net. เป็นส่วนย่อยของ .สุทธิ (เซิร์ฟเวอร์ TLD ที่ตอบกลับ)
ถ้าฉันเข้าใจดี (หลังจากอ่านเอกสารและการใช้งานบางส่วน) เนื่องจากเซิร์ฟเวอร์ TLD จัดการไฟล์ สุทธิ. โซนเราสามารถเชื่ออะไรภายใต้ สุทธิ.เช่น IP ของ ns1.omtrdc.net. นั่นคือ NS ของ อะโดบี.เน็ต.
มันสมเหตุสมผลหรือฉันลืมส่วนสำคัญบางอย่างไป?
ฉันไม่แน่ใจว่าจะเห็นคำถามของคุณจริงๆ
เพิ่มเติม ถูกกำหนดให้เป็นตัวเลือก (ดังนั้นไคลเอนต์จึงมีอิสระที่จะเพิกเฉยต่อข้อมูลนั้น และด้วยเหตุผลด้านความปลอดภัย จึงควรเพิกเฉยข้อมูลดังกล่าวเกือบตลอดเวลา)... ยกเว้นเมื่อไม่มีวิธีอื่นในการบรรลุบางสิ่งซึ่งก็คือกาว
แต่ปัญหาคือ DNSSEC ไม่ครอบคลุมกาวเพิ่มเติม ดังนั้นจึงไม่ได้รับการรับรอง ดังนั้นจึงต้องจัดการด้วยความระมัดระวัง
โปรดทราบว่ากรณีของคุณ อะโดบี.เน็ต ใช้เนมเซิร์ฟเวอร์ภายใต้ omtrdc.net ไม่ใช่คำจำกัดความของ "อิน-ไบลิวิค" มันน่าจะเป็นใน Bailiwick ถ้าชื่อเนมเซิร์ฟเวอร์อยู่ภายใต้ด้วย อะโดบี.เน็ต. ดังนั้นกรณีของคุณจึงเป็นเพียงสิ่งที่เรียกว่า "เนมเซิร์ฟเวอร์ภายใน" เนื่องจากชื่อเนมเซิร์ฟเวอร์นั้นอยู่ภายในรีจิสตรีเดียวกันกับชื่อโดเมนที่ได้รับอนุญาต
[ ด้านข้าง บันทึกส่วนตัวตามจริง: ฉันรู้สึกว่าการตั้งค่าโดเมน A นี้โดยใช้เนมเซิร์ฟเวอร์ภายใต้โดเมน B ซึ่งเนมเซิร์ฟเวอร์กลับมาอยู่ภายใต้โดเมน A นั้นอันตรายมาก ผิดพลาดประการใดในอ หรือ B อาจปิดใช้งานความละเอียดของทั้ง A และ ข; นี่คือการวนซ้ำบางประเภท และควรหลีกเลี่ยงการวนซ้ำใน DNS (หรือได้รับการปฏิบัติด้วยความระมัดระวังและการลดและป้องกันที่เหมาะสม) ]
คุณสามารถค้นหาคำจำกัดความที่ยอดเยี่ยมมากมายใน RFC 8499 เกี่ยวกับคำศัพท์ DNS
มีตัวอย่างดังนี้
Bailiwick: "In-bailiwick" เป็นตัวดัดแปลงเพื่ออธิบายเนมเซิร์ฟเวอร์ ที่มีชื่อเป็นโดเมนย่อยของหรือ (ไม่ค่อย) เหมือนกับของ ที่มาของโซนที่มีการมอบหมายชื่อ เซิร์ฟเวอร์
ส่วน
มันสมเหตุสมผลหรือฉันลืมส่วนสำคัญบางอย่างไป? คุณทำได้ดีโดยการแสดงผลลัพธ์ DNS ของขุดหรือที่คล้ายกัน แต่สิ่งที่ขาดหายไป/คลุมเครือคือเซิร์ฟเวอร์ชื่อใดที่คุณสืบค้นข้อมูล คุณควรแสดงและศึกษาสิ่งนั้นเพื่อให้เห็นภาพชัดเจน ในกรณีส่วนใหญ่ของความเข้าใจผิดใน DNS ฉันเห็นว่าเกิดจากความสับสนระหว่างเซิร์ฟเวอร์ชื่อที่เชื่อถือได้และเรียกซ้ำ
เพิ่มเติม ส่วนถูกกำหนดเช่นนั้นใน RFC 1034:
เพิ่มเติม
ดำเนินการ RRs ซึ่งอาจเป็นประโยชน์ในการใช้ RRs ใน ส่วนอื่น ๆ
จากนั้นมาอย่างสมบูรณ์ใน §4.3.2 ที่อธิบายอัลกอริทึมการแก้ปัญหา:
คัดลอก NS RRs สำหรับโซนย่อยไปยังหน่วยงาน ส่วนของคำตอบ ใส่ที่อยู่อะไรก็ได้ มีอยู่ในส่วนเพิ่มเติมโดยใช้กาว RRs หากไม่มีที่อยู่จากผู้มีอำนาจ ข้อมูลหรือแคช ไปที่ขั้นตอนที่ 4
กลับไปที่ RFC 8499 คุณจะได้รับคำอธิบายเพิ่มเติม:
การตอบกลับที่มีการอ้างอิงเท่านั้นมีคำตอบที่ว่างเปล่า ส่วน. ประกอบด้วย NS RRset สำหรับโซนที่อ้างถึงใน ส่วนอำนาจหน้าที่. อาจมี RR ที่ให้ที่อยู่ใน ส่วนเพิ่มเติม AA บิตมีความชัดเจน
และ
ในกรณีที่แบบสอบถามตรงกับนามแฝง และเซิร์ฟเวอร์คือ ไม่น่าเชื่อถือสำหรับเป้าหมายของนามแฝง แต่เป็นผู้มีอำนาจ สำหรับบางชื่อที่อยู่เหนือเป้าหมายของนามแฝง ความละเอียด อัลกอริทึมจะสร้างการตอบสนองที่มีทั้ง คำตอบที่เชื่อถือได้สำหรับนามแฝงและการอ้างอิง ดังกล่าวบางส่วน คำตอบและคำตอบอ้างอิงมีข้อมูลในส่วนคำตอบ มัน มี NS RRset สำหรับโซนที่อ้างถึงในหน่วยงาน ส่วน. อาจมี RR ที่ให้ที่อยู่ใน ส่วนเพิ่มเติม
ส่วน:
อย่างไรก็ตาม ฉันได้เห็นการใช้งานบางอย่าง
ใช่เนื้อหาของ เพิ่มเติม อาจเปลี่ยนแปลงได้ขึ้นอยู่กับเนมเซิร์ฟเวอร์ที่คุณสอบถามและกำหนดค่าอย่างไร ดูตัวอย่าง การตอบสนองขั้นต่ำ ตัวเลือกของ Bind, เอกสารที่ https://bind9.readthedocs.io/en/latest/reference.html ระบุ: "ตัวเลือกนี้ควบคุมการเพิ่มระเบียนไปยังหน่วยงานและส่วนเพิ่มเติมของการตอบสนอง บันทึกดังกล่าวอาจรวมอยู่ในการตอบสนองเพื่อเป็นประโยชน์กับลูกค้า ตัวอย่างเช่น ระเบียน NS หรือ MX อาจมีระเบียนที่อยู่ที่เกี่ยวข้องรวมอยู่ในส่วนเพิ่มเติม หลีกเลี่ยงความจำเป็นในการค้นหาที่อยู่แยกต่างหาก อย่างไรก็ตาม การเพิ่มบันทึกเหล่านี้ในการตอบสนองไม่จำเป็นและต้องมีการค้นหาฐานข้อมูลเพิ่มเติม มีค่าที่เป็นไปได้ 4 ค่า ดังนั้นพฤติกรรมต่างๆ มากมายทางออนไลน์
และสุดท้ายสำหรับ:
เนื่องจากเซิร์ฟเวอร์ TLD จัดการเน็ต โซนเราจะเชื่ออะไรก็ได้ตามเน็ต
ใช่และไม่ :-). ยกตัวอย่าง "การทดลอง" ของ Verisign SiteFinder ในอดีต: คุณสอบถามเซิร์ฟเวอร์ชื่อที่มีสิทธิ์ของ com สำหรับชื่อที่ไม่มีอยู่ และคุณได้รับกลับมา ก บันทึก. คุณเชื่อหรือไม่?
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
