CAA Record Generator: ล็อกการออกใบรับรองของโดเมนคุณด้วย DNS CAA Record

Certificate authority ยินดีออกใบรับรองให้โดเมนไหนก็ได้ที่คุณพิสูจน์ความเป็นเจ้าของได้ — และตามค่าเริ่มต้นมันไม่เคยถามเลยว่าคุณ อยาก รับใบรับรองจาก CA ตัวนั้นหรือไม่ ประตูที่เปิดแง้มนี้แหละคือสิ่งที่ CAA เข้ามาปิด CAA record บอก certificate authority ทุกเจ้าว่า CA ไหนมีสิทธิ์ออกใบรับรองให้โดเมนของคุณ — เป็นกุญแจราคาถูกที่กันการออกใบรับรองเกินอำนาจ (mis-issuance) ตั้งแต่ปี 2017 CA ที่ทำตาม CA/Browser Forum baseline requirements ต้องเช็ก record เหล่านี้ก่อนออกใบรับรองทุกครั้ง แปลว่า DNS แค่ไม่กี่บรรทัดก็เบียดให้ CA ที่ถูกแฮ็กหรือผิดพลาดออกใบรับรองให้โดเมนคุณแอบ ๆ ไม่ได้

CAA Record Generator เปลี่ยนการเขียนนโยบายนี้ให้เหลืองานสองนาที เลือก certificate authority จาก preset อย่าง Let's Encrypt, DigiCert และ Sectigo ตัดสินใจว่าจะจัดการ wildcard อย่างไร เพิ่มที่อยู่รับรายงานเหตุการณ์ได้ตามต้องการ แล้วคัดลอกผลลัพธ์ในรูปแบบที่ DNS provider คุณใช้: snippet แบบ BIND zone file, ค่ารายฟิลด์สำหรับ Cloudflare dashboard หรือ AWS Route 53 change-batch JSON ทุกอย่างประมวลผล 100% ฝั่ง client-side ชื่อโดเมนของคุณจึงไม่เคยออกจากเบราว์เซอร์

ทำไมต้องใช้ CAA Record Generator

• CA preset ตัดปัญหาการเดา. นโยบายที่เขียน letsencrypt.com แทนที่จะเป็น letsencrypt.org ไม่คุ้มกันอะไรเลย — แต่ละ CA เช็กจากโดเมนที่จดทะเบียนของตัวเองแบบเป๊ะ ๆ preset ช่วย emit identity ที่ถูกต้องให้ทุกครั้ง
• ครบทั้งสาม tag ในที่เดียว. issue, issuewild และ iodef ถูกประกอบให้พร้อม ทั้ง flags และรูปแบบ quoted value ถูกต้อง ไม่ต้องพิมพ์เอง
• สามรูปแบบ output พร้อมใช้ต่อ provider. นโยบายชุดเดียวเรนเดอร์เป็น BIND zone file, ค่าสำหรับ Cloudflare dashboard และ Route 53 change-batch JSON — เปลี่ยนโฮสต์เมื่อไรก็ไม่ต้องจัดรูปแบบใหม่
• คัดลอกไปวางได้ทันที. คลิกเดียวคัดลอกทีละ record หรือทั้งชุด
• รายงานเหตุการณ์ในตัว. มีที่อยู่ iodef เมื่อไรที่ CA เห็นความพยายามใช้โดเมนของคุณผิดวิธี มันจะแจ้งเข้ามาหาคุณ
• ประมวลผล 100% ฝั่ง client-side. ไม่มีการอัปโหลด เก็บ log หรือจัดเก็บข้อมูลใด ๆ — เครื่องมือรันในเบราว์เซอร์ของคุณล้วน ๆ

ฟีเจอร์เด่น

• ตาม semantics ของ RFC 8659 ตั้งแต่ต้น. flag, tag และ quoted value ถูก emit ถูกต้องทุกครั้ง CA ทุกเจ้า parse ได้เหมือนกัน
• เป็นอิสระจาก provider. สร้างครั้งเดียว วางได้ทุกที่ — ทุกรูปแบบแบกนโยบายชุดเดียวกัน

