ข้ามไปยังเนื้อหา
อาคารศูนย์ข้อมูลของ AWS ตอนพระอาทิตย์ตก ภาพประกอบข่าว Route 53 record set protection
Cloud

Route 53 record set protection ล็อก DNS record สำคัญ กันแก้พลาดในโซนเดียว

อาคารศูนย์ข้อมูลของ AWS ภาพประกอบ ไม่ใช่ภาพจากประกาศ ภาพ: Amazon

Route 53 record set protection ให้ล็อก record ตามชื่อและประเภทในโซนโดยตรง กันการแก้หรือลบโดยไม่ตั้งใจ ไม่ต้องเขียนเงื่อนไขในนโยบาย IAM ของทุกบัญชี

โดย กองบรรณาธิการ THAI DATA อ่าน 4 นาที

แชร์FacebookXLINELinkedIn

สรุปประเด็นสำคัญ

  • AWS ประกาศเมื่อ 12 พฤศจิกายน 2026 ว่า Amazon Route 53 รองรับ record set protection ป้องกันการเปลี่ยน DNS record สำคัญ เช่น record ที่ apex ของโซน, MX และ endpoint ของระบบจริง
  • ก่อนหน้านี้ต้องเขียนเงื่อนไขระดับ record ลงในนโยบาย IAM ของทุกผู้ใช้และทุกบทบาทที่แก้โซนได้ และเมื่อถูกบล็อกผู้แก้ไม่รู้ว่า record ถูกป้องกันหรือเพราะอะไร
  • ตอนนี้ตั้งการป้องกันตามชื่อและประเภทใน hosted zone ได้เลย 1 การป้องกันครอบคลุมทุก record ชื่อและประเภทเดียวกัน รวมถึง record ที่ใช้ set identifier ต่างกัน เช่น weighted และ latency
  • สร้างการป้องกันล่วงหน้าก่อนมี record ได้ เพื่อกันการสร้าง record ชื่อนั้น ใส่หมายเหตุได้ สูงสุด 256 ตัวอักษร ผ่านคอนโซล AWS CLI หรือ SDK
  • ควบคุมว่าใครปลดการป้องกันได้ด้วยสิทธิ์ DeleteResourceRecordSetProtections ใน IAM ใช้ได้ในทุก AWS commercial Region ที่มี public และ private hosted zone

Amazon Web Services ประกาศเมื่อ 12 พฤศจิกายน 2026 ว่า Amazon Route 53 รองรับ Route 53 record set protection ให้ผู้ดูแล DNS ล็อก record สำคัญใน hosted zone ได้ตรง ๆ เช่น record ที่ apex ของโซน MX และ endpoint ของระบบจริง การแก้ record ที่ถูกป้องกันจะถูกบล็อกจนกว่าผู้มีสิทธิ์จะปลดการป้องกันออก

หน้าประกาศ AWS What's New เรื่อง Route 53 record set protection ลงวันที่ 12 พฤศจิกายน 2026
หน้าประกาศ AWS What's New เรื่อง Route 53 record set protection ภาพ: Amazon Web Services (ภาพหน้าจอ)

Route 53 record set protection ต่างจากเดิมอย่างไร

AWS อธิบายว่าก่อนหน้านี้ ผู้ที่อยากล็อก record เฉพาะจุด ต้องเขียนเงื่อนไขระดับ record ลงในนโยบาย IAM ของทุกผู้ใช้และบทบาทที่แก้ hosted zone ได้ และเมื่อนโยบายเหล่านั้นบล็อกการแก้ ผู้แก้ไม่ได้รับสัญญาณว่า record ถูกป้องกันหรือเพราะอะไร

Route 53 record set protection ย้ายการป้องกันมาอยู่ใน hosted zone เอง ผู้ดูแลระบุชื่อและประเภทของ record แล้วระบบบล็อกการเปลี่ยนแปลงทุกทางที่ไม่ได้ปลดการป้องกันก่อน

วิธีตั้งและขอบเขตของการป้องกัน

ตามประกาศของ AWS

  • ป้องกันตามชื่อและประเภท: การป้องกัน 1 รายการครอบคลุมทุก record ชื่อและประเภทนั้น รวมถึง record ที่ใช้ set identifier ต่างกัน ทั้ง weighted, latency และนโยบายเส้นทางอื่น
  • ป้องกันล่วงหน้าได้: สร้างการป้องกันก่อนที่ record จะมีอยู่ เพื่อกันไม่ให้ใครสร้าง record ชื่อและประเภทนั้นขึ้นมา
  • ใส่หมายเหตุได้: แต่ละการป้องกันมีช่องหมายเหตุสูงสุด 256 ตัวอักษร ไว้บอกเหตุผลที่ล็อก
  • จัดการได้ 3 ทาง: คอนโซล Route 53, AWS CLI และ AWS SDK ผ่าน API CreateResourceRecordSetProtections, DeleteResourceRecordSetProtections และ ListResourceRecordSetProtections
  • คุมสิทธิ์ปลดล็อก: จำกัดสิทธิ์ DeleteResourceRecordSetProtections ในนโยบาย IAM เพื่อกำหนดว่าใครปลดการป้องกันได้

