Schedule icon
Request icon
Script icon
If icon
SlackIncomingWebhook icon
Log icon
OutputValues icon

Check DNS CAA Issuers Against an Approved List

Check DNS CAA issuance rules and alert Slack when allowed certificate authorities differ from policy.

Categories
CloudInfrastructure

Check which certificate authorities may issue TLS certificates for a domain and alert when effective DNS CAA issuer rules do not match an approved list.

How it works

  1. fetch_initial_caa requests CAA records from Google's DNS-over-HTTPS API.
  2. check_caa examines that response, querying parent names up to root_domain if the initial domain has no CAA policy. It reads issue, or issuewild for wildcard certificates when present, and compares issuer names to an exact allowlist. It writes caa-policy-report.json.
  3. policy_result sends a Slack alert and explanatory log on FAIL; a passing policy is logged without sending an alert.
  4. report_location publishes the status, source name, and report URI. DNS errors fail execution rather than producing a false PASS.

What you get

  • A PASS/FAIL result and JSON report with checked domains, effective issuer records, policy source, and mismatch reasons.
  • Slack notifications for completed checks that find disallowed policies.
  • A disabled-by-default weekday schedule for repeatable checks.

Who it's for

  • Security teams reviewing TLS issuance controls and compliance.
  • Infrastructure operators checking DNS CAA policy drift.
  • Platform engineers building scheduled DNS security checks.

Why orchestrate this with Kestra

Kestra combines DNS resolution, policy comparison, execution history, JSON artifacts, conditional alerts, and scheduling in one inspectable flow.

Prerequisites

  • A Kestra worker able to run the Python scripts plugin using the python:3.11-slim container image.
  • Outbound worker HTTPS access to https://dns.google/resolve.
  • A Slack incoming webhook for policy-mismatch alerts.
  • A correct root_domain boundary; parent lookup stops there.

Secrets

  • SLACK_WEBHOOK_URL: Slack webhook used by alert_caa_violation. Keep the value in Kestra Secrets, not in the flow YAML.

Quick start

  1. Configure the SLACK_WEBHOOK_URL secret.
  2. Import the blueprint and manually run its public google.com example with pki.goog. Review the current result rather than assuming a PASS: public CAA records may change.
  3. Set domain, root_domain, and comma-separated allowed_issuers to your own domain and issuer policy. Extra or missing issuers fail.
  4. Use wildcard to check wildcard issuance; use require_explicit to require an issuer rule even when no record is present.
  5. Read outputs.report_location.values.status (PASS/FAIL) and outputs.report_location.values.report_uri (JSON report).
  6. Test a deliberate issuer mismatch and verify the Slack notification. Enable the weekday schedule only after manual verification.

How to extend

  • Feed failed checks into incident-management or approval workflows.
  • Check several owned domains with a ForEach task.
  • Store successive reports in object storage to track policy drift.
  • Add DNSSEC, CNAME resolution, and account-option checks separately before treating this as a comprehensive certificate issuance audit.

Limits

  • Compares issuer domain names only; it does not evaluate CAA account options, DNSSEC, CNAME traversal, or actual certificate issuance.
  • Unsupported CAA encodings or CNAME answers stop the audit.
  • The root boundary and use of a public DNS resolver are explicit tradeoffs; ensure both meet your organization's security policy.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.