วิธีใช้งาน

1. เปิดเครื่องมือ CAA Record Generator แล้วกรอก โดเมนของคุณ — record จะ publish ที่ zone apex
2. เลือก certificate authority จาก preset โดยเลือกครบทุก CA ที่คุณใช้ออกใบรับรองอยู่วันนี้
3. เลือก tag. เก็บ issue สำหรับใบรับรองปกติ ตั้งกฎ issuewild แยกถ้า wildcard ต้องใช้นโยบายต่างกัน และเพิ่มที่อยู่ iodef แบบ mailto เพื่อให้กรณีละเมิดส่งเข้าหาคุณ
4. เลือกรูปแบบ output แล้วคัดลอก: BIND zone file, ฟิลด์สำหรับ Cloudflare dashboard หรือ Route 53 change-batch JSON
5. Publish แล้วทดสอบ. เพิ่ม record ที่ DNS provider รอให้ propagate แล้วสั่งออกใบรับรองจริงหนึ่งใบเพื่อยืนยันว่า CA ของคุณผ่าน

issue, issuewild และ iodef

ชุด CAA record คือรายการ property record แต่ละรายการมี flag ตัวเลข, tag และ quoted value สาม tag แบ่งหน้าที่กันนิยามนโยบายของคุณ:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "digicert.com"
example.com.  IN  CAA  0 iodef "mailto:[email protected]"

• issue — อนุญาตให้ certificate authority ที่ระบุชื่อออกใบรับรองปกติแบบ single-name
• issuewild — อนุญาต CA ที่ระบุชื่อเฉพาะใบรับรอง wildcard เท่านั้น ถ้าไม่มี record issuewild เลย record issue จะใช้บังคับ wildcard ด้วย
• iodef — ที่อยู่รับรายงานที่ CA ต้องส่งรายละเอียดไปแจ้งเมื่อมีคนขอออกใบรับรองโดยละเมิดนโยบายของคุณ

เลข 0 นำหน้าคือ flag field ที่ RFC 8659 สงวนไว้

ทำไมถึงมีได้หลาย record. การประเมิน CAA เป็นแบบ union ไม่ใช่ first-match ถ้ามี CAA record อยู่ CA ทุกเจ้าในลิสต์ออกใบรับรองได้หมด และนอกลิสต์ห้ามทั้งนั้น publish issue record ละหนึ่งตัวต่อ CA นโยบายก็คือ "ตัวไหนในลิสต์ก็ได้ และมีแค่ตัวเหล่านี้" preset สำคัญเพราะแต่ละ CA เช็ก identity ของตัวเองแบบเป๊ะ ๆ: Let's Encrypt มองหา letsencrypt.org, DigiCert มองหา digicert.com, Sectigo มองหา sectigo.com — เขียนโดเมนคล้ายกันแต่ไม่ตรง ได้ record ที่ดูถูกแต่ไม่ทำงาน

เทคนิคแยกนโยบาย wildcard. เพราะ issuewild ทับการตีความ issue เฉพาะ wildcard คุณจึงตัดนโยบายตามรอยต่อนี้ได้ — เช่น ให้ Let's Encrypt ออกใบรับรอง single-name ตามปกติ ส่วน wildcard สงวนไว้ให้ CA แบบเสียเงิน:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "digicert.com"

ถ้าอยากแบน wildcard ทั้งหมด ให้ emit record issuewild ที่ค่าว่าง — ใบรับรองปกติยังออกได้ แต่ wildcard เป็นไปไม่ได้อีกต่อไป

