เหตุขัดข้องของ Cloudflare 1.1.1.1 เมื่อวันที่ 14 กรกฎาคม 2025

• Cloudflare ทำให้ ตัวแก้ไข DNS สาธารณะ 1.1.1.1 เกิดเหตุขัดข้องเต็มรูปแบบนาน 62 นาที ระหว่างการเปลี่ยนแปลงโทโพโลยีของบริการเมื่อวันที่ 14 กรกฎาคม 2025
• ผู้ใช้ทั่วโลกส่วนใหญ่ ได้รับผลกระทบโดยตรง จนใช้งานอินเทอร์เน็ตไม่ได้
• สาเหตุของเหตุขัดข้องมาจาก การตั้งค่าผิดพลาดในระบบเลกาซีภายใน และไม่เกี่ยวข้องกับการโจมตีจากภายนอกหรือ BGP hijacking
• เหตุขัดข้องถูกกระตุ้นจาก การสะสมของการเปลี่ยนแปลงการตั้งค่าที่ผิดพลาด ร่วมกับการรีเซ็ตทั้งเครือข่าย
• มาตรการป้องกันการเกิดซ้ำ ได้แก่ การนำระบบ deploy แบบค่อยเป็นค่อยไปมาใช้ และเตรียมยกเลิกระบบจัดการการตั้งค่าแบบเลกาซี

---

ภาพรวม

เมื่อวันที่ 14 กรกฎาคม 2025 Cloudflare ได้ก่อให้เกิดเหตุขัดข้องของเครือข่ายทั่วโลกกับ ตัวแก้ไข DNS สาธารณะ 1.1.1.1 ระหว่างการเปลี่ยนแปลงโทโพโลยีของบริการ ส่งผลให้ผู้ใช้ที่ใช้งานบริการ 1.1.1.1 และ Gateway DNS ประสบกับ การใช้งานอินเทอร์เน็ตไม่ได้ หรือประสิทธิภาพบริการลดลงอย่างรุนแรงเป็นเวลา 62 นาที สาเหตุเกิดจาก ความผิดพลาดในการตั้งค่าภายในระบบเลกาซี ไม่ได้เกิดจากการโจมตีภายนอกหรือ BGP hijacking

ขอบเขตและผลกระทบของเหตุขัดข้อง

• ระหว่าง 21:52 UTC ~ 22:54 UTC ตัว Resolver 1.1.1.1 อยู่ในสภาพที่แทบใช้งานไม่ได้ทั่วโลก
• ลูกค้าทั่วโลกส่วนใหญ่ไม่สามารถแปลงชื่อโดเมนได้ ทำให้ใช้งานอินเทอร์เน็ตแทบไม่ได้เลย
• สามารถตรวจสอบสถานการณ์ขณะเกิดเหตุได้ผ่าน Cloudflare Radar
• สาเหตุของเหตุขัดข้องมาจาก การตั้งค่าที่ไม่ถูกต้อง ในระบบเลกาซีที่ใช้จัดการโครงสร้างพื้นฐานซึ่งควบคุมการประกาศ IP address ของ Cloudflare สู่โลกอินเทอร์เน็ต
• ทราฟฟิกทั้งหมดที่เข้าถึง Cloudflare ผ่านช่องทาง 1.1.1.1 ได้รับผลกระทบอย่างรุนแรง

สาเหตุและภูมิหลังของเหตุขัดข้อง

• Cloudflare ใช้ Anycast routing สำหรับบริการทั่วโลก เช่น DNS Resolver
• แม้จะให้บริการในหลายภูมิภาค แต่บางบริการที่ต้องปฏิบัติตามข้อกำหนดด้าน data localization จะถูกจำกัดไว้เฉพาะบางพื้นที่
• วันที่ 6 มิถุนายน ระหว่างการเปลี่ยนแปลงการตั้งค่าเพื่อเตรียมบริการ DLS (data localization) ในอนาคต ช่วง IP ของ Resolver 1.1.1.1 ถูกใส่เข้าไปใน DLS ใหม่โดยไม่ตั้งใจ
  • ความผิดพลาดนี้ไม่ได้ถูกนำไปใช้ทันทีและยังไม่ส่งผลจริง จึงไม่มีการแจ้งเตือน
