ตัวแก้ไข DNS เทียบกับระเบียน NS TTL

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

ใช่ เนมเซิร์ฟเวอร์แบบเรียกซ้ำที่เหมาะสมจะพิจารณาเนมเซิร์ฟเวอร์ทั้งหมดและจะพยายามค้นหาเนมเซิร์ฟเวอร์ที่เร็วที่สุดในภายหลังในแต่ละครั้ง

อัลกอริทึมคร่าวๆ คือ:

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

หากตัวแก้ไขใช้เซิร์ฟเวอร์ NS ที่ 1

หยุดตรงนี้. บันทึกมาในชุดไม่ใช่รายการ นั่นคือไม่มีลำดับโดยธรรมชาติใน DNS แน่นอนว่ามีคำสั่งในสายหรือการแสดง แต่ไม่ได้มาจากโปรโตคอล

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

เมื่อเซิร์ฟเวอร์ชื่อที่เชื่อถือได้ไม่ตอบสนอง

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

หมายความว่าฉันต้องตั้งค่า TTL แบบสั้นสำหรับระเบียน NS หรือไม่

อาจจะ แต่ส่วนใหญ่ไม่เกี่ยวข้อง ทำไม เพราะของคุณ สวพ.FM91 มีการเผยแพร่ระเบียนในโซนหลักของโดเมนของคุณ เพื่อให้แน่ใจว่ามีการมอบหมาย DNS แน่นอนว่ามีการเผยแพร่ที่นั่นด้วย TTL เนื่องจากบันทึกทั้งหมดมี TTL แนบมาด้วย แต่เผยแพร่ในโซนที่คุณไม่ได้ควบคุม ดังนั้นคุณจึงไม่สามารถเลือกค่า TTL ได้

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

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

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

ดังนั้นหากคุณดูว่าเกิดอะไรขึ้นในเนมเซิร์ฟเวอร์ TLD (โฮสต์นั้น สวพ.FM91 บันทึกสำหรับโดเมนทั้งหมดภายใต้ TLD นั้น) หรือในคำแนะนำต่าง ๆ คุณมักจะเห็น สวพ.FM91 บันทึกด้วย TTL 1 หรือ 2 วัน

มีคำแนะนำเกี่ยวกับวิธีที่ตัวแก้ไข DNS ทำงานร่วมกับ NS ที่ไม่ตอบสนองและ TTL อย่างไร

ตัวแก้ไขแต่ละตัวทำ :-) สิ่งนี้ไม่ได้ระบุโดยโปรโตคอล แต่เป็นรายละเอียดการใช้งาน คุณสามารถศึกษาซอร์สโค้ดของซอร์สโค้ดที่คุณสามารถติดตั้งได้ แต่อาจไม่สามารถรวบรวมรายละเอียดเกี่ยวกับซอร์สโค้ดจากผู้ให้บริการ DNS แบบเรียกซ้ำสาธารณะรายใหญ่ได้

คุณสามารถดูรายละเอียดเพิ่มเติมได้ที่นี่:

• https://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/
• https://www.nanog.org/meetings/nanog54/presentations/Tuesday/Yu.pdf

RFC 1034 §5.3.3 ให้ข้อมูลบางอย่างด้วย (โปรดทราบว่ามันคำนึงถึงกรณีหนึ่งที่คุณลืม: เซิร์ฟเวอร์ชื่อหนึ่งๆ อาจมีที่อยู่ IP หลายที่อยู่ - ทุกวันนี้ควรเป็นเช่นนั้นเสมอ โดยมี IPv4 หนึ่งรายการและ IPv6 หนึ่งรายการ - และไม่มีการรับประกันว่าคุณจะได้รับผลลัพธ์ในระยะเวลาที่เท่ากันในแต่ละรายการ):

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

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

RFC 1035 §7.2 มีสิ่งนี้ว่า:

