CAA Records So Only Your Certificate Authority Can Issue

A Certificate Authority Authorization record is a DNS policy that tells public CAs whether they are allowed to issue for your domain. It does not encrypt anything. It does not replace SPF. It is a gate in front of issuance: Let's Encrypt, Google Trust Services, ZeroSSL, and the commercial CAs are supposed to query CAA before they sign. If your name is valuable enough that a mis-issued certificate would hurt, CAA is one of the cheapest controls you can add to a VPS zone.

Without CAA, any CA that can pass an ACME or email challenge may issue. With CAA, you name the CA you actually use, and a second CA should refuse. That matters when a forgotten subdomain, a reseller account, or a lookalike order would otherwise produce a trusted cert.

The record is a tag, not a certificate

CAA lives on the domain (and can be inherited from a parent). The common properties are issue, issuewild, and iodef. issue lists a CA that may mint non-wildcard certs. issuewild lists a CA that may mint wildcard certs. iodef is a URL or mailto where a CA can report a policy violation. An empty issue value (just empty quotes in some UIs) means "nobody may issue."

Let's Encrypt's CA domain in CAA is letsencrypt.org. If you also use another ACME CA as a fallback, add a second issue record. A single issue record that names only Let's Encrypt will cause a Google Trust Services or ZeroSSL request to fail, which is the point if you did not intend that CA.

dig +short CAA example.com
dig CAA example.com @1.1.1.1
dig CAA www.example.com

If www has no CAA of its own, the CA walks up to example.com. That tree walk is defined in RFC 8659. A CAA on a parent covers subdomains unless a closer CAA exists. Putting CAA only on www and not on the apex is a hole for the apex name.

Issue and issuewild are not interchangeable

A wildcard certificate is issued against a different policy flag. If you set only issue "letsencrypt.org" and later request *.example.com, Let's Encrypt must also find issuewild allowing it, or find no issuewild and then fall back depending on current CA policy. Do not guess. If you use wildcards, publish both:

example.com.  300  IN  CAA  0 issue "letsencrypt.org"
example.com.  300  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  300  IN  CAA  0 iodef "mailto:ops@example.com"

The flags field is usually 0. The issuer critical flag (128) is for properties a CA must understand or refuse. You almost never need it on a VPS zone. iodef does not have to be a working mailbox for issuance to succeed, but if you publish it, monitor it.

CAA can break a working certbot overnight

The failure mode looks like: HTTP-01 succeeded last month, DNS is unchanged, nginx is fine, and today's renewal dies with a CAA error. Someone added a "security" CAA at the registrar that names a commercial CA, or a panel wizard wrote issue ";" meaning deny all. Certbot will not override CAA. Fix the zone, wait TTL, retry.

Another failure: you allow letsencrypt.org but your automation switched to a different ACME directory (staging versus production is the same CA; a different CA hostname is not). Staging Let's Encrypt still uses the Let's Encrypt identity. A third-party ACME CA does not.

Test with the CA you will actually call. After publishing CAA, run a dry issuance or wait for the next renewal rather than discovering the policy during an expiry incident.

How to roll it out on a VPS domain

Start with a read-only inventory: which CA issued the current leaf. openssl s_client will show Let's Encrypt or another issuer. Match CAA to that issuer before you tighten anything. Add issue (and issuewild if you have wildcards). Keep TTL modest (300–1800) until the next successful renewal. Then you can raise it.

Do not mix CAA with a CNAME at the same node. If www is a CNAME, put CAA on the apex and let the CA tree-walk, or put CAA on the CNAME target according to the alias rules. For a simple VPS zone, CAA on the apex plus A records for apex and www is the layout that surprises people least.

CAA is optional in the protocol sense and mandatory in the operational sense once you care who can mint a trusted cert for your name. Name the CA you run certbot against, include issuewild if you mint wildcards, and verify with dig before the next ACME run. You can apply this on a Netbay Ubuntu VPS in Lucknow (DC01) the same day you point the A record — netbayhosts.in.