DNS-PERSIST-01: โมเดลใหม่สำหรับการตรวจสอบความท้าทายบนพื้นฐาน DNS

 (letsencrypt.org)
4 คะแนน โดย GN⁺ 2026-02-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DNS-PERSIST-01 ของ Let's Encrypt เป็นโมเดล ACME challenge แบบใหม่ที่มาแทนการตรวจสอบซ้ำแบบ DNS-01 เดิม โดยใช้ บันทึกการยืนยันตัวตนแบบคงอยู่ถาวร
  • วิธีนี้พิสูจน์การควบคุมโดเมนในระยะยาวผ่าน ระเบียน TXT ที่ผูกกับบัญชี ACME และ CA ที่ระบุ
  • ช่วยลดการเปลี่ยนแปลง DNS และ ภาระในการกระจายข้อมูลรับรอง API ทำให้ทั้งประสิทธิภาพการปฏิบัติการและความปลอดภัยดีขึ้นพร้อมกัน
  • รองรับฟังก์ชันควบคุมอย่างละเอียด เช่น ตัวเลือกนโยบาย (policy=wildcard), เวลาหมดอายุ (persistUntil), และ การอนุญาตหลาย CA
  • มีแผนเปิดใช้งาน staging ช่วงปลายไตรมาส 1 ปี 2026 และ rollout เต็มรูปแบบในไตรมาส 2 โดยคาดว่าจะช่วย ทำให้การจัดการใบรับรองในสภาพแวดล้อมขนาดใหญ่และอัตโนมัติง่ายขึ้น

ข้อจำกัดของวิธี DNS-01

  • DNS-01 challenge แบบเดิมต้องสร้างโทเค็นใหม่ทุกครั้งที่ออกใบรับรอง และต้องเพิ่มระเบียน TXT ที่ _acme-challenge.
    • ทุกการตรวจสอบต้องอัปเดต DNS ทำให้เกิดความล่าช้าในการเผยแพร่ข้อมูลและความซับซ้อนด้านอัตโนมัติ
  • ในการใช้งานระดับใหญ่ ข้อมูลรับรอง DNS API จะกระจายอยู่ในหลายระบบ ทำให้ความเสี่ยงด้านความปลอดภัยเพิ่มขึ้น
  • ผู้ใช้งานบางรายต้องการหลีกเลี่ยงการเปลี่ยน DNS ซ้ำๆ เหล่านี้

โครงสร้างและวิธีทำงานของ DNS-PERSIST-01

  • วิธีใหม่นี้นำแนวคิด การให้สิทธิ์แบบคงอยู่ถาวร (persistent authorization) มาใช้
    • ตั้งค่าระเบียน TXT ที่ _validation-persist. เพียงครั้งเดียว โดยใส่ CA และ URI ของบัญชี ACME
    • หลังจากนั้นสามารถใช้ระเบียนเดิมซ้ำได้ทั้งในการออกและต่ออายุใบรับรอง
  • ตัวอย่าง: 
    _validation-persist.example.com. IN TXT (  
  "letsencrypt.org;"  
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"  
)
  • ด้วยเหตุนี้ การเปลี่ยน DNS จึงถูกตัดออกจากเส้นทางการออกใบรับรอง ช่วยเพิ่มประสิทธิภาพการดำเนินงาน

จุดสมดุลด้านความปลอดภัยและการปฏิบัติการ

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

ฟังก์ชันควบคุมขอบเขตและอายุการใช้งาน

  • โดยค่าเริ่มต้น จะมีผลแบบไม่มีกำหนดกับ FQDN ที่ผ่านการตรวจสอบแล้วเท่านั้น
  • สามารถขยายให้ครอบคลุม wildcard และโดเมนย่อย ได้ด้วยตัวเลือก policy=wildcard 
    "policy=wildcard"
  • สามารถกำหนด เวลาหมดอายุ (หน่วยเป็นวินาที UTC) ได้ด้วยแอตทริบิวต์ persistUntil
    • ต้องต่ออายุก่อนหมดอายุ และจำเป็นต้องมีระบบมอนิเตอร์
    "persistUntil=1767225600"
  • หากต้องการอนุญาตหลาย CA พร้อมกัน ให้เพิ่ม ระเบียน TXT แยกตาม CA ที่ _validation-persist.

