SCT

กำลังเตรียมประสบการณ์ดิจิทัล

กุญแจรากของ DNS เปลี่ยน 11 ตุลาคม 2569: องค์กรที่ตั้ง DNS resolver เองต้องตรวจอะไร และทดสอบด้วยคำสั่งเดียวว่าพร้อมหรือยัง

วันที่ 11 ตุลาคม 2569 กุญแจที่ใช้ลงลายเซ็นรากของระบบ DNS จะเปลี่ยนจากชุดเดิม KSK-2017 เป็นชุดใหม่ KSK-2024 คนทั่วไปและเจ้าของเว็บส่วนใหญ่ไม่ต้องทำอะไร แต่องค์กรที่ตั้งเครื่อง DNS resolver ของตัวเองและเปิดตรวจ DNSSEC ไว้ ถ้าเครื่องยังไม่รู้จักกุญแจใหม่ ผู้ใช้ในองค์กรอาจเปิดเว็บแทบไม่ได้เลยตั้งแต่วันนั้น บทความนี้อธิบายว่ากุญแจนี้ทำหน้าที่อะไร ใครต้องตรวจ และวิธีทดสอบที่ใช้เวลาไม่ถึงนาที

วันที่ 11 ตุลาคม 2569 กุญแจที่ใช้ลงลายเซ็นรากของระบบ DNS จะเปลี่ยนจากชุดเดิม KSK-2017 เป็นชุดใหม่ KSK-2024 คนทั่วไปและเจ้าของเว็บส่วนใหญ่ไม่ต้องทำอะไร แต่องค์กรที่ตั้งเครื่อง DNS resolver ของตัวเองและเปิดตรวจ DNSSEC ไว้ ถ้าเครื่องยังไม่รู้จักกุญแจใหม่ ผู้ใช้ในองค์กรอาจเปิดเว็บแทบไม่ได้เลยตั้งแต่วันนั้น บทความนี้อธิบายว่ากุญแจนี้ทำหน้าที่อะไร ใครต้องตรวจ และวิธีทดสอบที่ใช้เวลาไม่ถึงนาที

DNSSEC และกุญแจรากคืออะไร

DNS คือระบบที่แปลงชื่อเว็บเป็นหมายเลข IP ส่วน DNSSEC เป็นส่วนเสริมที่แนบลายเซ็นดิจิทัลไปกับคำตอบ เครื่องที่ถามจึงตรวจได้ว่าคำตอบไม่ถูกปลอมระหว่างทาง ลายเซ็นต่อกันเป็นสายจากบนลงล่าง ราก (root) รับรองโดเมนระดับบนสุดอย่าง .com หรือ .th ผ่านระเบียน DS ที่เก็บลายนิ้วมือของกุญแจโดเมนลูก แล้วโดเมนระดับบนสุดก็รับรองโดเมนถัดลงไปด้วยวิธีเดียวกัน

รากไม่มีใครอยู่เหนือขึ้นไปให้รับรอง resolver ที่ตรวจ DNSSEC จึงต้องเก็บกุญแจสาธารณะของรากไว้ล่วงหน้า เรียกว่า trust anchor กุญแจที่ลงลายเซ็นชุดกุญแจของรากเรียกว่า KSK (Key Signing Key) ส่วนกุญแจที่ลงลายเซ็นระเบียนอื่นของรากเรียกว่า ZSK (Zone Signing Key) สิ่งที่เปลี่ยนในรอบนี้คือ KSK ซึ่งเป็นจุดตั้งต้นของการตรวจทั้งหมด

อะไรเปลี่ยน และเมื่อไร

ลำดับเหตุการณ์ของการเปลี่ยนกุญแจรากรอบนี้
เหตุการณ์เมื่อไรความหมาย
เผยแพร่กุญแจใหม่ KSK-2024 (key tag 38696) ในโซนราก11 มกราคม 2568resolver ที่อัปเดตอัตโนมัติเริ่มเรียนรู้กุญแจใหม่
เปลี่ยนไปลงลายเซ็นด้วย KSK-2024 แทน KSK-2017 (key tag 20326)11 ตุลาคม 2569resolver ที่ไม่รู้จักกุญแจใหม่จะตรวจลายเซ็นไม่ผ่าน
เพิกถอนและถอด KSK-2017 ออกจากโซนรากปี 2570ปิดการเปลี่ยนกุญแจรอบนี้