ความต่างของรูปแบบแต่ละ DNS provider. นโยบายเหมือนกันทุกที่ แต่ syntax ไม่เหมือน zone file สไตล์ BIND ใช้รูปแบบ record ด้านบน — ชื่อ, IN CAA, flag, tag, quoted value ส่วน Cloudflare dashboard มี CAA เป็น record type ระดับ first-class มี dropdown เลือก tag และ CA พร้อมใส่ quote ให้เอง AWS Route 53 คุยกันด้วย JSON: เครื่องมือสร้าง change-batch ฉบับเต็มที่ field CAAValue ฝัง quoted value ถูกต้อง พร้อมส่งผ่าน CLI หรือ API ทันที

Propagation และการทดสอบ. CAA อยู่ภายใต้ DNS caching และ TTL เปลี่ยนแล้วจึงไม่เดิมผลทันทีทั่วโลก ช่วงทดลองให้ตั้ง TTL ต่ำ ๆ publish แล้วรอให้ครบ TTL ก่อนถือว่านโยบายมีผล จากนั้นทดสอบด้วยการสั่งออกใบรับรองจริง: CA ในลิสต์ต้องสำเร็จ และกรณีถูกปฏิเสธจะมีรายงานเข้ากล่อง iodef ใบสั่งจริงหนึ่งใบพิสูจน์ทั้งเชนตั้งแต่ DNS record จนถึงการเช็กของ CA

Use Cases ในทางปฏิบัติ

ล็อกการออกใบรับรองหลังย้าย CA

การย้ายมักทิ้งสิ่งตกค้าง: automation เก่า, ACME client ที่ลืมลบ, script สั่งจองครั้งเดียว พอ CA ตัวใหม่พร้อมทำงาน ให้ publish CAA ที่ระบุแค่ issuer ตัวใหม่ ตัวตกค้างจะกลายเป็นความล้มเหลวที่มองเห็นทันที และรายงาน iodef จะบอกด้วยว่า process ไหนพยายาม

นโยบายแบบ wildcard เท่านั้น

บางทีมออกเฉพาะใบรับรอง wildcard แล้วผลัก single-name ไปที่ CDN record issuewild ที่ระบุแค่ wildcard CA คู่กับ issue ที่เข้มงวด คือการบันทึกสถาปัตยกรรมนั้นลง DNS โดยตรง ใครจะแอบขอใบรับรองนอกโมเดลก็ไม่มีทางสำเร็จ

เช็กลิสต์เพื่อการ compliance

Baseline ด้านความปลอดภัยหลายฉบับถามว่า "CA ไหนก็ได้ออกใบรับรองให้โดเมนนี้ได้หรือเปล่า?" และต้องการคำตอบที่มีหลักฐาน ชุด CAA record คือคำตอบนั้นในรูปธรรม: ตรวจสอบได้ด้วย DNS query เดียว และเป็นหลักฐานว่าการออกใบรับรองถูกจำกัดด้วยเจตนา ไม่ใช่ด้วยดวง

กระจายความเสี่ยงแบบหลาย CA

ใช้ CA สองเจ้า — ตัวหลักกับตัวสำรอง — ช่วยให้ automation ยังมีชีวิตรอดตอน CA ล่ม การลิสต์ทั้งคู่ใน CAA คงความซ้ำซ้อนนี้ไว้โดยไม่เปิดประตูให้ CA อื่นบนอินเทอร์เน็ตทั้งหมด

Best Practices