กำหนดการนำไปใช้และสถานะการพัฒนา

  • การลงคะแนน CA/Browser Forum SC-088v3 ผ่านเป็นเอกฉันท์ในเดือนตุลาคม 2025 และ IETF ACME Working Group ก็รับร่างนี้ไว้แล้ว
  • ตอนนี้รองรับแล้วใน Pebble (เวอร์ชันย่อของ Boulder) และกำลังดำเนินการพัฒนาไคลเอนต์ lego-cli
  • มีกำหนด staging ช่วงปลายไตรมาส 1 ปี 2026 และ เปิดใช้งานจริงเต็มรูปแบบในไตรมาส 2
  • โมเดลนี้เหมาะกับพื้นที่ที่วิธีเดิมไม่มีประสิทธิภาพ เช่น IoT, มัลติเทนแนนต์, และสภาพแวดล้อมที่ออกใบรับรองจำนวนมาก

ภูมิหลังของ Let's Encrypt และ ISRG

  • Let's Encrypt คือ หน่วยงานออกใบรับรอง (CA) ฟรี อัตโนมัติ และเปิดกว้าง ที่ดำเนินการโดย องค์กรไม่แสวงหากำไร ISRG
  • ISRG เปิดเผยกิจกรรมด้านความปลอดภัยอินเทอร์เน็ตไว้ในรายงานประจำปี 2025

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