ทั้งสองกุญแจใช้อัลกอริทึม RSA/SHA-256 เหมือนกัน รอบนี้จึงเปลี่ยนเฉพาะตัวกุญแจ ไม่ได้เปลี่ยนวิธีคำนวณ เหตุผลที่ต้องเปลี่ยนคือไม่ควรใช้กุญแจลับชุดเดียวนานเกินไป และต้องซ้อมกระบวนการแจกกุญแจใหม่ให้ทั้งอินเทอร์เน็ตเป็นระยะ IANA ตั้งเป้าเปลี่ยนราวทุกสามปี แต่รอบนี้ห่างจากรอบปี 2561 นานกว่านั้น เพราะช่วงการระบาดของโควิดและการอัปเกรดฮาร์ดแวร์ที่เก็บกุญแจ

ใครต้องทำอะไร

  • ผู้ใช้ทั่วไปและเจ้าของเว็บส่วนใหญ่ ไม่ต้องทำอะไร การเปลี่ยนนี้กระทบเครื่องที่ตรวจคำตอบ DNS ไม่ใช่ตัวเว็บไซต์
  • ผู้ใช้ DNS สาธารณะอย่าง 1.1.1.1 Cloudflare ระบุว่าใส่กุญแจใหม่ไว้ในระบบตั้งแต่กรกฎาคม 2567
  • องค์กร มหาวิทยาลัย และผู้ให้บริการอินเทอร์เน็ตที่ตั้ง resolver เอง และเปิดตรวจ DNSSEC ต้องยืนยันว่าเครื่องเชื่อถือ KSK-2024 แล้ว
  • เครื่องที่เพิ่งติดตั้งใหม่หรือย้ายเครื่อง ในรอบปี 2561 ปัญหาส่วนหนึ่งมาจากเครื่องที่อัปเกรดซอฟต์แวร์หรือย้ายไปเครื่องใหม่แล้วกุญแจที่เรียนรู้ไว้หายไป

ทดสอบว่า resolver พร้อมหรือยัง

วิธีที่ง่ายที่สุดคือเปิดหน้า dnstest.dev/ksk-2024 จากเครื่องที่ใช้ resolver ตัวที่ต้องการตรวจ อีกวิธีคือใช้คำสั่ง dig ถามชื่อทดสอบสองชื่อ ที่ออกแบบตามมาตรฐาน RFC 8509 (trust anchor sentinel) ซึ่งทำให้ resolver บอกโดยอ้อมได้ว่ากำลังเชื่อถือกุญแจใดอยู่

อ่านผลการทดสอบด้วยคำสั่ง dig (แทน RESOLVER ด้วย IP ของเครื่องที่ต้องการตรวจ)
คำสั่งถ้าเชื่อถือ KSK-2024 แล้วถ้ายังไม่เชื่อถือ
dig @RESOLVER root-key-sentinel-is-ta-38696.dnstest.dev. Aได้คำตอบตามปกติSERVFAIL
dig @RESOLVER root-key-sentinel-not-ta-38696.dnstest.dev. ASERVFAILได้คำตอบตามปกติ

ถ้าทั้งสองคำสั่งได้คำตอบปกติ แปลว่า resolver ตัวนั้นอาจไม่ได้ตรวจ DNSSEC หรือไม่รองรับวิธีทดสอบนี้ ให้ตรวจไฟล์ trust anchor ของซอฟต์แวร์โดยตรงแทน ถ้าพบว่ายังไม่เชื่อถือกุญแจใหม่ ให้ทำตามคู่มือของซอฟต์แวร์ที่ใช้และแนวทางของ ICANN เพื่อเพิ่ม KSK-2024 หรืออัปเดตซอฟต์แวร์เป็นรุ่นที่มีกุญแจใหม่ฝังมาแล้ว อย่ารอให้เครื่องเรียนรู้เอง เพราะกลไกอัปเดตอัตโนมัติตาม RFC 5011 ต้องเห็นกุญแจใหม่ต่อเนื่องอย่างน้อย 30 วันก่อนยอมรับ ซึ่งไม่ทันวันที่ 11 ตุลาคมแล้ว

ถ้าไม่พร้อม จะเกิดอะไรขึ้น

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

