全球 CAA 紀錄檢查器
CAA (Certification Authority Authorization) 紀錄是 RFC 6844 中引入的一項關鍵安全增強功能，旨在強化公開金鑰基礎架構 (PKI)。CAA 紀錄允許網域管理員明確定義到底哪些憑證授權單位（Certificate Authorities，例如 Let's Encrypt、DigiCert 或 Sectigo）在法律上被允許為其基礎架構核發 SSL/TLS 憑證。它作為一種積極的邊界防禦機制 (perimeter defense)，防止流氓或被入侵的憑證授權單位產生用於中間人攻擊的欺詐性、受信任憑證。
強制性的核發前檢查
自 2017 年以來，CA/Browser Forum 規定每個商業 CA 在核發任何憑證之前都必須執行 CAA 紀錄的 DNS 查詢。當自動化的 ACME 用戶端或管理員請求憑證時，CA 會查詢該區域。如果不存在 CAA 紀錄，CA 會假定具有隱含權限並核發憑證。然而，如果存在 CAA 紀錄，且發出請求的 CA 主機名稱（例如 letsencrypt.org）未明確列在 Payload 中，則核發過程將被硬性阻擋，並在 CA 層級立即中止。
Tree-Climbing 解析邏輯與應用範圍
CAA 架構的一個強大方面是它的「tree-climbing」（向上爬樹）解析邏輯。如果管理員為深度巢狀的子網域（例如 api.staging.example.com）請求憑證，憑證授權單位會向該確切節點查詢 CAA 紀錄。如果找不到，它會向上解析，檢查 staging.example.com，最後檢查頂點 example.com。這意味著部署在根網域的單一 CAA 紀錄可充當全面的安全原則，自動向下聯級 (cascade) 並保護其下方的每個子網域免於未經授權的核發。
除錯自動更新失敗
雖然 CAA 紀錄極大地提高了安全性，但它們卻是現代 DevOps 流程 (pipelines) 中突然、無聲的 SSL 故障的主要原因。如果一家公司從 DigiCert 核發的手動 Wildcard 憑證轉換為透過 Kubernetes cert-manager 的自動 Let's Encrypt 更新，但忘記更新其限制性的 CAA 紀錄，更新機器人將會失敗。CA 將回傳授權錯誤，最終，正式環境的憑證將會過期，觸發所有終端使用者的瀏覽器警告。此外，管理員可以在 CAA Payload 內設定 iodef 標籤，指示 CA 在發生被阻擋的核發嘗試時，發送自動電子郵件或 webhook 警報給安全團隊。