เมื่อ "มันเป็น DNS เสมอ" ไม่ใช่ DNS: การถกเถียงเรื่องโครงสร้างพื้นฐานที่เผยให้เห็นปัญหาที่ลึกกว่าที่คิด

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

ความแตกต่างระหว่างความเรียบง่ายและความซับซ้อน

หัวใจของการอภิปรายเกี่ยวข้องกับคำถามพื้นฐาน: DNS นั้นไม่น่าเชื่อถือโดยธรรมชาติ หรือเราแค่ใช้มันเพื่อจุดประสงค์ที่มันไม่ได้ถูกออกแบบมาเพื่อจัดการ? คำถามนี้ได้รับความเร่งด่วนใหม่เมื่อ CEO และ CTO ของ ccTLD registry เปิดเผยว่าการดำเนินงานของพวกเขาบันทึกสถิติการทำงานได้ 100% โดยมีพนักงานเพียง 30 คนดูแลไฟล์ข้อความขนาด 1GB สถิติความน่าเชื่อถืออันน่าทึ่งของพวกเขาตั้งอยู่ใน contrast อย่างชัดเจนกับผู้ให้บริการ cloud รายใหญ่ที่บางครั้งประสบกับปัญหา DNS ที่ร้ายแรง

ไม่ สิ่งที่เราทำนั้นเรียบง่าย พวกเขาใช้ DNS เพื่อแก้ปัญหาที่กระจายตัวทุกประเภท

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

การเปรียบเทียบความน่าเชื่อถือของ DNS:

มากกว่า DNS: ตัวการที่แท้จริงในความล้มเหลวของระบบ

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

การสนทนาได้ขยายออกไปเพื่อรวมจุดล้มเหลวทั่วไปอื่นๆ ของโครงสร้างพื้นฐานไว้ด้วย ดังที่ผู้แสดงความคิดเห็นหนึ่งคนระบุว่า แน่นอน... มันอาจจะเป็น BGP ซึ่งหมายถึงโปรโตคอล Border Gateway Protocol ที่จัดการการ routing ทางอินเทอร์เน็ต บางคนชี้ไปที่ปัญหาชั้นกายภาพ เช่น สายเคเบิลมีปัญหา หรือแม้แต่ปัจจัยด้านสิ่งแวดล้อม เช่น รังสีแกมมาที่ทำให้เกิดข้อผิดพลาดชั่วคราว รูปแบบนั้นชัดเจน: เมื่อระบบล้มเหลว เรามักจะโทษองค์ประกอบที่มองเห็นได้ชัดเจนที่สุด แทนที่จะสืบสวนสถาปัตยกรรมพื้นฐาน

จุดวิกฤตของโครงสร้างพื้นฐานทั่วไปนอกเหนือจาก DNS:

• ปัญหาการกำหนดเส้นทาง BGP (Border Gateway Protocol)
• ข้อผิดพลาดในการกำหนดค่า CORS (Cross-Origin Resource Sharing)
• ปัญหาในชั้นกายภาพ (สายเคเบิล, ตัวเชื่อมต่อ)
• สคริปต์อัตโนมัติที่มีผลกระทบที่ไม่ได้ตั้งใจ
• การเชื่อมต่อเครือข่ายระหว่างโฮสต์
• ความซับซ้อนในการนำ DNSSEC ไปใช้และการย้อนกลับ

DNSSEC: ขอบมีดที่คมจนทุกคนกลัว

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

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

ก้าวข้ามมeme

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

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

อ้างอิง: IT'S NOT ALWAYS DNS.