ฟีเจอร์ใช้ได้ในทุก AWS commercial Region ที่มี public และ private hosted zone

อาคารศูนย์ข้อมูลของ AWS หลังรั้วเหล็กริมถนนที่ Ashburn รัฐเวอร์จิเนีย ภาพประกอบเรื่อง Route 53
อาคารศูนย์ข้อมูลของ AWS หลังรั้วเหล็กริมถนนที่ Ashburn ภาพประกอบ ภาพ: Vahurzpu / Wikimedia Commons (CC BY-SA 4.0)

ตัวอย่างที่ Route 53 record set protection ช่วยได้

สมมุติบริษัทมีโซน DNS ของโดเมนหลัก ที่ทั้งทีมเว็บ ทีมอีเมล และผู้รับเหมาเข้าไปแก้ได้ MX record ที่ชี้ไปยังระบบอีเมล และ record ของเว็บหลัก เป็นสองรายการที่ถ้าแก้ผิดแล้วอีเมลหรือเว็บหยุดทันที ด้วย Route 53 record set protection ผู้ดูแลล็อกสองรายการนี้ไว้พร้อมหมายเหตุ เช่น "อย่าแก้ก่อนผ่านทีมโครงสร้างพื้นฐาน" คนอื่นยังเพิ่มหรือแก้ record อื่นในโซนได้ตามปกติ

วิศวกรดาต้าเซ็นเตอร์ AWS แก้ปัญหากับเซิร์ฟเวอร์ด้วยแล็ปท็อป ภาพประกอบเรื่อง Route 53 record set protection
วิศวกรดาต้าเซ็นเตอร์ AWS แก้ปัญหากับเซิร์ฟเวอร์ด้วยแล็ปท็อป ภาพประกอบ ภาพ: Amazon

เงื่อนไขในคู่มือ Route 53 ที่ต้องรู้ก่อนใช้

Route 53 Developer Guide หัวข้อ Protecting records from changes ระบุรายละเอียดที่ประกาศฉบับสั้นไม่ได้เขียน

  • ใช้กับทุกผู้ใช้: Route 53 record set protection มีผลกับทุกผู้ใช้และบทบาท แม้แต่ผู้ที่มีสิทธิ์ Route 53 เต็ม การจะแก้ record ที่ถูกล็อกต้องลบการป้องกันก่อน
  • ปฏิเสธทั้งคำขอ: ถ้าคำขอ ChangeResourceRecordSets มีรายการใดแตะ record ที่ป้องกัน ไม่ว่า CREATE, DELETE หรือ UPSERT Route 53 ปฏิเสธทั้งคำขอและไม่ทำอะไรเลย ส่วน UPSERT ที่ค่าเหมือนเดิมทุกอย่างผ่านได้ เพราะไม่ได้เปลี่ยนอะไร
  • แก้หมายเหตุไม่ได้: การป้องกันอัปเดตไม่ได้ ถ้าจะเปลี่ยนหมายเหตุ ต้องลบแล้วสร้างใหม่ หมายเหตุจะแสดงในข้อความผิดพลาดเมื่อ Route 53 ปฏิเสธการแก้ เหมาะกับการบอกเหตุผลและชื่อคนที่ต้องติดต่อ
  • ลบ hosted zone ไม่ได้: โซนที่ยังมี Route 53 record set protectionการป้องกันอยู่ลบไม่ได้ ต้องลบการป้องกันก่อน
  • ป้องกันได้ทุกประเภท: รวมถึง NS และ SOA ที่ apex แต่การป้องกันกัน "คำขอของผู้ใช้" เท่านั้น ไม่ได้กัน Route 53 ที่ปรับ record สองชนิดนี้เองตามการจัดการโซน
  • ไม่เปลี่ยนการตอบ DNS: Route 53 record set protection ควบคุมเฉพาะการแก้ record ไม่กระทบวิธีที่ Route 53 ตอบคำถาม DNS
  • เครื่องมืออื่นก็ถูกบล็อก: ถ้า AWS CloudFormation, AWS CLI หรือ SDK แก้ record ที่ล็อก คำขอล้มเหลวด้วยข้อผิดพลาด InvalidChangeBatch เหมือนกัน
  • มีบันทึกตรวจสอบ: CloudTrail บันทึกคำขอสร้าง ลบ และดูรายการการป้องกัน
  • ใช้ได้กับโซนสาธารณะและส่วนตัว: hosted zone แบบ public และ private ต่างรองรับ

คู่มือเตือนว่าการป้องกัน "แข็งแรงเท่านโยบาย IAM ที่คุมสิทธิ์ลบ" เท่านั้น ใครมี route53:DeleteResourceRecordSetProtections บนโซนนั้นก็ปลดการป้องกันทุกรายการได้

