An expired WHOIS server domain. A forgotten CAA record. A BGP route slipped past a CA’s validation check. These are not hypothetical attack vectors: they are the mechanics behind incidents that have already affected governmental networks, major resolvers, and widely trusted certificate authorities. If your infrastructure team is still treating DNS security as a set-and-forget checkbox, the threat model has moved on without you.

This post works through the concrete controls available today: DNSSEC deployment, CAA record configuration, certificate transparency monitoring, resolver hardening, and what the CA/Browser Forum’s new multi-perspective issuance rules actually change. The goal is a checklist you can act on, not a taxonomy of things that could go wrong.

What the recent incidents actually demonstrate

The .mobi TLD incident, documented by WatchTowr, is the clearest illustration of how fragile the trust chain becomes when an expired domain sits at a critical choke point. The old WHOIS server domain for .mobi (whois.dotmobiregistry.net) expired after the TLD migrated to a new domain. WatchTowr purchased it, stood up a WHOIS server, and within five days received over 2.5 million queries from 135,000 unique systems, including governmental and military organisations. The attack surface was not a vulnerability in any software; it was an administrative gap that persisted because nobody was watching.

The Fina CA incident is a different failure mode. Between February 2024 and August 2025, Croatia’s Fina CA issued twelve unauthorised TLS certificates for Cloudflare’s 1.1.1.1 resolver service. No evidence of active exploitation was found, but the episode illustrates that certificate misissuance can go undetected for months when monitoring is absent. CAs can and do make mistakes; the controls discussed below exist precisely because the trust model assumes they will.

A third pattern, documented by Palo Alto Networks’ Unit 42, is more operationally dangerous: an adversary compromises a domain’s DNS control plane, then runs a legitimate ACME workflow on top of the hijacked control to obtain a valid certificate. The certificate is real, issued by a trusted CA, and will be accepted by every browser. The attack succeeds because domain control validation, at its core, asks only whether you can answer a DNS query or serve a file, not whether you legitimately hold the domain.

DNSSEC: necessary but not sufficient

DNSSEC provides cryptographic authentication of DNS data, authenticated denial of existence, and data integrity. It does not provide availability or confidentiality, and it does not prevent a CA from being deceived by a hijacked control plane if the resolver doing the validation does not enforce DNSSEC. That distinction matters for how you scope the control.

Deployment remains thin. Verisign data puts DNSSEC adoption at roughly 5% of .net second-level domains and around 4% in .com. End-to-end validation rates for EU countries (the share of queries that are actually cryptographically verified end-to-end, not just signed) are lower still: Germany sits at approximately 0.63%, France at 0.59%, the Netherlands at 0.51%, Spain at 0.35%. Signing rates are considerably higher than validation rates, which means many operators have signed their zones but are not enforcing validation on the resolvers their workloads use. Signing without enforced validation is incomplete.

The deployment checklist for DNSSEC is straightforward in principle:

  • Sign every authoritative zone you control, including subdomains that delegate to third-party providers. Verify the DS record is correctly published in the parent zone.
  • Configure your recursive resolvers to enforce DNSSEC validation, not merely to request it. A resolver that requests DNSSEC signatures but does not verify them offers no protection.
  • Monitor key rollover schedules. A misconfigured or missed key rollover will make your zone unresolvable for validating resolvers; automate alerts before the rollover deadline.
  • Audit third-party DNS delegations. A signed parent zone with an unsigned or improperly signed subdomain delegation breaks the chain of trust at that point.

CAA records: restrict who can issue, and how

CAA records (formally defined in RFC 8659, which superseded RFC 6844 in 2019) let you publish a DNS-level policy restricting which certificate authorities are permitted to issue certificates for your domain. Since CA/Browser Forum Ballot 187 passed in 2017, CAs are required to check CAA records before issuing any certificate. An absent CAA record means every public CA is permitted to issue; a present but misconfigured one can be worse than none at all.

A CAA record that names the right CA but omits wildcard restrictions, or that lacks an iodef reporting address, is a policy with no enforcement and no visibility. You will not know when someone tries to violate it.

The three core CAA tags are issue (permits issuance of regular certificates), issuewild (permits wildcard issuance, and must be set separately), and iodef (specifies a reporting address for unauthorised issuance attempts). RFC 8657 adds two parameters worth deploying: accounturi, which pins issuance to a specific ACME account, and validationmethods, which restricts which domain control validation methods are acceptable. Together these parameters address the attack pattern Unit 42 documented, where an adversary uses a hijacked control plane to pass a legitimate ACME challenge.