• ใส่ที่อยู่ iodef ไว้เสมอ. รายงานคือเส้นแบ่งระหว่างการออกใบรับรองที่ถูกขวางแบบไม่มีใครรู้ กับสัญญาณเตือนล่วงหน้าว่ามีอะไรกำลังส่องโดเมนคุณ
• ทบทวนนโยบายปีละครั้งและทุกครั้งที่เปลี่ยน CA. allow-list ที่เลยเวลาจะไม่ยอมรับการ renew ที่ชอบด้วยกฎหมาย หรือไม่ก็ปกป้องอะไรเงียบ ๆ เลย
• จำไว้ว่า CAA จำกัดการออกใบรับรอง ไม่ใช่ใบรับรองที่มีอยู่แล้ว. record ใหม่ไม่ revoke อะไรเลย จับคู่ CAA กับ certificate transparency monitoring เพื่อจับใบรับรองที่ออกก่อนมีนโยบาย
• Quote ค่าตามที่เครื่องมือสร้างเป๊ะ ๆ. identity ของ CA ต้องตรงทุกตัวอักษร — preset มีไว้เพื่อไม่ให้คุณต้องพิมพ์เอง
• เก็บลิสต์ให้สั้น. ทุก CA ในลิสต์ออกใบรับรองได้ ถอด preset ของ CA ที่เลิกใช้ออกทุกครั้ง
• ทดสอบด้วยใบสั่งจริงหลังแก้ทุกรอบ. การสั่งออกใบรับรองจริงหนึ่งครั้งคือหลักฐานชิ้นเดียวที่นับ

เริ่มล็อกนโยบายใบรับรองของคุณวันนี้

Mis-issuance หายากจนกว่ามันจะเกิดกับโดเมนคุณ — และตอนนั้นใบรับรองก็เชื่อถือได้ในทุกเบราว์เซอร์บนโลกไปแล้ว CAA Record Generator เปลี่ยนงานแก้นี้ให้เหลือ dropdown ไม่กี่คลิกกับกดคัดลอก: preset ครบ สาม tag สามรูปแบบ output เสียสองนาทีไปเถอะ

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• DKIM Record Generator — แปลง DKIM public key ใด ๆ เป็น DNS TXT record ที่ถูกต้องและแบ่ง chunk ถูกต้อง
• Security Headers Generator — สร้าง security header และ Content-Security-Policy แบบ hardened สำหรับเว็บคุณ
• URL Parser — แยก URL เป็น protocol, host, path และ query component ในเบราว์เซอร์

DNS ไม่กี่บรรทัด ยามเงียบ ๆ ประจำโดเมน ขอให้ทุก CA นอกลิสต์ปฏิเสธคุณ Happy building!

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

ถ: CAA record มีผลกับใบรับรองที่ออกไปแล้วหรือไม่?

ตอบ: ไม่มี CAA ถูกเช็กเฉพาะตอนออกใบรับรอง ใบที่ออกไปแล้วยัง valid จนกว่าจะหมดอายุ จึงควรจับคู่ CAA กับ certificate transparency monitoring แทนการคิดว่ามันคุ้มกันได้ทุกกรณี

ถ: ถ้าโดเมนของฉันไม่มี CAA record เลยล่ะ?

ตอบ: CA ที่ทำตามมาตรฐานทุกเจ้าออกใบรับรองให้ได้ การ publish CAA record ตัวแรกเปลี่ยนโดเมนเป็นโหมด allow-list ทันที: มีแต่ CA ที่คุณระบุเท่านั้นที่ออกให้ได้จากบัดนี้เป็นต้นไป

ถ: อนุญาต certificate authority ได้หลายเจ้าพร้อมกันไหม?

ตอบ: ได้ publish issue record หนึ่งตัวต่อหนึ่ง CA นโยบายเป็นแบบ union — CA ทุกตัวในลิสต์ออกได้ และตัวนอกลิสต์ห้ามทั้งหมด

ถ: CAA จะทำให้ auto-renewal ของ Let's Encrypt พังไหม?

ตอบ: ไม่ ถ้า letsencrypt.org อยู่ในลิสต์ ส่วนถ้าใบรับรองมี wildcard name ให้เช็กด้วยว่าเส้นทาง wildcard ได้รับอนุญาตผ่าน issue record หรือ issuewild ที่ระบุไว้ชัดเจน

ถ: CAA ที่แก้ไขใหม่มีผลเร็วแค่ไหน?

ตอบ: เร็วเท่าที่ DNS caching ยอม ภายใน TTL ของ record ช่วงทดสอบให้ตั้ง TTL ต่ำ แล้วยืนยันด้วยการสั่งออกใบรับรองจริง