ในการเริ่มต้น SLIST ให้สมบูรณ์ ตัวแก้ไขจะแนบอะไรก็ตาม ข้อมูลประวัติที่มีในแต่ละที่อยู่ใน SLIST นี่จะ มักจะประกอบด้วยค่าเฉลี่ยถ่วงน้ำหนักบางประเภทสำหรับเวลาตอบสนอง ของที่อยู่ และค่าเฉลี่ยของที่อยู่ (เช่น บ่อยแค่ไหน ที่อยู่ตอบกลับคำขอทั้งหมด) โปรดทราบว่าสิ่งนี้ ข้อมูลควรเก็บไว้ตามที่อยู่มากกว่าตามที่อยู่ พื้นฐานเนมเซิร์ฟเวอร์ เนื่องจากเวลาตอบสนองและค่าเฉลี่ยบอลของ a เซิร์ฟเวอร์เฉพาะอาจแตกต่างกันไปมากจากที่อยู่หนึ่งไปยังอีกที่อยู่หนึ่ง บันทึก นอกจากนี้ ข้อมูลนี้มีความเฉพาะเจาะจงกับที่อยู่ตัวแก้ไข / คู่ที่อยู่เซิร์ฟเวอร์ ดังนั้นตัวแก้ไขที่มีหลายที่อยู่อาจต้องการ เก็บประวัติแยกกันสำหรับแต่ละที่อยู่ ส่วนหนึ่งของขั้นตอนนี้ ต้องจัดการกับที่อยู่ที่ไม่มีประวัติดังกล่าว ในกรณีนี้ เวลาไปกลับที่คาดไว้ 5-10 วินาทีควรเป็นกรณีที่แย่ที่สุดด้วย ค่าประมาณที่ต่ำกว่าสำหรับเครือข่ายท้องถิ่นเดียวกัน ฯลฯ

โปรดทราบว่าเมื่อใดก็ตามที่มีการมอบหมายตาม อัลกอริทึมตัวแก้ไข เริ่มต้น SLIST ใหม่

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

นอกจากนี้เพื่อสิ้นสุดและโดยเฉพาะอย่างยิ่งเกี่ยวกับเรื่องนี้:

ตามที่แสดงในข้อเขียนนี้จากเปรต

บทความนี้ที่คุณอ้างอิงพูดถึงปัญหาที่เกิดขึ้นกับผู้ใช้ Dyn nameservers เมื่อมีการหยุดทำงาน ใช่แล้ว หากคุณใช้เฉพาะเนมเซิร์ฟเวอร์ Dyn แสดงว่าคุณมีปัญหา แม้ว่าคุณจะเปลี่ยนโซนไปใช้โซนอื่นก็ตาม สวพ.FM91 บันทึก TTL หมายความว่าการเปลี่ยนแปลงของคุณจะไม่เห็นในทันที แต่ในความเป็นจริงไม่ได้พูดอะไรมากเกี่ยวกับ TTL แต่พูดมากเกี่ยวกับการจัดการ DNS: หากคุณต้องการความยืดหยุ่น สำหรับโซนที่สำคัญ อย่าใช้ผู้ให้บริการ DNS รายเดียว แต่ใช้ผู้ให้บริการหลายราย (ซึ่งแน่นอนว่าต้องมีการประสานงานระหว่าง คุณไม่สามารถผสมและจับคู่ผู้ให้บริการ X และ Y โดยพลการได้ และจะยิ่งซับซ้อนมากขึ้นหากคุณผ่าน DNSSEC ในการผสม แต่เป็นไปได้) ด้วยวิธีนี้ เนื่องจากอัลกอริทึมที่ร่างไว้ด้านบนอย่างรวดเร็ว แม้ว่า 2 ใน 5 จะบอกว่าเนมเซิร์ฟเวอร์ไม่สามารถตอบกลับได้ทั้งหมดเนื่องจากผู้ให้บริการรายนี้มีปัญหา ผู้ให้บริการรายอื่นจะรับภาระและทำให้โดเมนของคุณทำงานได้อาจมีความล่าช้าเป็นพิเศษในการค้นหาใหม่แต่ละครั้งสำหรับผู้เยี่ยมชม (เนื่องจากเนมเซิร์ฟเวอร์แบบเรียกซ้ำทั้งหมดไม่สามารถเข้าใจได้ทันทีว่าพวกเขาต้องเปลี่ยนไปใช้เนมเซิร์ฟเวอร์เฉพาะเนื่องจาก 2 ใน 5 หยุดทำงาน) และยังมีความล่าช้ามากขึ้นเนื่องจากอีก 3 รายการมีจำนวนมากขึ้น ข้อความค้นหามากกว่าปกติ (DNS จะทำการโหลดบาลานซ์ตามค่าเริ่มต้น ดังนั้นในทางทฤษฎีแล้ว แต่ละเนมเซิร์ฟเวอร์จะได้รับข้อความค้นหาในปริมาณที่เท่ากันโดยประมาณ) แต่จะมีการตอบกลับ

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