เครือข่ายองค์กรในไทยหลายแห่งตั้ง DNS ภายในไว้บนเครื่องที่ใช้งานมาหลายปี และมักไม่มีใครดูจนกว่าจะเกิดปัญหา ทีมงาน Smart Cyber Tech ออกแบบและดูแลระบบคลาวด์และเครือข่ายขององค์กร ช่วยตรวจ resolver เตรียมแผนรับมือ และวางการเฝ้าระวังให้เห็นปัญหาก่อนผู้ใช้ ปรึกษาได้ที่ แบบฟอร์มติดต่อ

สรุปสาระสำคัญ

  • DNSSEC และกุญแจรากคืออะไร
  • อะไรเปลี่ยน และเมื่อไร
  • ใครต้องทำอะไร
แหล่งอ้างอิงเรียบเรียงจาก The Cloudflare Blog — อ่านบทความต้นฉบับ
ภาพปก: The Cloudflare Blog · ลิขสิทธิ์ภาพเป็นของเจ้าของต้นฉบับ ใช้ประกอบการรายงานพร้อมอ้างอิงแหล่งที่มา
มีคำถามเพิ่มเติมเกี่ยวกับบทความนี้? เขียนหาเราได้ที่ info@smart-cyber-tech.com
บริการที่เกี่ยวข้องจากทีมงาน Smart Cyber Tech

บทความอื่นที่เกี่ยวข้อง

บทความที่เกี่ยวข้อง

เตรียมอินเทอร์เน็ตให้พร้อมรับคอมพิวเตอร์ควอนตัม: ทำไม 1.1.1.1 ต้องรองรับลายเซ็น DNSSEC ขนาด 2,420 ไบต์ เทคโนโลยีใหม่

เตรียมอินเทอร์เน็ตให้พร้อมรับคอมพิวเตอร์ควอนตัม: ทำไม 1.1.1.1 ต้องรองรับลายเซ็น DNSSEC ขนาด 2,420 ไบต์

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

อ่านบทความ
ลดหน่วยความจำได้ 100 เทระไบต์ด้วยการจัดโครงสร้างข้อมูลใหม่: บทเรียนจากแคช DNS ระดับโลก คลาวด์

ลดหน่วยความจำได้ 100 เทระไบต์ด้วยการจัดโครงสร้างข้อมูลใหม่: บทเรียนจากแคช DNS ระดับโลก

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

อ่านบทความ
เว็บทั่วโลกเร็วแค่ไหนจริง ๆ: Cloudflare เปิดข้อมูลความเร็วจากผู้ใช้จริงชุด BEACON ให้ใครก็วิเคราะห์ได้ และสิ่งที่ตัวเลขบอกทีมทำเว็บ เว็บ

เว็บทั่วโลกเร็วแค่ไหนจริง ๆ: Cloudflare เปิดข้อมูลความเร็วจากผู้ใช้จริงชุด BEACON ให้ใครก็วิเคราะห์ได้ และสิ่งที่ตัวเลขบอกทีมทำเว็บ

ทีมทำเว็บส่วนใหญ่วัดความเร็วจากเครื่องของตัวเองหรือจากเครื่องมือทดสอบ ซึ่งไม่เหมือนสิ่งที่ผู้ใช้จริงเจอบนมือถือและเครือข่ายที่หลากหลาย Cloudflare เปิดข้อมูลชุด BEACON ซึ่งรวบรวมการวัดความเร็วจากผู้ใช้จริงนับพันล้านครั้งต่อวันของเว็บไซต์ 10,000 อันดับแรกบนเครือข่ายของตน ให้ทุกคนวิเคราะห์ได้ผ่าน Google BigQuery ข้อมูลชุดแรกบอกว่าหน้าแรกที่ผู้ใช้เข้ามาถึงช้ากว่าการเปลี่ยนหน้าภายในเว็บหลายเท่า และเบราว์เซอร์บน iPhone ช้ากว่าเบราว์เซอร์ตระกูล Chrome ในหลายสิบประเทศ

อ่านบทความ

ติดต่อเพื่อขอรับคำปรึกษาจากทีมงาน

ตั้งแต่ประเมินระบบปัจจุบัน วางแผน จนถึงลงมือพัฒนา — คุยกับเราได้โดยไม่มีค่าใช้จ่าย

ปรึกษาทีมของเรา