วิธีที่ถูกต้องในการตั้งค่า DNS หลัก / รอง / ... เพื่อลดความซ้ำซ้อนและความหน่วงแฝง

ฉันคิดว่า DNS หลัก / รองสำหรับวัตถุประสงค์ในการทำซ้ำซ้อนนั้นเรียบง่าย ความเข้าใจของฉันคือคุณควรมีหลักและรองอย่างน้อยหนึ่งและคุณควรตั้งค่ารองของคุณในสถานที่ที่แตกต่างกันทางภูมิศาสตร์ แต่ยังอยู่หลังเราเตอร์ที่แตกต่างกัน (ดูตัวอย่าง/server/48087 / Why-are-there-nameservers-for-my-domain )

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

อย่างไรก็ตาม sysadmins ของเราอ้างว่าสิ่งนี้ไม่ได้ช่วยอะไรมากหากศูนย์ข้อมูลอื่นไม่น่าเชื่อถือเท่ากับศูนย์ข้อมูลหลัก พวกเขาอ้างว่าลูกค้าส่วนใหญ่ยังคงไม่สามารถค้นหาได้อย่างเหมาะสมหรือหมดเวลานานเกินไปเมื่อศูนย์ข้อมูลหลักไม่ทำงาน

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

ฉันสามารถใช้เหตุผลอะไรในการกระตุ้นรูในการให้เหตุผล sysadmins ของเรา? แหล่งข้อมูลออนไลน์ใด ๆ ที่ฉันสามารถปรึกษาเพื่อเข้าใจปัญหาที่พวกเขาอ้างว่ามีอยู่ได้ดีขึ้น?

หมายเหตุเพิ่มเติมบางส่วนหลังจากอ่านคำตอบ:

• เราอยู่บน Linux
• เรามีความต้องการ DNS ที่ซับซ้อนเพิ่มเติม รายการ DNS ของเราได้รับการจัดการโดยซอฟต์แวร์ที่กำหนดเองบางส่วนโดยในปัจจุบัน BIND จะใช้งานจากการใช้งาน Twisted DNS และมีมุมมองบางส่วนในการผสมเช่นกัน อย่างไรก็ตามเราสามารถตั้งค่าเซิร์ฟเวอร์ DNS ของเราเองได้ที่ศูนย์ข้อมูลอื่น
• ฉันกำลังพูดถึง DNS ที่มีสิทธิ์สำหรับบุคคลภายนอกเพื่อค้นหาเซิร์ฟเวอร์ของเราไม่ใช่เซิร์ฟเวอร์ DNS แบบเรียกซ้ำสำหรับลูกค้าในพื้นที่ของเรา

มีเอกสาร "แนวทางปฏิบัติที่ดีที่สุด" ที่ยอดเยี่ยมมากแม้ว่าจะเป็นเทคนิคที่อาจพิสูจน์ได้ว่ามีประโยชน์เมื่อต่อสู้กับดูแลระบบของคุณ http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

หากเขา / เธอไม่รู้จักความถูกต้องของบทความที่เขียนโดย Cisco คุณอาจหยุดเถียงกับ sysadmin - เพิ่มระดับการจัดการ

เอกสาร "วิธีปฏิบัติที่ดีที่สุด" อื่น ๆ อีกมากมายแนะนำให้แยกเนมเซิร์ฟเวอร์หลักและรองของคุณไม่เพียง แต่โดยบล็อก IP แต่แยกตามที่ตั้งทางกายภาพ ในความเป็นจริง RFC 2182 แนะนำว่าบริการ DNS รองจะถูกแยกทางภูมิศาสตร์ สำหรับหลาย บริษัท ที่นี้หมายถึงการให้เช่าเซิร์ฟเวอร์ในดาต้าเซ็นเตอร์อื่นหรือสมัครรับผู้ให้บริการ DNS เป็นเจ้าภาพเช่นZoneEditหรือUltraDNS

