Cloudflare ประกาศเมื่อวันที่ 10 กันยายน 2026 ว่า DNS resolver สาธารณะ 1.1.1.1 ตรวจสอบลายเซ็น DNSSEC ที่ใช้อัลกอริทึมทนต่อคอมพิวเตอร์ควอนตัมได้แล้ว ฟังดูไกลตัว แต่นี่คือการเตรียมระบบที่ทำหน้าที่เหมือนสมุดโทรศัพท์ของอินเทอร์เน็ตให้ยังเชื่อถือได้ในวันที่คอมพิวเตอร์ควอนตัมถอดกุญแจแบบเดิมได้ บทความนี้อธิบายว่าทำไมลายเซ็นใหม่ที่ใหญ่กว่าเดิมหลายสิบเท่าจึงเป็นโจทย์วิศวกรรมจริง และองค์กรไทยควรเริ่มเตรียมอะไร
DNS และ DNSSEC ทำหน้าที่อะไร
ทุกครั้งที่พิมพ์ชื่อเว็บไซต์ อุปกรณ์ต้องถาม DNS ก่อนว่าชื่อนั้นอยู่ที่หมายเลข IP ใด ถ้าผู้ไม่หวังดีปลอมคำตอบนี้ได้ ผู้ใช้จะถูกพาไปยังเซิร์ฟเวอร์ปลอมโดยไม่รู้ตัว DNSSEC คือส่วนขยายที่ให้เจ้าของโดเมนเซ็นรับรองข้อมูล DNS ด้วยลายเซ็นดิจิทัล resolver อย่าง 1.1.1.1 จึงตรวจได้ว่าคำตอบมาจากเจ้าของโดเมนจริงและไม่ถูกแก้ระหว่างทาง
ลายเซ็นที่ใช้กันแพร่หลายในวันนี้คือ RSA และ ECDSA ซึ่งความปลอดภัยตั้งอยู่บนโจทย์คณิตศาสตร์ที่คอมพิวเตอร์ควอนตัมขนาดใหญ่พอจะแก้ได้ในอนาคต Cloudflare ระบุว่ากำลังเตรียมรับความเป็นไปได้ที่คอมพิวเตอร์ควอนตัมระดับนั้นอาจถูกสร้างขึ้นได้ราวปี 2030 และตั้งเป้าให้บริการของตัวเองปลอดภัยต่อควอนตัมเต็มรูปแบบภายในปี 2029
ภัยต่อ DNSSEC ต่างจากภัยต่อการเข้ารหัสทั่วไป
ข้อมูลที่เข้ารหัสไว้อาจถูกดักเก็บวันนี้แล้วถอดรหัสภายหลังเมื่อมีคอมพิวเตอร์ควอนตัม ภัยแบบนี้เรียกว่า harvest now, decrypt later แต่ DNSSEC ไม่ได้ปกปิดข้อมูล มันยืนยันความถูกต้องเท่านั้น จึงไม่เสี่ยงต่อภัยแบบนี้โดยตรง ความเสี่ยงของ DNSSEC คือในอนาคตผู้โจมตีที่กู้กุญแจส่วนตัวได้ด้วยคอมพิวเตอร์ควอนตัมจะปลอมลายเซ็นที่ resolver ยอมรับได้
คำถามจึงตามมาว่าทำไมต้องเริ่มตอนนี้ คำตอบคือการเปลี่ยนอัลกอริทึมของ DNSSEC ต้องไล่ไปจนถึงชั้นบนสุดของลำดับชั้น DNS ซึ่งเป็นจุดที่กุญแจรั่วแล้วเสียหายมากที่สุด และต้องประสานกันระหว่างเซิร์ฟเวอร์ DNS ของเจ้าของโดเมน ผู้ดูแลโดเมนระดับบน ผู้รับจดทะเบียนโดเมน และ resolver ทั่วโลก งานระดับนี้ใช้เวลาหลายปี จึงต้องมีคนเริ่มลองกับทราฟฟิกจริงก่อน
ML-DSA-44: ลายเซ็นยุคหลังควอนตัมที่ใหญ่กว่าเดิมหลายสิบเท่า
อัลกอริทึมที่ 1.1.1.1 รองรับคือ ML-DSA-44 ซึ่งพัฒนามาจาก CRYSTALS-Dilithium และได้รับการกำหนดเป็นมาตรฐานโดย NIST ในเดือนสิงหาคม 2024 อัลกอริทึมนี้อาศัยโจทย์คณิตศาสตร์แบบแลตทิซ (lattice) ที่ยังไม่มีวิธีให้คอมพิวเตอร์ควอนตัมแก้ได้อย่างมีประสิทธิภาพ แต่ราคาที่ต้องจ่ายคือขนาด
ขนาดลายเซ็นดิจิทัลที่ใช้ใน DNSSEC เทียบกัน (ตัวเลขจากบทความของ Cloudflare) อัลกอริทึม พื้นฐานทางคณิตศาสตร์ ขนาดลายเซ็น ทนต่อคอมพิวเตอร์ควอนตัม RSA-2048 (SHA-256) การแยกตัวประกอบจำนวนเฉพาะ 256 ไบต์ ไม่ทน ECDSA P-256 เส้นโค้งวงรี 64 ไบต์ ไม่ทน ML-DSA-44 แลตทิซ (lattice) 2,420 ไบต์ (กุญแจสาธารณะ 1,312 ไบต์) ทน
เมื่อเทียบกัน ลายเซ็น ML-DSA-44 ใหญ่กว่า ECDSA P-256 ราว 38 เท่า และตัวเลข 2,420 ไบต์ในชื่อบทความของ Cloudflare ก็คือขนาดของลายเซ็นหนึ่งชุดนี้เอง ยังไม่นับข้อมูล DNS ที่ถูกเซ็นกำกับ
ปัญหาจริงคือขนาดแพ็กเก็ต DNS
DNS ส่วนใหญ่ส่งผ่าน UDP ซึ่งเร็วแต่ไม่เหมาะกับข้อความขนาดใหญ่ แนวปฏิบัติปัจจุบันจำกัดขนาดคำตอบผ่าน UDP ไว้ราว 1,232 ไบต์ เพื่อไม่ให้แพ็กเก็ตถูกแบ่งเป็นชิ้น (fragmentation) ซึ่งมักถูกอุปกรณ์เครือข่ายทิ้งกลางทาง ลายเซ็น ML-DSA-44 เพียงชุดเดียวจึงเกินขีดจำกัดนี้ตั้งแต่ยังไม่ใส่ข้อมูลอะไร และคำตอบประเภท DNSKEY ที่ต้องมีทั้งกุญแจสาธารณะและลายเซ็นคือกรณีที่หนักที่สุด
วิธีของ 1.1.1.1 คือไม่ส่ง UDP แบบแบ่งชิ้นเลย เมื่อคำตอบใหญ่เกินจะส่งคำตอบที่ตั้งบิต TC (truncated) กลับไป เพื่อบอกให้ไคลเอนต์ถามซ้ำผ่าน TCP หรือช่องทางอื่นอย่าง DNS over TLS และ DNS over HTTPS กลไกนี้ไม่ใช่ของใหม่ แต่ลายเซ็นยุคหลังควอนตัมจะบังคับให้ถูกใช้บ่อยขึ้นมาก ขณะที่ Cloudflare ระบุว่าวันนี้คำถามที่ส่งมายัง 1.1.1.1 ราว 85 เปอร์เซ็นต์ยังมาทาง UDP
กับดักที่ยังต้องแก้: การย้อนกลับไปใช้อัลกอริทึมเดิม
ในช่วงเปลี่ยนผ่าน โดเมนต้องเซ็นทั้งด้วยอัลกอริทึมเดิมและอัลกอริทึมใหม่ไปอีกหลายปี เพื่อให้ resolver รุ่นเก่ายังทำงานได้ แต่มาตรฐาน RFC 6840 อนุญาตให้ validator ยอมรับคำตอบเมื่อพบเส้นทางลายเซ็นที่ถูกต้องเพียงเส้นทางเดียว หมายความว่าถ้าวันหนึ่ง ECDSA ถูกทำลายได้ ผู้โจมตีอาจปลอมคำตอบที่มีเฉพาะลายเซ็นแบบเดิมแล้วยังผ่านการตรวจ การมีลายเซ็นยุคใหม่เพิ่มเข้าไปจึงยังไม่ได้ปกป้องอัตโนมัติ ระบบนิเวศ DNS ต้องหาทางกันการย้อนกลับแบบนี้ให้ได้ก่อนจะนับว่าปลอดภัยจริง
องค์กรไทยควรเริ่มเตรียมอะไร
ยังไม่มีอะไรที่เจ้าของโดเมนทั่วไปต้องเปลี่ยนในทันที แต่มีงานพื้นฐานที่ควรทำตอนนี้ ข้อแรกคือตรวจว่าไฟร์วอลล์ขององค์กรไม่ได้บล็อก DNS ผ่าน TCP พอร์ต 53 เพราะเมื่อคำตอบใหญ่ขึ้น การถามซ้ำผ่าน TCP จะกลายเป็นเส้นทางปกติแทนที่จะเป็นกรณีพิเศษ ข้อสองคือทำบัญชีว่าระบบใดบ้างที่ใช้การเข้ารหัสแบบ RSA และ ECDSA ทั้งใบรับรอง TLS, VPN, การเซ็นโค้ด และ DNSSEC ข้อสามคือเลือกผู้ให้บริการ DNS และ CDN ที่มีแผนรองรับยุคหลังควอนตัมชัดเจน
หลักคิดที่สำคัญกว่าอัลกอริทึมใดอัลกอริทึมหนึ่งคือความยืดหยุ่นในการเปลี่ยนอัลกอริทึม (crypto-agility) ระบบที่ฝังอัลกอริทึมไว้ในโค้ดหลายจุดจะเปลี่ยนได้ช้าและเสี่ยงพลาด ขณะที่ระบบที่แยกส่วนนี้ออกมาเป็นการตั้งค่าจะปรับตัวได้เร็วกว่ามาก ทีมงาน Smart Cyber Tech ให้บริการตรวจประเมินความปลอดภัยของระบบ รวมถึงสำรวจการใช้การเข้ารหัสในระบบเดิมเพื่อวางแผนรับมือยุคหลังควอนตัม ปรึกษาได้ที่ แบบฟอร์มติดต่อ
สรุปสาระสำคัญ DNS และ DNSSEC ทำหน้าที่อะไร ภัยต่อ DNSSEC ต่างจากภัยต่อการเข้ารหัสทั่วไป ML-DSA-44: ลายเซ็นยุคหลังควอนตัมที่ใหญ่กว่าเดิมหลายสิบเท่า แหล่งอ้างอิง เรียบเรียงจาก Cloudflare Blog — 1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it —
อ่านบทความต้นฉบับ ภาพปก: Cloudflare Blog · ลิขสิทธิ์ภาพเป็นของเจ้าของต้นฉบับ ใช้ประกอบการรายงานพร้อมอ้างอิงแหล่งที่มา
มีคำถามเพิ่มเติมเกี่ยวกับบทความนี้? เขียนหาเราได้ที่
info@smart-cyber-tech.com บริการที่เกี่ยวข้องจากทีมงาน Smart Cyber Tech แบ่งปันบทความนี้:
คัดลอกลิงก์ ปรึกษาทีมของเรา