A practical minimum configuration for a domain using a single CA looks like this:

  • Set issue to your chosen CA only. Set issuewild explicitly, even if wildcards are not currently in use, to prevent unintended future issuance.
  • Set iodef to a monitored address. Most teams do not bother; the reports are genuinely useful.
  • If you use ACME, add accounturi to bind issuance to your account identifier. This prevents another account at the same CA from issuing against your domain.
  • Review CAA records for every subdomain that has its own delegation. A subdomain with no CAA record inherits the parent’s policy, but a subdomain with its own zone does not.

Certificate transparency monitoring

Certificate Transparency (standardised in RFC 6962, with RFC 9162 describing a version 2.0 architecture, currently classified as Experimental) creates a publicly auditable, append-only log of every TLS certificate issued by participating CAs. Browsers require certificates to appear in CT logs before trusting them. This means every certificate issued for your domain, including any fraudulently issued ones, will appear in a log you can query.

Monitoring is the part most teams skip. Useful tools include crt.sh (Sectigo’s public CT search), Cloudflare’s MerkleTown, and SSLMate’s Cert Spotter, which provides real-time alerts when a new certificate appears for a monitored domain. At minimum, configure alerts for any certificate issued for your apex domain and its immediate subdomains. Alert latency matters: the window between misissuance and detection is the window in which an attacker can operate.

Multi-perspective issuance corroboration: what SC-067 changes

CA/Browser Forum Ballot SC-067, approved in August 2024, introduced Multi-Perspective Issuance Corroboration (MPIC). The requirement, now in full enforcement since September 2025, mandates that domain control validation and CAA checks be performed from at least two independent network perspectives separated by a minimum of 500 km. The perspective count scales further: three perspectives by March 2026, four by June 2026, five by December 2026.

The explicit purpose of MPIC is to make a localised BGP hijack insufficient to fool CA domain validation. A BGP route hijack that redirects traffic from one network vantage point will not simultaneously redirect traffic from perspectives in geographically separated networks. This directly addresses the BGP route hijacking vector that has been used to intercept domain validation challenges. MPIC does not eliminate the risk, but it substantially raises the cost and coordination required for a successful attack.

Resolver hardening and the sovereign DNS layer

The resolver your workloads use for outbound DNS queries is part of your attack surface. A resolver that does not enforce DNSSEC validation, that does not filter known malicious domains, or that routes queries through infrastructure outside your jurisdiction weakens every other control in this list.

DNS4EU, launched in June 2025 and managed by a consortium from ten EU member states led by Czech cybersecurity company Whalebone, provides a privacy-compliant EU resolver service as an alternative to non-EU providers. It was developed in direct response to European Commission concerns about EU dependence on a small number of non-EU DNS resolvers.

For teams running workloads at AMS1, our Amsterdam site’s dense peering at AMS-IX gives us direct, low-latency paths to EU resolver infrastructure and to the major transit providers whose routing tables matter when MPIC checks are being performed. We operate our own recursive resolvers with DNSSEC validation enforced, which means the DNS layer your workloads sit on is not an opaque service managed by a hyperscaler’s shared infrastructure. That matters when the attack vector is the resolver itself.

The checklist

  1. Sign your zones and enforce validation. Signing without enforced validation on your resolvers is incomplete. Audit both.
  2. Set CAA records for every domain you own, including subdomains with independent delegations. Include issuewild, iodef, and accounturi if you use ACME.
  3. Monitor certificate transparency logs in real time. Use Cert Spotter or an equivalent for immediate alerts. Do not rely on periodic manual checks.
  4. Audit third-party DNS delegations. Expired domains in your DNS chain, whether WHOIS servers, nameserver hostnames, or delegated subdomains, are an attacker’s easiest entry point.
  5. Verify your CA enforces MPIC. As of September 2025 this is mandatory, but confirming your CA’s implementation is reasonable due diligence.
  6. Harden your resolver configuration. Enforce DNSSEC validation, restrict outbound DNS to controlled resolvers, and consider whether EU-sovereign resolver infrastructure fits your threat model.
  7. Set iodef and read the reports. Unauthorised issuance attempts against your CAA policy are intelligence. Treat them as such.

None of these controls is exotic. Most are configuration changes your team can complete in a day. The gap between knowing about them and running them in production is where the incidents happen.