• วันที่ 14 กรกฎาคม มีการเปลี่ยนแปลงเพื่อเพิ่มตำแหน่งออฟไลน์สำหรับการทดสอบเข้าไปในโทโพโลยี DLS
  • การเปลี่ยนแปลงนี้ทำให้เกิดการ รีเฟรชการตั้งค่าเครือข่ายทั้งระบบแบบบังคับ จนเผยให้เห็นความผิดพลาดเดิม
  • Prefixes ของ 1.1.1.1 ถูกถอนออกจาก data center ทั่วโลก ทำให้บริการหยุดชะงัก

ไทม์ไลน์ของเหตุขัดข้อง (สรุป)

• 2025-06-06 17:38: การเปลี่ยนแปลงการตั้งค่าสำหรับบริการ DLS มี การรวม 1.1.1.1 Prefixes เข้าไปด้วย (ยังไม่กระทบ, ความผิดพลาดแฝงอยู่)
• 2025-07-14 21:48: การเปลี่ยนแปลงการตั้งค่าทำให้เกิดการรีเฟรชการตั้งค่าทั้งเครือข่าย และเริ่มถอน 1.1.1.1 Prefixes ทั่วโลก
• 2025-07-14 21:52: ทราฟฟิก DNS ทั่วโลกลดลงอย่างรวดเร็ว
• 2025-07-14 22:01: มีการแจ้งเตือนภายในและประกาศเหตุขัดข้อง
• 2025-07-14 22:20: rollback ไปยังการตั้งค่าก่อนหน้า และเริ่มขั้นตอนกู้คืนบริการ
• 2025-07-14 22:54: ทราฟฟิกกลับสู่ภาวะปกติ ยกเลิกการแจ้งเตือน และสิ้นสุดเหตุขัดข้อง

IP และโปรโตคอลที่ได้รับผลกระทบ

• ขอบเขตผลกระทบ: Prefixes ของ IPv4 และ IPv6 จำนวนมาก เช่น 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48
• สังเกตพบว่าทราฟฟิกลดลงอย่างรวดเร็วในคำขอที่ใช้ UDP, TCP, DoT(DNS over TLS)
• DoH(DNS over HTTPS) แทบไม่ได้รับผลกระทบ เพราะส่วนใหญ่ใช้งานผ่านโดเมน cloudflare-dns.com

คำอธิบายทางเทคนิคของเหตุขัดข้อง

เหตุขัดข้องของบริการ Resolver 1.1.1.1

• มีการแทรกความผิดพลาดของ Prefixes ระหว่างกระบวนการเปลี่ยนแปลงการตั้งค่าล่วงหน้าสำหรับ DLS เมื่อวันที่ 6 มิถุนายน
• วันที่ 14 กรกฎาคม มีการเพิ่มตำแหน่งออฟไลน์เพื่อการทดสอบ ทำให้การตั้งค่าทั่วทั้งเครือข่ายถูกรีเฟรช
• ในกระบวนการนี้ Prefixes ของ Resolver 1.1.1.1 ถูกจำกัดทั่วโลกให้เหลือเพียงตำแหน่งออฟไลน์จุดเดียว ส่งผลให้บริการถูกถอนออก

การวิเคราะห์สาเหตุทางเทคนิค

• ปัจจุบัน Cloudflare ดำเนินการ ระบบเลกาซีและระบบเชิงกลยุทธ์รุ่นใหม่ ควบคู่กัน และซิงก์การประกาศเส้นทาง routing ตาม address space

• ระบบเลกาซีมีความเสี่ยงต่อความผิดพลาดสูงกว่า เนื่องจากต้องอัปเดตด้วยมือและไม่มีการ deploy แบบค่อยเป็นค่อยไป

  • แม้จะมีการ peer review และการตรวจสอบโดยวิศวกรคนอื่น แต่ก็ ไม่มีโครงสร้างที่รับประกันการนำไปใช้แบบค่อยเป็นค่อยไป เช่น canary deployment

• แนวทางใหม่ใช้โทโพโลยีเป็นศูนย์กลางแทนการ hardcode และมี ระบบนำการเปลี่ยนแปลงไปใช้แบบค่อยเป็นค่อยไปพร้อมการมอนิเตอร์

• 22:01 มีการแจ้งเตือนเกี่ยวกับ DNS Resolver

• ยืนยันได้จากตาราง routing ภายในแบบ BGP ว่าเส้นทางของ Resolver หายไปทั้งหมด

