CAA record (Certification Authority Authorization) là DNS record cho phép chủ sở hữu domain chỉ định Certificate Authority nào được phép phát hành certificate cho domain đó. Theo RFC 8659, CAA là một authorization control được CA kiểm tra trước issuance; nó giúp giảm rủi ro certificate bị phát hành ngoài ý muốn nhưng không phải là bảo đảm tuyệt đối.
Bài này giải thích issue, issuewild, iodef, cách CAA inheritance hoạt động, những lỗi cấu hình thường gặp và cách audit CAA trong DNS zone.
Hiểu CAA record và các property tag
CAA record là gì?
CAA là DNS resource record cho phép domain holder công bố CA nào được ủy quyền issue certificate. Một domain có thể có nhiều CAA record để cho phép nhiều CA hoặc mô tả chính sách khác nhau.
Cú pháp cơ bản
Dạng trình bày chuẩn là CAA <flags> <tag> <value>. Ví dụ:
example.com. 300 IN CAA 0 issue "letsencrypt.org"Trong đó 0 là flags, issue là property tag và value xác định issuer domain name.
Tag issue dùng để làm gì?
issue cho biết CA nào được phép issue certificate thông thường cho FQDN. Nếu Relevant CAA RRset có issue, CA phải xác định request có phù hợp policy đó hay không trước khi phát hành.
Tag issuewild dùng để làm gì?
issuewild áp dụng riêng cho wildcard certificate. Nếu có issuewild, wildcard issuance được đánh giá theo tag này. Điều này cho phép tổ chức dùng policy khác nhau cho certificate thường và wildcard.
Tag iodef là gì?
iodef được thiết kế để chỉ định nơi nhận báo cáo về CAA policy violation hoặc incident liên quan issuance. Tuy nhiên không phải mọi CA đều triển khai cùng mức hỗ trợ reporting, vì vậy không nên coi iodef là alerting system duy nhất.
CAA inheritance hoạt động thế nào?
RFC 8659 định nghĩa cách CA tìm Relevant CAA RRset bằng cách đi từ FQDN lên DNS tree cho tới khi gặp CAA RRset phù hợp. Điều này có nghĩa policy ở parent có thể áp dụng cho subdomain nếu subdomain không có RRset riêng.
Subdomain có thể override policy không?
Có. Khi một CAA RRset phù hợp được tìm thấy ở tên gần hơn, đó trở thành Relevant RRset cho việc đánh giá issuance. Vì vậy audit CAA phải xem cả apex và các subdomain có policy riêng.
CAA liên quan thế nào tới certificate security?
CAA có ngăn certificate mis-issuance hoàn toàn không?
Không. RFC 8659 nói rõ việc tuân thủ CAA là điều kiện cần nhưng không đủ cho certificate issuance. CAA giúp giảm rủi ro unintended mis-issue bằng cách bổ sung authorization signal cho CA, nhưng vẫn phụ thuộc vào CA processing, PKI ecosystem và toàn bộ issuance workflow.
CAA có thay thế Certificate Transparency không?
Không. CAA là pre-issuance authorization control; Certificate Transparency cung cấp visibility sau issuance thông qua public logs. Hai control bổ sung cho nhau: CAA giới hạn CA được phép issue, còn CT giúp phát hiện certificate đã được phát hành. Để quản trị inventory, issuance, renewal, CT, revocation và decommission theo một chuỗi hoàn chỉnh, xem TLS Certificate Lifecycle Security.
CAA có thay DNSSEC không?
Không. CAA record vẫn là DNS data. DNSSEC cung cấp cơ chế xác minh tính xác thực và toàn vẹn của DNS data đã ký. Nếu cần protection cho CAA record trên DNS path, DNSSEC là lớp bổ sung phù hợp, nhưng nó không thay policy CAA.
Cách cấu hình CAA an toàn
1. Inventory CA đang thực sự dùng
Trước khi thêm CAA, xác định CA nào đang issue certificate cho website, CDN, email gateway, SaaS hoặc automation. Nếu bỏ sót một CA hợp lệ, renewal có thể thất bại.
2. Phân biệt certificate thường và wildcard
Nếu tổ chức dùng wildcard, review riêng issuewild. Không nên assume một issue record luôn phản ánh đúng wildcard policy.
3. Kiểm tra subdomain exception
Một số subdomain có thể dùng SaaS hoặc CDN yêu cầu CA khác. Audit policy theo service owner thay vì áp một allowlist chung không kiểm chứng.
4. Dùng change control
CAA ảnh hưởng certificate issuance và renewal. Mọi thay đổi nên có before-state, intended CA list, validation plan và rollback. Sau write cần read-back public DNS và kiểm tra automation renewal liên quan.
Những lỗi CAA thường gặp
Cho phép CA đã không còn dùng
Record cũ làm policy rộng hơn intended. Đây là governance gap, dù không nhất thiết tạo exploit trực tiếp.
Chặn nhầm CA đang renewal
Thêm CAA quá chặt mà không inventory issuance path có thể làm renewal fail khi certificate hết hạn.
Quên wildcard policy
Wildcard certificate có thể cần issuewild riêng. Audit chỉ nhìn issue dễ bỏ sót.
Không kiểm tra parent/subdomain relationship
CAA lookup có tính kế thừa theo DNS tree. Một policy ở apex có thể ảnh hưởng subdomain nếu không có RRset gần hơn.
Audit và vận hành CAA
Cách audit CAA record
- Liệt kê toàn bộ CAA tại apex và subdomain quan trọng.
- Inventory CA đang phát hành certificate thực tế.
- Đối chiếu
issuevới certificate thường. - Đối chiếu
issuewildvới wildcard certificate. - Review
iodefnếu đang dùng. - Kiểm tra CAA inheritance ở subdomain.
- Kiểm tra automation renewal/CDN/SaaS dependency.
- Review TTL theo change process.
- Nếu dùng DNSSEC, validate CAA trong signed zone.
- Read-back sau mọi thay đổi.
CAA nên nằm ở đâu trong DNS Security?
CAA là một record-level security policy trong authoritative DNS. Nó không thay access control, DNSSEC, monitoring hoặc registrar security. Vì vậy CAA nên được audit trong bối cảnh rộng hơn của audit DNS record và DNS Security.
Ví dụ policy cơ bản
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issue "digicert.com"
example.com. 300 IN CAA 0 issuewild "letsencrypt.org"Ví dụ này chỉ minh họa cú pháp. Không nên copy vào production nếu chưa xác minh CA mà tổ chức thực sự dùng.
Checklist CAA record
- Biết CA đang issue certificate.
- Có owner cho certificate lifecycle.
- CAA chỉ cho phép CA intended.
- Review wildcard issuance riêng.
- Review subdomain override/inheritance.
- Không để CA legacy không còn dùng.
- Kiểm tra renewal automation trước change.
- Có rollback plan.
- Read-back public DNS sau change.
- Audit lại khi đổi CDN/CA/SaaS.
Để rà soát CAA cùng registrar, DNS, subdomain và TLS certificate lifecycle trong cùng một lượt, dùng Domain & DNS Security Checklist.
Mẫu dig CAA output và issuance-policy matrix
Artifact dưới đây là mẫu kiểm tra, không phải kết quả DNS thực tế của SecureWebOps.
# Query CAA ở apex
dig +noall +answer example.com CAA
# Query CAA ở subdomain quan trọng
dig +noall +answer app.example.com CAA
# Khi cần đối chiếu authoritative source
dig @authoritative-ns.example +noall +answer example.com CAAOutput thực tế cần được lưu cùng timestamp và nguồn query. Không tự suy ra policy chỉ từ ví dụ bên dưới.
| Use case | CAA policy direction | Validation bắt buộc |
|---|---|---|
| Một CA duy nhất cho certificate thường | Dùng issue cho issuer intended |
Xác minh toàn bộ issuance/renewal path thực tế đều dùng CA đó |
| Nhiều CA hợp lệ | Nhiều issue record |
Gắn owner/purpose cho từng CA, loại bỏ issuer legacy |
| Wildcard dùng CA riêng | Dùng issuewild theo wildcard policy |
Kiểm tra automation wildcard và subdomain dependency |
| Subdomain có SaaS/CDN riêng | Review RRset gần nhất và inheritance | Xác minh provider yêu cầu CA nào trước khi override |
| Không chắc issuance architecture | Không siết policy theo phỏng đoán | Inventory certificate/CA trước, trạng thái NEEDS_INVESTIGATION |
Mẫu evidence record sau thay đổi
| Field | Giá trị cần ghi |
|---|---|
| Before-state | CAA RRset trước change |
| Intended issuers | CA được owner xác nhận |
| Wildcard policy | issuewild expected state nếu có |
| Subdomain exceptions | Hostname và lý do override/inheritance |
| Renewal dependency | CDN/SaaS/ACME/provider liên quan |
| Read-back | Authoritative/public CAA state + timestamp |
| Outcome | PASS / FAIL / ROLLBACK |
Nguồn kỹ thuật tham khảo
Kết luận
CAA record cho phép domain owner công bố CA nào được phép issue certificate và là một control hữu ích để giảm unintended certificate mis-issue. Giá trị của CAA nằm ở việc policy phản ánh đúng certificate architecture thực tế, không phải chỉ ở việc “có CAA”.
Hãy inventory CA, hiểu inheritance, tách wildcard policy, kiểm tra renewal dependency và dùng read-back sau thay đổi. CAA tốt là policy được duy trì theo lifecycle, không phải record thêm một lần rồi quên.