Safety
CAA Records vs Registrar Lock for Domain OPSEC
May 9, 2022
CAA records vs registrar lock are two different doors on the same house. Certification Authority Authorization (CAA) is a DNS record that tells public CAs which issuers are allowed to mint certificates for your domain. Registrar lock (clientTransferProhibited) blocks a class of domain-theft transfers. CAA does not stop someone who already controls your DNS from changing CAA. Lock does not stop a CA from issuing if your DNS still allows them. Marketing sites should publish a tight CAA for the CA they actually use, keep transfer lock on, and still run MFA on the registrar. RoastMyOpsec inventories public NS for hygiene context. It does not attempt transfers, issuance, or CAA forging.
The practical difference
CAA is issuance policy. A CA that checks CAA should refuse to issue if your record does not name them (or if you used issuewild vs issue incorrectly for wildcards). It is a speed bump against surprise certificates, not a cryptographic proof that no cert exists.
Registrar lock is account policy. It makes unauthorized transfers fail until you unlock on purpose. Combined with unique passwords and MFA, it is how you keep the zone from walking out the registrar's front door.
How to choose what to ship this week
If the registrar account is still on a shared mailbox password, lock and MFA first. Then add CAA for the CA your CDN or ACME client actually uses (including issuewild if you mint *.example.com). If you use two issuers during a migration, list both until cutover, then drop the old one.
Do not copy someone else's CAA that names a CA you never configured. Failed issuance is an outage with extra steps.
| Control | What it limits | What it does not limit | Takeaway |
|---|---|---|---|
| CAA issue / issuewild | Which public CAs should issue for the name | Attackers who already edit your DNS; private PKI | Publish for the CA you use; keep it current |
| Registrar transfer lock | Surprise domain transfers | Compromised registrar login that can unlock first | On by default; MFA the account |
| DNSSEC | Forged DNS answers when validators check | Unlocked registrar; stale CAA | Pair with hygiene; see the DNSSEC guide |
| NS inventory | Knowing who answers the zone | Issuance policy | Start here so CAA is on the live nameservers |
When CAA still fails OPSEC
CAA on the apex only, while www or the API host lives in a different zone, is a common miss. Wildcards need issuewild. A leftover CAA that names last year's CA is how ACME breaks on deploy day.
A URL roast will not prove your CAA is correct. Confirm in DNS and in your CA's issuance logs. The scan is not a certificate-transparency hunt.
Common mistakes
The first mistake is CAA without lock, as if issuance policy stops domain theft.
The second mistake is lock without CAA, then wondering why a surprise cert appeared in a dashboard.
The third mistake is setting CAA on a staging zone that is not the zone browsers actually query.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is CAA better than registrar lock?
- They solve different problems. Lock the registrar. Publish CAA for your real CA. Do both.
- Does RoastMyOpsec check my CAA records?
- The public DNS work is nameserver inventory for hygiene, not a full CAA or DNSSEC validator. Confirm CAA at your DNS host.
- Will CAA stop mixed content or expired certs?
- No. CAA is about who may issue. Expiry, HSTS, and mixed content are separate guides.