Google Asked for Account-Bound CAA. 0 of 100 Irish Sites Have It.

On 6 October 2026 Google published its response to a set of country-code top-level domain hijacks. Attackers compromised the .gh, .sl and .as registries, rewrote authoritative DNS records, passed automated domain control validation, and walked away with unauthorised HTTPS certificates for several Google domains and, per Google, “several leading global brands and widely used online services”. Chrome blocked what it found. Google was careful to say the issuing CAs did nothing wrong, and equally careful to say browser-side blocking should not be relied on.

Then it told domain owners what to do. Two things: monitor Certificate Transparency across your whole portfolio, and publish restrictive CAA records, specifically ones restricting issuance to “specific authorized accounts and validation methods”.

That second instruction is machine-checkable from the outside, so we checked it. We took the same 100 Irish domains we have used for previous audits here, queried their CAA records, pulled the certificate each one is serving, and checked whether their DNS is signed. The gap between Google’s advice and Irish practice is not close.

TL;DR

• 16 of 100 Irish domains publish any CAA record. 83 of the 98 that served us a certificate have nothing restricting ordinary issuance.
• Zero of 100 use accounturi or validationmethods, the two RFC 8657 parameters Google explicitly asked for. The only CAA parameter present anywhere in the dataset grants an extra capability rather than removing one.
• The 16 that do publish are permissive: a median of five authorised CAs each, up to nine. Exactly one domain authorises a single CA.
• Those parameters are not mandatory for CAs to process until 15 March 2027, and RFC 8657 says not to assume they work before your CA confirms it.
• CAA lives in DNS, and only 5 of 100 of these domains are DNSSEC-signed. Two of the three hijacked ccTLDs have no DS record at the root; the third does, which is the uncomfortable part.

What we measured, and how

For each of 100 Irish domains spanning media, banking, retail, utilities, transport, government, universities, insurance and classifieds, we ran a CAA query at the apex against Cloudflare’s resolver, then re-ran every negative against Google’s and Quad9’s. All 84 negatives held on all three, so this is not a resolver artefact. We fetched the leaf certificate from port 443 with openssl s_client, falling back to the www host. We queried DS records to see which zones are signed, and checked the .ie, .com, .org and .news apexes for CAA too. Two domains, an-post.ie and welfare.ie, returned no address records, so the certificate figures below are out of 98.

That last check matters: RFC 8659 says the CAA search “climbs the DNS name tree from the specified label up to, but not including, the DNS root”. None of those four TLDs publish CAA, so there is no inherited policy to fall back on.

Finding 1: 83 of 98 have no restriction on issuance

Sixteen domains publish a CAA record. Eighty-four publish none, which per RFC 8659 means any CA in any root store may issue for them after a successful validation.

One of the sixteen is a false positive. irishlife.ie publishes exactly one record, 0 issuewild "comodoca.com", and nothing else. RFC 8659 is unambiguous: “Each issuewild Property MUST be ignored when processing a request for an FQDN that is not a Wildcard Domain Name.” The spec works that exact example through and concludes such a record “permits any Issuer to issue for” the base name. The restriction on irishlife.ie and www.irishlife.ie is none at all. Somebody did the work and got nothing for it.

That puts the real figure at 15 domains with an enforceable issue policy, against 83 without.

Finding 2: the records that exist are not restrictive

Google’s word was “restrictive”. The distribution of authorised CAs across the 16 published records runs 0, 1, 2, 3, 4, 5, 5, 5, 5, 6, 6, 6, 7, 7, 9, 9. Median five. Two domains, daft.ie and adverts.ie, authorise nine CA identifiers each, the permissive default set that arrives when a CDN writes your CAA record for you.

We cross-checked each domain’s authorised set against the CA that actually issued the certificate it is serving. All 15 covered their own live issuer, so nobody has locked themselves out. But the surplus is large: across the 15 there are 63 CA authorisations beyond the single CA each domain was observed using, a median of four per domain. Nine CA operators served all 98 certificates, led by DigiCert on 26. Narrowing a nine-CA record to the one you use is a DNS change, not a project.

Exactly one domain gets this right. virginmedia.ie publishes 0 issue "globalsign.com", 0 issuewild ";" and an iodef address. One CA, no wildcards, a reporting channel. That is the record Google is describing, and it appears once in 100.

Finding 3: nobody has done the thing Google actually asked for

Google did not just say “publish CAA”. It said publish CAA “with ACME account bindings”, restricting issuance to specific authorised accounts and validation methods. Those are RFC 8657’s accounturi and validationmethods parameters. The first binds an authorisation to one named account at that CA, so a stranger holding your hijacked DNS cannot order a certificate on their own account. The second restricts which proof mechanisms count, so you can forbid HTTP-based validation outright.