อย่างไรก็ตาม sysadmins ของเราอ้างว่าสิ่งนี้ไม่ได้ช่วยอะไรมากหากศูนย์ข้อมูลอื่นไม่น่าเชื่อถือ เท่ากับศูนย์ข้อมูลหลัก พวกเขาอ้างว่าลูกค้าส่วนใหญ่ยังคงไม่สามารถค้นหาได้อย่างเหมาะสมหรือหมดเวลานานเกินไปเมื่อศูนย์ข้อมูลหลักไม่ทำงาน

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

โดยส่วนตัวแล้วฉันเชื่อว่าเราไม่ใช่ บริษัท เดียวที่มีปัญหาแบบนี้และเป็นไปได้มากว่าปัญหานี้ได้รับการแก้ไขแล้ว ฉันไม่สามารถจินตนาการได้ว่า บริษัท อินเทอร์เน็ตทั้งหมดที่ได้รับผลกระทบจากปัญหาของเรา

คุณไม่ได้เป็นเพียง บริษัท เดียวและนี่อาจจะได้รับการปรับปรุงใหม่หลายล้านครั้งใน บริษัท ทั่วโลก

อย่างไรก็ตามฉันไม่สามารถหาเอกสารออนไลน์ที่ดีที่อธิบายสิ่งที่เกิดขึ้นในกรณีที่เกิดข้อผิดพลาด (เช่นหมดเวลาของลูกค้า) และวิธีแก้ไขปัญหา

ฉันสามารถใช้เหตุผลอะไรในการกระตุ้นรูในการให้เหตุผล sysadmins ของเรา? แหล่งข้อมูลออนไลน์ใด ๆ ที่ฉันสามารถปรึกษาเพื่อเข้าใจปัญหาที่พวกเขาอ้างว่ามีอยู่ได้ดีขึ้น?

• ฉันกำลังพูดถึง DNS ที่มีสิทธิ์สำหรับบุคคลภายนอกเพื่อค้นหาเซิร์ฟเวอร์ของเราไม่ใช่เซิร์ฟเวอร์ DNS แบบเรียกซ้ำสำหรับลูกค้าในพื้นที่ของเรา

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

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

เหตุผลที่สิ่งนี้เป็นสิ่งผิดที่ต้องทำ:

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

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

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

ฉันต้องการแก้ไขปัญหานี้เนื่องจากเนมเซิร์ฟเวอร์การแก้ปัญหา Amazon EC2 ของเราไม่สามารถเข้าถึงได้สำหรับพนักงานหลายคนของเรา สิ่งนี้ทำให้เกิดความล่าช้าอย่างมากในกระบวนการของเราและแม้กระทั่งการหยุดทำงานในบางกรณีเนื่องจากเราต้องใช้การแก้ไข ฉันต้องการเซิร์ฟเวอร์ชื่อผู้ใช้ Google / Level3 ที่ล้มเหลวในกรณีที่ Amazon ล้มเหลวอีกครั้ง และถอยกลับโดยเร็วที่สุดเพราะจากนั้น Amazon จะแก้ไขชื่อโฮสต์ให้เป็นที่อยู่ในท้องถิ่นที่สามารถใช้งานได้การแก้ไขในเวลาแฝงที่ต่ำกว่าสำหรับการสื่อสารตัวอย่างเช่น

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

ฉันตัดสินใจที่จะใช้ crontab และทุบตีและเขียนnsfailover.sh หวังว่านี่จะช่วยได้

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

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

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

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

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

การตั้งค่าของเราคือ:

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

การตั้งค่านี้มีประสิทธิภาพมากพอที่จะทำให้เรามีเวลาประมาณ 5 9 ในช่วง 6 หรือ 7 ปีที่ผ่านมาแม้ว่าจะมีการหยุดทำงานของเซิร์ฟเวอร์เป็นครั้งคราวสำหรับการอัปเดต ฯลฯ หากคุณยินดีจ่ายเพิ่มอีกไม่กี่ดอลลาร์ โฮสติ้งของโซนกับคนอย่าง ultradns ...

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