• หลังการถอน Prefixes, subnet 1.1.1.0/24 มีความพยายามประกาศ BGP จาก Tata Communications India(AS4755)

  • แม้จะดูคล้าย Prefix Hijack ชั่วคราว แต่ไม่เกี่ยวข้องโดยตรงกับอุบัติเหตุครั้งนี้

ขั้นตอนการกู้คืนและมาตรการติดตามผล

• 22:20 UTC, rollback กลับสู่การตั้งค่าก่อนหน้า และประกาศ Prefixes ใหม่
  • ทราฟฟิกประมาณ 77% ฟื้นตัวกลับมาทันที
  • edge server บางส่วนถูกรีเซ็ตอัตโนมัติ จึงต้องนำการเปลี่ยนแปลงกลับไปใช้ใหม่ผ่านระบบจัดการการเปลี่ยนแปลงแบบแมนนวล
  • โดยปกติจะทำ rollout แบบค่อยเป็นค่อยไปเพื่อความปลอดภัยของเครือข่าย แต่ในเหตุการณ์นี้มีการนำไปใช้โดยเร็วหลังยืนยันความถูกต้องแล้ว
• 22:54 ทุกตำแหน่งกลับสู่ภาวะปกติ

แนวทางปรับปรุงในอนาคต

• นำระบบ deploy แบบค่อยเป็นค่อยไป (Stage Deployment) มาใช้: ยกเลิกวิธี deploy แบบเลกาซี และนำโครงสร้าง rollback อัตโนมัติตามสถานะสุขภาพระบบมาใช้
• เร่งยกเลิกระบบเลกาซี: ลบรูปแบบการตั้งค่าและ deploy ด้วยมือที่มีความเสี่ยง พร้อมเสริมเอกสารและ test coverage

บทสรุป

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

[GN⁺]

ความเห็นจาก Hacker News

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

  • Cloudflare แนะนำให้ตั้งทั้ง 1.1.1.1 และ 1.0.0.1 เป็น DNS เซิร์ฟเวอร์ แต่เพราะความผิดพลาดของการตั้งค่าที่ทำให้เกิดเหตุขัดข้องครั้งนี้ การประกาศ BGP ของ Cloudflare สำหรับทั้งพรีฟิกซ์ 1.1.1.0/24 และ 1.0.0.0/24 จึงหยุดลง
  • บน Android เท่าที่ทราบ สามารถกรอกได้เพียงค่าเดียวใน Settings-Network & Internet-Private DNS ตรง "Private DNS provider hostname" และไม่เข้าใจว่าทำไมถึงไม่รับ IP (1.1.1.1) แต่บังคับให้ใช้ชื่อโฮสต์ (one.one.one.one) การกำหนด DNS เซิร์ฟเวอร์ด้วย IP ดูสมเหตุสมผลกว่ามาก
  • การใส่สองตัวดีกว่าไม่มีเลย แต่ก็ไม่ได้สมบูรณ์แบบ ถ้าฝั่งหนึ่งล่ม โดยทั่วไปจะเจอเวลารอนานและปัญหาเป็นช่วง ๆ เพราะระบบไม่ได้ติดตามว่าตัวไหนยังทำงานปกติ เว้นแต่จะใช้การตั้งค่าขั้นสูงอย่าง local caching DNS proxy ที่มี upstream มากกว่าหนึ่งตัว
  • ถ้าคิดว่าคุยเรื่อง DNS ได้ ก็ควรดูแลบริการเอง โดเมนราก "." ทำงานได้ดีมาหลายสิบปีแล้ว และสาเหตุหลักที่ 1.1.1.1 มีปัญหาไม่ใช่ DNS เองแต่เป็น anycast Cloudflare (รวมถึง Google) ยืนกรานใช้ IP แบบ "vanity" ซึ่งต้องอาศัย anycast จึงจะทำได้ และปัญหาที่แท้จริงไม่ใช่ DNS แต่คือ anycast แนะนำให้เลือกและตั้งค่าผู้ให้บริการมากกว่าหนึ่งราย
  • การตั้งค่าที่ Cloudflare แนะนำคือให้มี 1.0.0.1 เป็น DNS สำรองด้วย แต่ในเหตุการณ์ครั้งนี้เซิร์ฟเวอร์นั้นก็ได้รับผลกระทบเหมือนกัน