Across 100 Irish domains, accounturi appears zero times and validationmethods appears zero times.

The only CAA parameter present anywhere in the dataset is cansignhttpexchanges=yes, on nine domains, and it has nothing to do with restriction: it authorises the CA to issue certificates capable of signing HTTP Exchanges. The single parameter Irish sites have deployed hands out a capability rather than removing one.

Finding 4: two records that look like policy and are not

boards.ie publishes 0 issuewild ";", which reads as “no wildcard certificates”. It also publishes five permissive issuewild records naming Comodo, DigiCert, Let’s Encrypt, Google and SSL.com. RFC 8659 settles it: “CAA authorizations are additive; thus, the result of specifying both an empty issuer-domain-name and a non-empty issuer-domain-name is the same as specifying just the non-empty issuer-domain-name.” The prohibition is a no-op and five CAs may still issue wildcards. The same record’s iodef value carries a space between scheme and address, mailto: hello@boards.ie, where the RFC specifies a URL.

Six of the 100 publish an iodef address at all, so 94 have no CAA-advertised channel for a CA to report a refused or suspicious request.

Finding 5: the number behind “cached validation state”

Google conceded something important: CAA “can not prevent certificate issuance during an active DNS hijack”. Its value is afterwards. CAs may cache and reuse a completed domain control validation, so an attacker who validated during the hijack can keep minting certificates after you have taken your DNS back, unless a restrictive CAA stops them.

The CA/Browser Forum Baseline Requirements put a number on that window. For certificates issued on or after 15 March 2026 and before 15 March 2027, the maximum domain validation data reuse period is 200 days, dropping to 100 days in March 2027 and 10 days in March 2029. Today, a validation an attacker completed during a hijack is good for most of a year. Worse, the same document lets remote network perspectives skip re-reading CAA records for up to 398 days after an issuance, so a newly restrictive record is not seen everywhere at once.

Finding 6: the mechanism is not contractually required to work yet

Here is the part that should change how you act on Google’s advice. The Baseline Requirements’ effective-date schedule carries an entry at section 4.2.2.1.2, dated 15 March 2027: “CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657.”

Which means today they need not. RFC 8657 is blunt: “Domains configuring CAA records for a CA MUST NOT assume that the restrictions implied by the accounturi and validationmethods parameters are effective in the absence of explicit indication as such from that CA.” A property with an unrecognised accounturi is, per the same RFC, unsatisfiable, so getting it wrong against a CA that does parse it can block your own renewals. Get the support statement out of your CA’s CPS before you rely on it.

Finding 7: CAA is only as trustworthy as the DNS carrying it

CAA records are DNS records. An attacker who can rewrite your authoritative DNS can delete your CAA record as easily as forge an _acme-challenge answer, unless the zone is signed.

Five of our 100 domains publish a DS record: rte.ie, aldi.ie, aviva.ie, carzone.ie and boards.ie. Of the 16 publishing CAA, three are signed. Thirteen publish a policy an attacker in control of their DNS can simply delete.

We also checked the three hijacked namespaces at the root. .gh and .sl have no DS record. .as does, on algorithm 8, and .ie does, on algorithm 13. Signing the TLD did not save .as, because the compromise was of the registry itself, and a compromised registry can re-sign whatever it likes. DNSSEC raises the bar against forgery in transit; it does not defend you against the party holding the keys. Which is exactly why account-bound CAA matters: it moves part of the authorisation decision out of DNS and into an account relationship with your CA.

What to do this week

1. Inventory, then monitor. Every domain you own, including parked names and regional ccTLDs, needs CT monitoring. That advice applies hardest to the portfolio nobody owns internally.
2. Publish CAA at the apex, naming only the CAs you use. One live CA means one authorisation. Set issuewild separately, and remember a ";" alongside permissive values does nothing.
3. Add an iodef address and parse it before shipping. A URL, no spaces, to a mailbox somebody reads.
4. Ask your CA, in writing, whether it processes accounturi and validationmethods today. Deploy them where the answer is yes; diary 15 March 2027 for the rest.
5. Sign the zone. DNSSEC is not sufficient, but it is not optional either once your CAA record is load-bearing.

None of this is expensive. A CAA record is one DNS change. The reason 83 of 98 Irish sites have none is not cost, it is that nobody owns the certificate surface, so the people who could fix it in ten minutes have never been asked.

At REPTILEHAUS we build and run this layer as part of our DevOps and security work: certificate inventories, CT monitoring that pages somebody, CAA and DNSSEC deployed properly rather than pasted from a vendor default, and renewal pipelines that will survive the 47-day certificate lifetime arriving in 2029. If you cannot currently name every CA permitted to issue for your domains, that is the finding. Get in touch and we will audit it with you.

📷 Photo by Georg Bommeli on Unsplash