1 ความคิดเห็น

 
GN⁺ 2026-02-20
ความคิดเห็นจาก Hacker News

  • ดีใจมากที่ได้เห็นข่าวนี้
    ถ้าใช้ bind เป็น authoritative nameserver ฉันตั้งค่าให้จำกัด hmac-secret เพื่อให้เว็บเซิร์ฟเวอร์แต่ละตัวอัปเดตได้เฉพาะ TXT record ของตัวเอง
    แบบนี้ถึงแม้เซิร์ฟเวอร์ “bob” จะถูกเจาะ ก็จะขอออกใบรับรองได้เฉพาะสำหรับโดเมน “bob” เท่านั้น
    ตัวอย่างการตั้งค่าคือใช้ update-policy เพื่อจำกัดให้แต่ละคีย์แก้ไขได้เฉพาะซับโดเมนใต้ _acme-challenge

    • ถ้ายินดีรัน DNS เซิร์ฟเวอร์แยกต่างหากแทน bind, acmedns ก็มีฟังก์ชันคล้ายกัน
      เมื่อสร้างบัญชีใหม่ ระบบจะให้ซับโดเมนเฉพาะมา และถ้าทำ CNAME ของโดเมน challenge ไปยังซับโดเมนนั้น ก็จะมีเพียงบัญชีนั้นที่อัปเดตโซนนั้นได้

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

    • ใน CAA record ค่า accounturi ก็เปิดเผยตัวระบุบัญชีอยู่แล้ว ดังนั้นในระดับหนึ่งมันก็เป็นข้อมูลสาธารณะอยู่แล้ว
      ฉันกลับคิดว่าถ้าให้ฟอร์แมตของ CAA กับ persist record สอดคล้องกันน่าจะดีกว่า
    • น่าจะให้ผู้ใช้ใช้ ID แบบสุ่มอย่าง UUID แทนบัญชีจริง แล้วใส่ใน accounturi
    • เพราะมันเป็นบัญชีเดียวกับที่ ACME client สร้างอยู่แล้ว ฉันเลยมองว่าความเสี่ยงจากการค้นย้อนหลังไม่ได้สูงมาก

  • แปลกใจที่ไม่ได้บังคับใช้ DNSSEC
    เมื่อก่อนฉันคิดว่า DNSSEC ยุ่งยาก แต่ตอนนี้มีทั้ง CAA, CERT, SSHFP, TXT และ record ที่กระทบกับ root of trust มากขึ้น จึงเสี่ยงต่อการโจมตีแบบ MITM
    โดยเฉพาะเมื่อแม้แต่บริษัทใหญ่ ๆ ก็ยังมักตั้งค่า DNSSEC ไม่ครบถ้วน ฉันคิดว่าอย่างน้อยก็ควรระบุไว้เป็นคำแนะนำ

    • ในร่าง RFC ก็แนะนำให้ใช้ DNSSEC ในระดับ “SHOULD” อยู่แล้ว (ลิงก์)
    • เดิมที DNS ก็เป็น single point of failure สำหรับการออกใบรับรอง TLS อยู่แล้ว
      ถ้าผู้โจมตียึด DNS ได้ ก็สามารถปลอมใบรับรองได้ไม่ว่าจะใช้ HTTP-01, TLS-ALPN-01 หรือ DNS-01
    • ส่วนตัวฉันมองว่า TLSA เป็นแนวทางที่ดีกว่า DNSSEC แต่ก็น่าเสียดายที่แทบไม่มีเบราว์เซอร์รองรับ

  • ฟีเจอร์นี้น่าจะทำให้การออก ใบรับรองสำหรับเซิร์ฟเวอร์ LAN ที่ไม่ได้เปิดสู่ภายนอกง่ายขึ้นมาก
    ต่อไปน่าจะเห็น UI สำหรับผู้ดูแลส่วนใหญ่สร้างสตริงสำหรับนำไปวางใน DNS record ให้อัตโนมัติ แล้วรับใบรับรองจาก Let's Encrypt ได้ทันที

    • ฉันเองก็เคยลองในสภาพแวดล้อมคล้ายกัน แต่การตั้งค่า headscale magic DNS ซับซ้อนกว่าที่คิด สุดท้ายเลยกลับไปใช้การต่ออายุแบบทำเอง

  • ถ้าเป็นผู้ใช้ certbot สามารถติดตามสถานะการรองรับฟีเจอร์นี้ได้ใน GitHub issue

  • แต่ก่อนฉันเคยสงสัยเรื่องการออกใบรับรองอายุสั้น แต่พอเห็น ใบรับรองสำหรับ IP address กับการตรวจสอบแบบ HTTP-01 ก็เปลี่ยนความคิด
    ตอนนี้ฉันไม่เก็บใบรับรองไว้บนดิสก์แล้ว และให้ background thread ตรวจหาใบรับรองใหม่ทุก 24 ชั่วโมง
    แบบนี้ทำให้สร้างโซลูชัน self-hosted ที่ผู้ใช้แค่ deploy ซอฟต์แวร์ลง VM ก็ พร้อมใช้งานได้ภายใน 5 นาที
    ถ้ารวมกับบริการอย่าง checkip.amazonaws.com ก็ทำให้ deployment อัตโนมัติได้เต็มรูปแบบ

    • แต่ rate limit ของ Let's Encrypt ต่อรองไม่ได้ ดังนั้นถ้าขอบ่อยเกินไปก็เสี่ยงต้องรอ
    • ถ้าไม่เก็บใบรับรองไว้เลย ความพร้อมใช้งานจะขึ้นกับ uptime ของ LE ดังนั้นอย่างน้อยก็ควรมีการเก็บไว้นิดหน่อย

  • ในที่สุดก็ดูเหมือนว่าจะ ทำระบบอัตโนมัติ สำหรับใบรับรองของเว็บเซอร์วิสภายในได้ง่ายขึ้น
    ให้ความรู้สึกเหมือนแก้ปัญหาด้านปฏิบัติการที่ใหญ่ที่สุดไปได้แล้ว เลยยินดีมาก

  • ส่วนที่ยังขาดอยู่ตรงนี้คือ การยืนยันความเป็นเจ้าของบัญชี ACME
    ปกติเครื่องมืออัตโนมัติส่วนใหญ่จะสร้างบัญชีเอง ผู้ใช้จึงไม่ได้แตะต้องโดยตรง แต่ตอนนี้จำเป็นต้องส่งข้อมูลรับรองที่ใช้พิสูจน์ความเป็นเจ้าของบัญชีให้ผู้ให้บริการ ACME
    ถ้า Let's Encrypt ไม่สามารถสร้างโทเค็นที่จำกัดตามแต่ละโดเมนได้ อาจต้องแยกสร้างบัญชีต่อโดเมน

    • แต่บัญชี ACME เองก็มีข้อมูลรับรองสำหรับยืนยันตัวตนอยู่แล้ว และยังยืนยันความเป็นเจ้าของโดเมนผ่าน DNS หรือ HTTP challenge ด้วย
      ถ้าข้อมูลรับรองหรือ endpoint พวกนั้นถูกยึดได้ ก็แปลว่าสถานการณ์มีปัญหาใหญ่กว่านั้นอยู่แล้ว

  • สำหรับผู้ใช้ Dynamic DNS นี่เป็นข่าวที่น่ายินดีมาก
    ตัวอย่างเช่นกรณีอย่าง Namecheap ที่คำขอเปลี่ยนแปลงทำได้จาก fixed IP เท่านั้น ตอนนี้แค่ตั้งค่าไว้ครั้งเดียวก็ทำการต่ออายุอัตโนมัติได้
    ฉันวางแผนจะลองแน่นอนตอนอัปเกรด homelab ให้ทันสมัยขึ้น

  • ถ้าฉันไม่ได้เข้าใจผิด ก็สงสัยว่าคนที่ควบคุม DNS server ของโดเมนฉัน หรือคนที่ดักทราฟฟิกระหว่าง Let's Encrypt กับ DNS server ได้ จะสามารถออกใบรับรอง TLS สำหรับโดเมนฉันได้ไม่ใช่หรือ
    DNS-01 ก็มีปัญหาเดียวกัน แต่แบบใหม่นี้ดูเหมือนยิ่งง่ายกว่า เพราะผู้โจมตีแค่ใส่บัญชี LE ของตัวเองลงไปใน DNS response
    ฉันเลยสงสัยว่าน่าจะเอาใบรับรอง public ของฉันใส่ไว้ใน DNS ตรง ๆ จะดีกว่าไหม

    • ถ้าคุณเชื่อถือผู้ให้บริการ DNS ไม่ได้ ความสัมพันธ์นั้นเองก็มีปัญหาแล้ว
      ถ้ามีคนทำ MITM ทราฟฟิกระหว่าง LE กับ DNS server ได้ ก็ถือว่าเป็นสถานการณ์ที่ร้ายแรงกว่านั้นมากอยู่แล้ว
    • คนที่ควบคุม DNS ได้ สามารถออกใบรับรองจาก CA ไหนก็ได้
      ถ้าเปลี่ยน DNS ได้ ก็ไม่มีวิธีป้องกันการออกใบรับรอง
    • ถ้าควบคุม DNS ได้ ก็ทำ HTTP challenge ได้ด้วย ดังนั้นในทางปฏิบัติโดเมนนั้นก็เป็นของคนนั้นแล้ว
    • CA ต่าง ๆ ตรวจสอบ DNS จากหลายมุมเครือข่ายเพื่อ ลดผลกระทบจากการโจมตีทางเครือข่าย
      Let's Encrypt ทำแบบนี้มาหลายปีแล้ว และตั้งแต่ปี 2024 เป็นต้นไปก็เป็นข้อบังคับสำหรับ CA ทุกเจ้า
      ลิงก์ข้อกำหนด CAB Forum
    • วิธีแบบนี้จริง ๆ แล้วคือแนวทางที่ DANE ใช้อยู่
      ข้อมูลที่เกี่ยวข้อง