ฉันใช้โหลดสูงสุดจากเราเตอร์ขอบของฉันทั้งหมดรวมเข้าด้วยกันแล้วหารด้วย 0.65 ... นั่นคือแบนด์วิดท์ขั้นต่ำที่เราต้องมีในแต่ละศูนย์ข้อมูล ฉันวางกฎนั้นไว้เมื่อประมาณ 5 ปีที่แล้วพร้อมกับเอกสารบางอย่างเพื่อพิสูจน์ว่าฉันรวบรวมจาก CCO และเกี่ยวกับอินเทอร์เน็ตและมันไม่เคยล้มเหลวเรา อย่างไรก็ตามคุณต้องตรวจสอบสถิติเหล่านั้นอย่างน้อยทุกไตรมาส เรามีปริมาณการใช้งานเพิ่มขึ้นเกือบ 3 เท่าระหว่างเดือนพฤศจิกายนถึงเดือนกุมภาพันธ์ปีที่แล้วและฉันไม่ได้เตรียมการไว้ ด้านที่สว่างไสวนั่นคือสถานการณ์ทำให้ฉันสามารถสร้างข้อมูลที่ชัดเจนอย่างหนักซึ่งบอกว่าโหลด 72% ในวงจร WAN ของเราเราเริ่มทิ้งแพ็กเก็ต ไม่มีเหตุผลเพิ่มเติมที่ฉันต้องการสำหรับแบนด์วิดท์มากขึ้น

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

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

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

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

DNS รองถูกแบ่งตามภูมิศาสตร์และแยกเครือข่ายเป็นสิ่งที่ดี คุณอาจจะสามารถแลกเปลี่ยน DNS รองกับ บริษัท ที่เป็นมิตรและมีผู้ให้บริการ DNS มากมายที่คุณสามารถจ่ายให้คุณได้ ผู้รับจดทะเบียนบางรายมี DNS รองเป็นบริการเช่นกัน

โทมัส

หลังจากอ่านอัปเดตของคุณฉันได้แก้ไขโพสต์ของฉัน (โพสต์ก่อนหน้านี้มีการอ้างอิงถึงซอฟต์แวร์ Windows)

ดูเหมือนว่าฉันจะชอบระบบดูแลระบบของคุณกำลังบอกคุณว่าตำแหน่งรองของคุณไม่มีฮาร์ดแวร์ที่จำเป็นในการจัดการโหลดเต็มหรือไม่

ดูเหมือนว่าเขากำลังพูดว่า "เฮ้เพื่อนถ้าตำแหน่งหลักของเรา (ซึ่งรวมถึง DNS หลัก) ลงไป DNS นั้นเป็นความกังวลอย่างน้อยของเราเพราะถ้า COLO1 ลงแล้ว COLO2 ไม่สามารถจัดการโหลดได้"

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

ในโลกที่สมบูรณ์แบบนั้น COLO1 และ COLO2 จะสามารถยืนอยู่คนเดียวและจัดการกับภาระของคุณได้

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

ฉันใช้วิธีนี้ในสภาพแวดล้อมขนาดเล็กถึงเหมาะสมและใช้งานได้ดี โดยทั่วไปแล้ว Failover ใช้เวลาน้อยกว่า 10 นาที

คุณเพียงแค่ต้องตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ DNS ของคุณสามารถรองรับโหลดพิเศษของ TTL สั้น ๆ (เวลาใช้งาน)

หวังว่านี่จะช่วยได้

ผู้ดูแลระบบของคุณผิด (ส่วนใหญ่)

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

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

หากจำเป็น (เพื่อเอาใจ sysadmins) ให้รันเซิร์ฟเวอร์สองเครื่องที่ศูนย์ข้อมูลหลักของคุณต่อไป

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

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

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

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