• น่าสนใจที่ในช่วงล่มราว 20 นาที ทราฟฟิกของ 1.1.1.1 ลดลงเพียงประมาณ 20% แปลกดีที่ Cloudflare ยังสะดุดกับปัญหาง่าย ๆ และเก่าแก่แบบนี้อยู่เรื่อย ๆ (ครั้งนี้ไม่ใช่ครั้งแรก และคงไม่ใช่ครั้งสุดท้าย) ขณะที่ 8.8.8.8 และ 8.8.4.4 ของ Google แทบไม่มีดาวน์ไทม์เลยทั่วโลกมาเกือบ 10 ปี (1 วินาทีก็ไม่มี) (1: เคยมีปัญหาเฉพาะบางภูมิภาค แต่เป็นความผิดของอินเทอร์เน็ตเอง และแม้ตอนที่บริการอื่น ๆ ของ Google มีเหตุขัดข้องร้ายแรง DNS เองก็ยังทำงานตามปกติ)

  • ไม่ใช่แค่ความพร้อมใช้งานเท่านั้น แต่สำหรับ DNS ความเร็วและความเป็นส่วนตัวก็สำคัญด้วย หากเป็นผู้ใช้ในยุโรป ก็อาจเลือกใช้แทนบริษัทสหรัฐฯ (ที่อยู่ภายใต้ CLOUD Act) จาก รายการทางเลือก DNS ในยุโรป
  • สำหรับความเห็นที่ว่าปัญหาวิศวกรรมในสภาพแวดล้อมเครือข่ายที่ใหญ่และซับซ้อนมหาศาลอย่าง Cloudflare ไม่น่าจะแก้ยากได้ขนาดนี้ ต้องอธิบายว่าจริง ๆ แล้วเป็นปัญหาที่มีเพียง 0.001% ของวงการเท่านั้นที่เคยเจอ
  • Cloudflare มีวัฒนธรรมการตอบสนองต่อเหตุการณ์ที่สมเหตุสมผล แต่มีข้อเสียคือแรงจูงใจในการผลักดันมาตรการป้องกันเชิงรุกยังไม่มากพอ
  • ตัวเลข 20% ที่พูดถึงหมายความว่าไคลเอนต์/รีโซลเวอร์บางตัวจะทำเครื่องหมาย DNS เซิร์ฟเวอร์ว่าใช้งานชั่วคราวไม่ได้หลังตอบสนองล้มเหลวหลายครั้ง เพื่อให้ผู้ใช้ไม่ต้องรอ timeout 500 ครั้งทุกคำขอ ในระยะยาว กราฟทราฟฟิก แสดงให้เห็นว่าปริมาณกลับสู่ภาวะปกติ
  • เห็นด้วยว่ามีหลายคนที่ไม่อยากใช้ Google DNS

• น่าตกใจที่ใช้เวลากว่า 5 นาทีในการตรวจจับผลกระทบ ทั้งที่ทราฟฟิกของโปรโตคอลหลักตกลงเหลือ 10% และคงอยู่แบบนั้น แม้จะไม่เคยดูแลระบบขนาดใหญ่มากแบบนี้ แต่ก็คิดว่าน่าจะมีการแจ้งเตือนทันที เลยอยากรู้ว่าผู้เชี่ยวชาญคิดว่านี่สมเหตุสมผลหรือไม่

  • มีความตึงเครียดอยู่เสมอระหว่างความเร็วในการตรวจจับกับอัตราการแจ้งเตือนผิดพลาด ระบบมอนิเตอร์อย่าง Nagios หรือ Icinga มักต้องล้มเหลวติดต่อกัน 3 ครั้งก่อนจึงจะสร้างเหตุการณ์ เพราะความผิดพลาดชั่วคราวเกิดขึ้นบ่อย ถ้ามีอัลертบ่อยเกินไป คนรับผิดชอบจะชินชาและเริ่มตอบสนองแบบ "รอดูอีกหน่อย" แม้ไม่เคยดูแลบริการระดับโลกแบบ Cloudflare โดยตรง แต่การตรวจจับที่เชื่อถือได้ภายใน 8 นาทีถือว่าไม่น่าแปลกใจ
  • ถ้าเป็นยุค NOC (ศูนย์ปฏิบัติการเครือข่าย) แบบเก่า ที่มีกราฟเหล่านี้ติดอยู่บนผนัง ก็คงมีใครสักคนเหลือบมองแล้วพูดว่า "แปลกนะ" ก่อนจะรีบเข้าไปดูทันที
  • คิดว่าตอนเริ่มได้รับผลกระทบ บริการคงยังไม่ได้ล่มทั้งหมด โดยเฉพาะถ้าเป็นจุดเริ่มของการ rollout ทั่วโลก จึงต้องใช้เวลาสักพักกว่าผลกระทบจะวัดได้ชัดเจน
  • ถ้าตั้งให้อัลาร์มดังภายใน 1 นาที สุดท้ายจะกลายเป็นการทดสอบประสิทธิภาพของโครงสร้างแจ้งเตือนเสียมากกว่า ประเด็นจริงคือสามารถเก็บและคำนวณข้อมูลทุก 1 นาทีได้อย่างเสถียรหรือไม่
  • เมื่อบริการรวมเมตริก crash ตัวชี้วัดอาจล่าช้าจนดูเหมือนตก 100% ไปจนกว่าระบบจะ deploy ใหม่ ถ้าแจ้งเตือนใน 1 นาที ก็อาจปลุกคนจำนวนมากตอนตี 2 โดยไม่จำเป็น และเมื่อเกิดซ้ำ ๆ สุดท้ายเกณฑ์แจ้งเตือนก็จะถูกผ่อนให้หลวมลง จึงมักจบที่ประมาณ 5 นาที