ภาพมุมสูงศูนย์ข้อมูล AWS ในโซน us-west-2 ที่รัฐออริกอน ภาพประกอบเรื่อง Route 53
ภาพมุมสูงศูนย์ข้อมูล AWS ในโซน us-west-2 ที่รัฐออริกอน ภาพประกอบ ภาพ: Tedder / Wikimedia Commons (CC BY-SA 4.0)

ผลต่อองค์กรไทย

เรื่อง Route 53 record set protection สำคัญเพราะ DNS เป็นจุดที่ผิดพลาดครั้งเดียวทำให้เว็บ อีเมล และระบบภายในหยุดพร้อมกัน องค์กรไทยที่ใช้ Route 53 ดูแลโดเมนหลักควรเริ่มจากรายการ record ที่ห้ามพลาด

  • ทำรายการ record สำคัญของแต่ละโซน เช่น apex, MX และ endpoint ของระบบจริง
  • ตั้ง Route 53 record set protection พร้อมหมายเหตุบอกเหตุผล และเจ้าของ record
  • จำกัดสิทธิ์ DeleteResourceRecordSetProtections ให้เหลือผู้ดูแลหลักไม่กี่คน
  • ตรวจว่าเครื่องมืออัตโนมัติ เช่น Terraform หรือ CI ที่แก้โซน ยังทำงานได้เมื่อ record ถูกล็อก และมีขั้นตอนปลดล็อกที่มีบันทึก
อาคารศูนย์ข้อมูลของ AWS ที่ Ashburn รัฐเวอร์จิเนีย ภาพประกอบข่าว Route 53
อาคารศูนย์ข้อมูลของ AWS ที่ Ashburn รัฐเวอร์จิเนีย ภาพประกอบ ภาพ: Vahurzpu / Wikimedia Commons (CC BY-SA 4.0)

บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง

โซน DNS และบัญชีคลาวด์ที่หลายทีมเข้าไปแก้ได้ เป็นจุดที่ผู้ดูแลองค์กรต้องกำหนดว่าใครแก้อะไรได้ IT Support ของ THAI DATA CLOUD ดูแลผู้ใช้ อีเมล เครื่องพนักงาน เซิร์ฟเวอร์ และเครือข่าย แจ้งผ่าน Ticket ที่ตรวจสอบได้ โดยทีมไทย 24x7 (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)

ติดตามข่าวคลาวด์เพิ่มเติมได้ที่หมวดคลาวด์

คำถามที่พบบ่อย

Route 53 record set protection คืออะไร?

Route 53 record set protection ตามประกาศของ AWS เป็นฟีเจอร์ของ Amazon Route 53 ที่ให้ผู้ดูแล DNS ล็อก record สำคัญใน hosted zone ตามชื่อและประเภท เช่น record ที่ apex ของโซน MX และ endpoint ระบบจริง การเปลี่ยน record ที่ถูกป้องกันจะถูกบล็อกจนกว่าผู้มีสิทธิ์จะปลดการป้องกัน

Route 53 record set protection ต่างจากการเขียนเงื่อนไขใน IAM อย่างไร?

แบบเดิมต้องเขียนเงื่อนไขระดับ record ลงในนโยบาย IAM ของทุกผู้ใช้และบทบาทที่แก้โซนได้ และเมื่อถูกบล็อกผู้แก้ไม่ทราบว่า record ถูกป้องกันหรือเพราะอะไร แบบใหม่ตั้งการป้องกันตรงใน hosted zone พร้อมหมายเหตุได้สูงสุด 256 ตัวอักษร

ป้องกัน record ก่อนที่ record นั้นจะมีอยู่ได้หรือไม่?

ได้ AWS ระบุว่า Route 53 record set protection สร้างการป้องกันล่วงหน้าได้ เพื่อกันไม่ให้มีการสร้าง record ชื่อและประเภทนั้นขึ้นมา

ใครปลดการป้องกันของ Route 53 ได้?

ผู้ที่ได้สิทธิ์ DeleteResourceRecordSetProtections บนโซนนั้นใน IAM ปลดการป้องกันได้ทุกรายการ คู่มือ Route 53 จึงระบุว่าการป้องกันแข็งแรงเท่านโยบาย IAM ที่คุมสิทธิ์นี้ ดังนั้นองค์กรควรจำกัดสิทธิ์นี้ให้เหลือเฉพาะผู้ดูแลที่เหมาะสม

แหล่งอ้างอิง

  1. Amazon Route 53 now supports record set protection — Amazon Web Services
  2. Protecting records from changes - Amazon Route 53 Developer Guide — Amazon Web Services

บุคคล องค์กร และสถานที่ในข่าวนี้

เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว

องค์กรและบริษัท
AWS145Amazon95
ผลิตภัณฑ์และเทคโนโลยี
Terraform17
แชร์FacebookXLINELinkedIn

พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