• เป็นบทสรุปที่ดี น่าสนใจตรงที่ DoH (DNS ผ่าน HTTPS) ส่วนใหญ่เข้าถึงผ่านโดเมน cloudflare-dns.com (ตั้งค่าเองหรือผ่านเบราว์เซอร์) และเพราะไม่ใช่ IP โดยตรง จึงได้รับผลกระทบจากเหตุขัดข้องน้อยกว่า ฉันโดนผลกระทบเมื่อวาน แต่แม้จะเปิด DoH บนเราเตอร์ไว้ ก็ยังค้นหาอะไรไม่ได้เลย พอเปลี่ยนเป็น 8.8.8.8 ก็หาย

  • อยากรู้ว่า DoH ทำงานอย่างไร เพราะต้องรู้ IP ของ cloudflare-dns.com อยู่ดี และเราเตอร์ก็อาจใช้ 1.1.1.1 อยู่
  • วันนี้กำลังตั้งค่าโดเมนใหม่ แล้วช่วงประมาณ 20 นาทีมีเพียง Firefox บนโน้ตบุ๊กเครื่องหนึ่งเท่านั้นที่เข้าได้ เครื่องมือ Google DNS บอกว่าโดเมนเปิดใช้งานแล้ว และบนเซิร์ฟเวอร์ AWS ก็ SSH ได้ แต่ในเครือข่ายภายในของฉันกลับ query DNS ไม่ได้ ล้างแคชและลองทุกอย่างแล้ว สุดท้ายพบว่าเฉพาะเบราว์เซอร์ Firefox ตัวนั้นถูกตั้งให้ใช้ Cloudflare DoH แยกไว้
  • ฉันไม่เห็นด้วย สาเหตุรากจริง ๆ ถูกซ่อนด้วยคำศัพท์เชิงวิชาการที่กำกวม ทำให้แม้แต่ผู้ดูแลระบบที่มีประสบการณ์ก็สับสน คำว่า "legacy" ไม่ชัดเจน และยิ่งให้ความรู้สึกเป็นนามธรรมกับไม่โปร่งใส ประโยคอย่าง "คอมโพเนนต์ legacy ไม่ได้ใช้วิธี deploy แบบค่อยเป็นค่อยไป และ Cloudflare จะนำวิธีสมัยใหม่ที่รองรับ progressive deployment และ rollback มาใช้" แม้จะพอเข้าใจ แต่ก็ไม่มีความจำเป็นต้องเขียนให้ตีความยากแบบนี้
  • เราเตอร์ Unifi ของฉันดูเหมือนจะใช้ DoH อัตโนมัติ โดยใช้ทั้ง Cloudflare และ Google พร้อมกัน ฉันจึงไม่รู้สึกถึงผลกระทบ อาจเพราะ Cloudflare DoH ยังทำงานอยู่หรือไม่ก็สลับไป Google ทันที
  • โดยรวมเป็นบทสรุปที่ทำได้ดี แต่เนื้อหา timeline ตอนต้นบทความไม่ตรงกับข้อเท็จจริง

• ถ้าใช้ dnsmasq สามารถตั้ง DNS หลายตัวพร้อมกันและใช้ตัวที่ตอบเร็วที่สุดได้ ทำให้แทบไม่รู้สึกถึงปัญหาแม้บริการหนึ่งจะล่ม

  • เมื่อใช้ all-servers โดยไม่มีการตั้งค่า strict-order dnsmasq จะส่งคำขอ retry ไปยังทุกเซิร์ฟเวอร์โดยอัตโนมัติ แต่ถ้าใช้ systemd-resolved มันจะ retry ตามลำดับเท่านั้น จึงสำคัญที่จะสลับลำดับของเซิร์ฟเวอร์จากผู้ให้บริการต่าง ๆ ถ้าใส่ทั้ง IPv4 และ IPv6 ร่วมกันแบบในตัวอย่าง การ failover จะยิ่งเร็วขึ้น IP ที่ระบุของ Quad9 เปิดใช้การกรองเริ่มต้นอยู่ ส่วนอีกสองตัวไม่เปิด ดังนั้นผลการ resolve อาจต่างกัน ส่วนตัวถ้าให้ความสำคัญกับการตรวจสอบความถูกต้องของ DNSSEC (ส่วนขยายความปลอดภัยของโดเมน) ก็ไม่ควรผสมรีโซลเวอร์ที่ตรวจสอบกับที่ไม่ตรวจสอบเข้าด้วยกัน (DNS ในตัวอย่างทั้งหมดรองรับ DNSSEC)
  • ไม่อยากให้ประวัติ DNS ทั้งหมดของตนถูกเปิดเผยกับบริษัทยักษ์ใหญ่ด้านเทคอย่าง Cloudflare หรือ Google และก็ไม่ต้องการ DoH ด้วย เลยถามว่ามีการตั้งค่าที่เป็นส่วนตัวกว่านี้หรือไม่ คิดว่าการใช้รายการ DNS ขนาดเล็กที่เชื่อถือได้กับ dnsmasq น่าจะดี แต่ก็ลังเลว่าการยิงคำขอไปยังผู้ให้บริการหลายรายทุกครั้งจะถือว่าเสียมารยาทหรือไม่ และก็ไม่รู้จะหารายการ DNS ที่เน้นความเป็นส่วนตัวและเสถียรได้จากที่ไหน
  • ผู้ให้บริการ DNS หลายรายมีนโยบายและลำดับความสำคัญต่างกัน ดังนั้นฉันจึงไม่มองว่าสองตัวแทนกันได้ ตรงกันข้ามจะเลือกสักตัวเดียว แล้วใช้ DNS ของ ISP เป็นตัวสำรอง
  • หากใช้ systemd-resolved ก็สามารถได้พฤติกรรมคล้ายกัน เพราะรองรับ DoT และ DNSSEC โดยปริยาย ถ้าต้องการหลีกเลี่ยง DNS แบบรวมศูนย์อย่างสิ้นเชิง ก็สามารถรัน Tor daemon เพื่อเปิด DNS รีโซลเวอร์บนเครือข่ายได้ และใช้หลายรีโซลเวอร์ก็ได้เช่นกัน
  • แม้ไม่ตั้งค่า all-servers dnsmasq ก็ยังแข่งส่งคำขอไปยังแต่ละเซิร์ฟเวอร์เป็นระยะ ๆ อยู่ดี (โดยปกติ retry ทุก 20 วินาที) ดังนั้นแม้จะเป็นเหตุขัดข้องฉับพลัน ก็มักได้รับผลกระทบไม่เกินไม่กี่วินาที

• แม้จะล่มนานประมาณ 1 ชั่วโมง ถ้าคิดเป็นรายเดือนก็เพียง 0.13% และรายปีก็ 0.0114% เลยสงสัยว่า SLO (เป้าหมายระดับบริการ) ที่ Cloudflare ใช้กับบริการนี้คือเท่าไร เจอลิงก์แล้ว แต่เป็นสำหรับบริการแบบเสียเงินเท่านั้น เหตุขัดข้องครั้งนี้ทำให้ความพร้อมใช้งานของเดือนกรกฎาคมตกไปอยู่ในช่วง "< 99.9% but >= 99.0%" ซึ่งในกรณีนี้จะได้รับเงินคืน 10% ของค่าบริการ

  • คิดว่าถ้าต้องการรักษาภาพลักษณ์ของแบรนด์ ก็น่าจะต้องอยู่ที่ 99.9% ต่อปีหรือสูงกว่านั้น

• น่าสนใจที่หลังเหตุการณ์ ทราฟฟิกยังไม่กลับสู่ปกติทั้งหมด ฉันเพิ่งใช้ luci-app-https-dns-proxy ของ OpenWrt ให้ส่งคำขอไปยัง Cloudflare และ Google DNS พร้อมกัน และแทบไม่ได้รับผลกระทบกับ DoH เลย จึงไม่รู้สึกถึงเหตุล่มนี้ (ถ้า DoH ล่มด้วยก็คงสลับไป Google อัตโนมัติ)

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

• น่าแปลกใจที่ทั้ง 1.1.1.1 และ 1.0.0.1 ได้รับผลกระทบจากการเปลี่ยนแปลงเดียวกัน แบบนี้คงต้องใช้ผู้ให้บริการคนละรายไปเลยสำหรับ DNS สำรอง (เช่น 8.8.8.8, 9.9.9.9)

  • จริง ๆ แล้วทั้งสองที่อยู่นั้นมาจากบริการเดียวกัน ไม่เคยถูกโฆษณาว่าเป็นแบ็กอัปที่เป็นอิสระต่อกัน
  • แต่เดิม DNS ถูกออกแบบมาให้ใช้รีโซลเวอร์ที่ใกล้ที่สุด การกระจายใช้หลายผู้ให้บริการ หลาย backbone หลายภูมิภาคอย่างเหมาะสม (และถ้าเป็นไปได้ก็ไม่ใช้ที่อยู่ anycast) เป็นเรื่องดี แต่ในกรณีนี้คุณสมบัติการทำงานของ DNS เองก็อาจทำให้เจอปัญหาที่ไม่คาดคิดได้
  • จริง ๆ ก็เป็นแบบนั้นมาโดยตลอด
  • ฉันตั้งค่า OpenDNS, Quad9 และ Cloudflare ผสมกันไว้บน Pi-hole สองตัวอยู่แล้ว อุปกรณ์ส่วนใหญ่ของฉันก็ตั้งให้ใช้ Pi-hole ทั้งสองตัวเป็น DNS คนละตัว
  • จริง ๆ แล้วแนวคิดเรื่อง "DNS สำรอง" เองก็แทบไม่มีความหมาย เพราะไคลเอนต์ส่วนใหญ่มักสุ่มเลือกที่อยู่หนึ่งอันมาใช้ และไม่ได้สลับไปอีกตัวโดยอัตโนมัติเมื่อฝั่งหนึ่งล่ม เป็นสถานการณ์ที่การทำงานไม่เป็นไปตามที่หลายคนคาดหวัง

• โทโพโลยีภายในของ Cloudflare กำลังค่อย ๆ พัฒนาไปในรูปแบบที่ระบบ "legacy" และ "strategic" ทำงานซิงก์กัน เป็นบทความที่อธิบายสถานะปัจจุบันได้ชัดเจนจนทั้งคนสายเทคนิคและคนทั่วไปเข้าใจได้ ดูเหมือนจะถ่ายทอดกระบวนการ migration ให้น่าสนใจขึ้นด้วย ข้อความขอโทษต่อความไม่สะดวกจากเหตุการณ์ และยืนยันว่าจะปรับปรุงกับป้องกันไม่ให้เกิดซ้ำ สร้างความประทับใจ ประเมินท่าทีของบริษัทในเรื่องนี้ในแง่บวก

  • "legacy" เป็นคำที่วิศวกรมักใช้ ส่วน "strategic" เป็นคำที่ฝ่ายการตลาดหรือผู้บริหารที่ไม่ใช่สายเทคนิคมักใช้ การเอามาปนกันจึงอาจทำให้ทั้งสองฝ่ายสับสนและหงุดหงิดมากกว่าเดิม

• น่าแปลกใจที่แม้จะมีวิศวกรหลายคนตรวจทานการรีแบรนด์แล้ว ก็ยังไม่มีใครเห็นความผิดพลาดที่เพิ่ม 1.1.1.0/24 เข้าไปในรายการ rerouting เลย สงสัยว่าต้องเป็นความผิดพลาดของมนุษย์แบบไหน หรืออาจถึงขั้นเจตนาร้าย จึงอยากให้มีข้อยกเว้นแบบ hardcode ใน DLS (Domain List Service) เพื่อกันไม่ให้กำหนด 1.1.1.1/32 และ 1.0.0.1/32 เป็นตำแหน่งเดียว

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