Ballot SC-085v2: certificate authorities now verify DNSSEC before issuing a TLS certificate

By CaptainDNS
Published on March 19, 2026

Diagram showing the link between DNSSEC, certificate authorities, and TLS certificate issuance after Ballot SC-085v2

TL;DR

Since March 15, 2026, CAs must verify DNSSEC during domain control validation (DCV) before issuing a TLS certificate (Ballot SC-085v2)
If your domain publishes DNSSEC and the chain of trust is broken (BOGUS), no certificate will be issued until the problem is resolved
SC-085v2 complements MPIC (SC-067): together, they protect DCV against BGP hijacking and DNS spoofing
SC-081v3 also reduces TLS certificate lifetimes to 47 days by 2029: read our complete SC-081v3 guide

Since March 15, 2026, renewing a TLS certificate can fail if your domain publishes DNSSEC with an invalid chain of trust. This is not a bug from your certificate provider: Ballot SC-085v2 from the CA/Browser Forum now requires certificate authorities (CAs) to validate DNSSEC responses during domain control verification.

This change affects all domains that publish DNSSEC. If your DNS zone is properly signed, you benefit from enhanced protection against BGP hijacking and DNS spoofing attacks during certificate issuance. But if your DNSSEC configuration is broken (stale DS record, expired signatures, obsolete algorithm), the CA will refuse to issue the certificate.

This article covers the problem SC-085v2 solves, how it works technically, how it interacts with MPIC (SC-067), the operational impact depending on your situation, and a practical guide to verifying and fixing your configuration before your next renewal.

Is your DNSSEC ready for the new CA requirements?

Check with DNSSEC Checker Test DANE TLSA

The problem: DCV relies on unauthenticated DNS

Domain control validation (DCV) is the process by which a CA verifies that the certificate requester actually controls the target domain. This process relies on DNS, a protocol designed without response authentication.

How domain control validation (DCV) works

Before issuing a TLS certificate, the CA must verify that you control the domain for which you are requesting the certificate. Three validation methods are commonly used:

DNS-01: the CA requests that you publish a specific TXT record under _acme-challenge.captaindns.com. It then queries DNS to verify that the record is present and contains the expected value. This is the most common method used by automated systems.
HTTP-01: the CA requests that you place a file at a specific URL on the domain's web server (for example http://captaindns.com/.well-known/acme-challenge/TOKEN). It then verifies that the file is accessible and contains the correct value.
Email: the CA sends a validation email to an administrative address for the domain (admin@, postmaster@, etc.) and waits for confirmation.

The ACME protocol (Automatic Certificate Management Environment, RFC 8555) automates these exchanges. It standardizes the dialogue between the client (certbot, acme.sh, etc.) and the CA. The DNS-01 method is the most common in automated environments because it supports wildcard certificate validation and does not require exposing a web server.

In all cases, the CA performs DNS queries: to resolve the validation TXT (DNS-01), to resolve the web server's IP address (HTTP-01), or to resolve the domain's MX (email). DNS is therefore the foundation of DCV.

DNS without DNSSEC is forgeable

The DNS protocol, designed in 1983, includes no response authentication. A DNS resolver cannot distinguish a legitimate response from a forged one. This structural weakness opens the door to several attack vectors:

Cache poisoning. An attacker injects false responses into a DNS resolver's cache. Subsequent queries for the same domain return the attacker's IP address instead of the legitimate server's.

BGP hijacking. An attacker announces fraudulent BGP routes to redirect network traffic to their own servers. Combined with a DCV request, they can intercept the validation and obtain a certificate for a domain they do not control.

Man-in-the-middle attack on the network. An attacker positioned on the network path between the CA and the authoritative DNS server modifies DNS responses in transit.

These attacks are not theoretical. Several major incidents have demonstrated their feasibility:

KLAYswap (February 2022): attackers hijacked BGP traffic from a Korean domain registry, obtained a fraudulent TLS certificate via BGP hijack, and stole the equivalent of $2 million in cryptocurrency through a fake site.
Celer Bridge (August 2022): a similar attack exploited BGP hijacking to redirect DNS traffic from a DeFi bridge. The attackers obtained a fraudulent certificate and stole $235,000.
MyEtherWallet (April 2018): attackers hijacked Amazon Route 53 BGP prefixes to redirect DNS queries to a fraudulent server, obtained a TLS certificate, and intercepted user credentials from the crypto wallet.

Academic research has formalized these risks. The study "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018, Princeton University) demonstrated that an attacker could obtain fraudulent TLS certificates from the five largest CAs by hijacking DNS queries via BGP, with a success rate exceeding 60% in their experiments.

The conclusion is clear: as long as DCV relies on unauthenticated DNS, TLS certificate issuance remains vulnerable.

Comparison of the DCV flow with and without DNSSEC validation by the CA

Ballot SC-085v2: what changes in practice

Ballot SC-085v2, titled "Require Validation of DNSSEC when Present for CAA and DCV Lookups," was proposed by Clint Wilson (Apple) and endorsed by the Chrome Root Program (Google), Fastly, and HARICA. It amends the Baseline Requirements (BR) of the CA/Browser Forum, the normative document that all publicly trusted CAs must comply with.

The vote

The vote concluded with unanimous adoption on the browser side and near-unanimous on the CA side:

25 votes in favor (including DigiCert, Sectigo, GlobalSign, Entrust, HARICA, SwissSign)
0 votes against
1 abstention (Entrust, which supported the technical merits but abstained over timing concerns)
Browser side: Apple and Mozilla voted in favor

What the ballot requires

Since March 15, 2026, CAs must perform full DNSSEC validation on DNS queries used for:

Domain control validation (DCV): all DNS queries related to control verification (TXT for DNS-01, A/AAAA for HTTP-01, MX for email)
CAA (Certification Authority Authorization) checks: CAA records determine which CAs are authorized to issue certificates for a domain

DNSSEC validation must be performed up to the IANA trust anchor (the root KSK) on the Primary Network Perspective, i.e., the CA's main resolution point. The requirement covers the full chain: from the DNS root to the target domain, every RRSIG signature must be verified.

What the ballot does not change

Domains without DNSSEC are not affected. If your domain does not publish a DS record at the TLD, the CA continues DCV exactly as before. SC-085v2 does not make DNSSEC mandatory for obtaining a certificate. It simply requires CAs to respect DNSSEC when it is deployed.

Deployment timeline

The major CAs anticipated the deadline:

DigiCert: DNSSEC validation active since March 3, 2026, with the dns_sec_validation_error error code for failing domains
Sectigo: deployment completed March 5, 2026
Official deadline: March 15, 2026, all CAs must be compliant

The exception for email validation (SC-094v2)

Ballot SC-094v2, adopted separately, grants a temporary exception for email-based DCV. Email validation methods (BR sections 3.2.2.4.2 and 3.2.2.4.4) are being phased out and receive additional time before DNSSEC validation is enforced on them. This exception acknowledges that these legacy methods will be gradually phased out.

How DNSSEC secures certificate issuance

DNSSEC adds a cryptographic authentication layer to DNS. Each DNS record is accompanied by a digital signature (RRSIG) verifiable by the resolver. Trust propagates from the IANA trust anchor (the root KSK) down to the target domain via a chain of DS records and DNSKEYs. For a detailed explanation of this mechanism, see our guide on the DNSSEC chain of trust.

Practical application to DCV

Let's take a concrete scenario. An automated system requests a certificate for captaindns.com via ACME (DNS-01). The ACME client publishes a TXT record under _acme-challenge.captaindns.com with a unique token.

The CA queries DNS to retrieve this TXT record. With SC-085v2, the CA's resolver now performs full DNSSEC validation:

It verifies that the captaindns.com zone publishes a DS record at the .com TLD
It retrieves the DNSKEYs for the captaindns.com zone and verifies that the DS matches the KSK hash
It verifies that the RRSIG for the _acme-challenge.captaindns.com TXT is signed by a ZSK whose DNSKEY is itself signed by the KSK
It walks back up the chain to the IANA root to validate every link

If all signatures are valid, the resolver returns the response with the AD (Authenticated Data) flag. The CA can then proceed with DCV with the guarantee that the DNS response has not been tampered with.

The three scenarios after SC-085v2

Scenario 1: domain without DNSSEC. Your domain does not publish a DS record at the TLD. The CA's resolver notes the absence of DNSSEC and proceeds with standard DCV, without cryptographic validation. No change compared to before SC-085v2.

Scenario 2: valid DNSSEC (SECURE). Your domain publishes DNSSEC and the chain of trust is intact. The resolver validates every signature, obtains the AD flag, and the CA proceeds with DCV with the certainty that the response is authentic. This is the ideal behavior: you benefit from full protection against DNS spoofing during certificate issuance.

Scenario 3: broken DNSSEC (BOGUS). Your domain publishes a DS record at the TLD, but validation fails. The DS does not match the DNSKEY, the RRSIGs are expired, or an unsupported algorithm is used. The resolver marks the response as BOGUS and returns a SERVFAIL. The CA cannot obtain a valid DNS response and refuses to issue the certificate.

RFC 4035 section 5 defines the validation algorithm that resolvers (and therefore CAs) must implement. CAs compliant with SC-085v2 apply this algorithm on their Primary Network Perspective for all DCV and CAA queries.

MPIC and DNSSEC: defense in depth

SC-085v2 does not operate in isolation. It is part of a defense-in-depth strategy initiated by the CA/Browser Forum, starting with MPIC (Multi-Perspective Issuance Corroboration).

MPIC: network-level protection

Ballot SC-067v3, effective since March 2025, requires CAs to validate DCV from at least two geographically separated network perspectives (minimum 500 km). In practice, when you request a certificate, the CA runs DNS verification from multiple points of presence around the world.

The goal: counter localized BGP attacks. If an attacker hijacks BGP traffic in one region, network perspectives in other regions will receive the legitimate DNS response. The CA detects the inconsistency and refuses to issue the certificate.

DNSSEC: protocol-level protection

SC-085v2 adds a second layer of protection, this time at the DNS protocol level itself. DNSSEC guarantees DNS response authenticity through cryptographic signatures. Even if the attacker controls the network path, they cannot forge a valid DNS response without possessing the zone's private keys.

Why both are necessary

MPIC and DNSSEC address different attack vectors and complement each other:

MPIC alone does not protect if the authoritative DNS server is compromised or if the attacker has globally poisoned DNS caches. All network perspectives would receive the same false response.
DNSSEC alone does not protect if the CA's resolver does not validate DNSSEC (which is no longer possible with SC-085v2 when DNSSEC is published), or if the attack targets the network path without modifying DNS responses.
Together: MPIC covers the network vector (localized BGP hijacking), DNSSEC covers the DNS vector (spoofing, cache poisoning). An attacker would need to simultaneously compromise the DNSSEC chain and hijack traffic from all the CA's network perspectives to obtain a fraudulent certificate.

CA/Browser Forum ballot timeline: SC-067 MPIC, SC-085v2 DNSSEC, SC-081 certificate lifetime reduction

Operational impact: who is affected?

The impact of SC-085v2 depends directly on your DNSSEC situation. Here are the four typical profiles and their consequences.

DNSSEC active and properly configured

If your domain publishes DNSSEC with an intact chain of trust, SC-085v2 changes nothing in your operational workflow. Your certificate renewals continue to work normally. The only difference: the CA now cryptographically validates DNS responses, which strengthens issuance security. You are protected against BGP hijacking and DNS spoofing attacks targeting DCV.

This is the ideal scenario. Your investment in DNSSEC pays off twice: standard DNS protection and certificate issuance protection.

DNSSEC active but misconfigured

This is the risk scenario. Your domain publishes a DS record at the TLD, indicating to resolvers that the zone is signed. But the DNSSEC configuration is invalid. Several common causes:

Stale DS record after a DNS migration. You switched DNS providers, the new provider generated new DNSSEC keys, but the DS record at the registrar still points to the old keys. The chain is broken.
Expired RRSIGs. DNSSEC signatures have a limited lifetime (typically 7 to 30 days). If the automatic re-signing process fails silently, the RRSIGs expire and the zone becomes BOGUS.
Incorrect KSK/ZSK rotation. A poorly sequenced key rotation (new key published before DS propagation, or old DS removed before new key propagation) temporarily breaks the chain.
Unsupported algorithm. Some older algorithms (RSA-SHA1, DSA) are deprecated. If your zone uses an algorithm that the CA's resolver does not support, validation fails.

Before SC-085v2, a broken DNSSEC configuration caused SERVFAILs for validating resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) but did not prevent certificate issuance, because CA resolvers did not systematically validate DNSSEC. Now, a BOGUS DNSSEC status blocks DCV and the certificate is denied.

No DNSSEC deployed

If your domain does not publish a DS record at the TLD, SC-085v2 has no immediate impact. The CA notes the absence of DNSSEC and proceeds with standard DCV. Your renewals continue to work exactly as before.

However, DNSSEC adoption is becoming increasingly important. SC-085v2 creates a strong incentive: domains with valid DNSSEC benefit from DCV protected against spoofing. Domains without DNSSEC remain vulnerable to the same attacks described in the previous section. The Microsoft 365 migration to the mx.microsoft domain with automatic DNSSEC, the arrival of DMARCbis which recommends DNSSEC for MX record protection, and SC-085v2 all converge toward an ecosystem where DNSSEC becomes the expected norm.

Automated certificates via ACME

This profile deserves special attention. The DNS-01 method is widely used by ACME systems to validate certificates, particularly for wildcard certificates. If your infrastructure automates renewal via certbot, acme.sh, or a Kubernetes operator like cert-manager, the flow is entirely non-interactive.

The risk: a broken DNSSEC causes a silent failure. The ACME renewal fails, the certificate expires, and your site becomes unreachable over HTTPS. No human is in the loop to detect the problem before expiration.

DigiCert introduced the dns_sec_validation_error error code to specifically signal a DNSSEC validation failure during DCV. If you receive this error, the problem is in your DNSSEC configuration, not in your validation record.

DNSSEC adoption: state of play in March 2026

Understanding the current adoption level helps measure the scope of the change introduced by SC-085v2.

Global validation

Approximately 35% of global DNS queries pass through resolvers that validate DNSSEC. This figure reflects resolver-side adoption: the major public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) all validate DNSSEC. ISP resolvers are more heterogeneous, but the trend is upward.

Signing rates by TLD

DNSSEC adoption by domains (zone-side, not resolver-side) varies considerably across TLDs:

.nl (Netherlands): approximately 60% of domains signed. Global leader thanks to active promotion by SIDN (the .nl registry).
Nordic TLDs (.se, .dk, .no): over 50% adoption, driven by proactive registries.
.com: approximately 4 to 5% of domains signed. The volume is enormous in absolute terms, but the percentage remains low.
92% of TLDs have a DS record in the root zone, meaning the signing infrastructure exists at the TLD level.

The asymmetry between infrastructure and adoption

DNSSEC validation infrastructure is widely deployed. Resolvers are ready. TLDs are signed. But individual zone signing remains a minority practice. This asymmetry is explained by the perceived complexity of DNSSEC deployment and the lack, until now, of visible consequences for unsigned domains.

SC-085v2 changes this dynamic. For the first time, there is a concrete consequence for publishing DNSSEC with an invalid configuration. And there is a measurable benefit to publishing DNSSEC correctly: DCV protection.

The domino effect is predictable. SC-085v2, combined with the Microsoft 365 migration to mx.microsoft with automatic DNSSEC and DMARCbis recommendations, will accelerate DNSSEC adoption in the coming quarters.

Practical guide: verify and fix your DNSSEC configuration

Before your next certificate renewal, verify that your DNSSEC configuration is intact. Here are the essential commands and steps.

Quick check with dig

Check the AD (Authenticated Data) flag:

dig +dnssec SOA captaindns.com

In the flags: section, look for ad. Its presence means the resolver successfully validated the DNSSEC chain. Its absence indicates either that DNSSEC is not deployed or that validation failed.

Check DS records at the TLD:

dig DS captaindns.com +short

This command returns the DS record(s) published by the registrar at the TLD. If the response is empty, your domain does not publish DNSSEC. If DS records are present, verify that they match the current keys for your zone.

Check DNSKEY records:

dig DNSKEY captaindns.com +short

You should see at least two keys: one with flag 256 (ZSK) and one with flag 257 (KSK). The hash of the KSK (flag 257) must match the DS record published at the TLD.

Distinguish a DNSSEC problem from another DNS issue:

dig captaindns.com +cd

The +cd (Checking Disabled) flag disables DNSSEC validation. If the query works with +cd but fails without it (SERVFAIL), the problem is DNSSEC.

What to do if DNSSEC is broken

If your checks reveal a problem, here are the corrective actions in order of priority:

Check the DS record at your registrar. Log into your registrar's interface and compare the published DS record with the DNSKEY (flag 257) of your zone. If you migrated DNS providers, the DS must point to the new provider's KSK.

Check the RRSIGs in the zone. Signatures have an expiration date. If your DNS provider has a re-signing issue, the RRSIGs may be expired. Contact your DNS provider or check the signing logs if you manage DNSSEC internally.

Check the algorithm. The RSA-SHA1 and DSA algorithms are deprecated. Prefer ECDSAP256SHA256 (algorithm 13) or ECDSAP384SHA384 (algorithm 14).

For a detailed diagnostic of SERVFAIL errors related to DNSSEC, see our dedicated guide: resolving SERVFAIL after DNSSEC. If you need to enable DNSSEC for the first time, follow our step-by-step DNSSEC activation guide.

Certificate renewal checklist

Before each certificate renewal on a domain with DNSSEC:

The DS record at the registrar matches the zone's active KSK
RRSIGs are not expired (check inception and expiration with dig +dnssec)
The algorithm used is supported (ECDSAP256SHA256 recommended)
The resolver returns the AD flag for your domain
DNSSEC monitoring is in place and sends alerts on chain breaks
An ACME dry-run was successfully executed on the target domain

SC-081 and the acceleration of renewals

Ballot SC-081, adopted by the CA/Browser Forum, progressively reduces the maximum TLS certificate lifetime:

Effective date	Maximum lifetime
March 2026	200 days
March 2027	100 days
March 2029	47 days

This reduction has a direct impact on the criticality of SC-085v2. The shorter the certificate lifetime, the more frequent the renewals. And the more frequent the renewals, the faster a broken DNSSEC will be detected, but also the more disruptive it will be.

With 200-day certificates, a DNSSEC problem lasting a week delays a renewal. With 47-day certificates, a DNSSEC problem lasting a few days can cause the certificate to expire before the renewal succeeds. The margin for error shrinks drastically.

At 47 days, ACME automation becomes essential. No organization can manually manage renewals every six weeks across a fleet of domains. And an automated ACME pipeline that silently fails due to broken DNSSEC is a major incident scenario.

The recommendation is clear: set up continuous DNSSEC monitoring on all your domains with TLS certificates. Configure alerts on RRSIG expiration (at least 7 days before expiration) and on DS/DNSKEY correspondence. Integrate DNSSEC verification into your ACME renewal pipeline, before the certificate request.

Action plan: prepare your infrastructure

Check the DNSSEC status of all your domains with the CaptainDNS DNSSEC Checker
Fix broken chains: missing DS record, expired signature, incompatible algorithm
Audit active certificates: list DNSSEC domains with certificates due for renewal within 90 days
Set up monitoring: alerts on RRSIG expiration and certificate expiration
Test renewal: run an ACME dry-run on DNSSEC domains
Document: add DNSSEC verification to your renewal runbook

FAQ

Does Ballot SC-085v2 make DNSSEC mandatory to obtain a TLS certificate?

No. SC-085v2 requires CAs to validate DNSSEC when it is present, but does not make DNSSEC mandatory. If your domain does not publish a DS record at the TLD, the CA proceeds with standard DCV without DNSSEC validation. You can obtain a TLS certificate without DNSSEC, exactly as before.

What happens if my DNSSEC is broken during automatic renewal?

The renewal fails. The CA returns an error such as dns_sec_validation_error (at DigiCert) or a SERVFAIL. The ACME client cannot complete DNS-01 validation and the certificate is not renewed. If the problem persists until the current certificate expires, your site becomes unreachable over HTTPS. This is why DNSSEC monitoring with alerts is essential.

Which CAs are affected by SC-085v2?

All publicly trusted CAs (i.e., those whose root certificate is included in browser trust stores). This includes DigiCert, Sectigo, Let's Encrypt, GlobalSign, Entrust, HARICA, SwissSign, and all other CAs compliant with the CA/Browser Forum Baseline Requirements. Private CAs (internal to an organization) are not affected.

Did Let's Encrypt already validate DNSSEC?

Let's Encrypt already used DNSSEC-validating resolvers (Unbound) in its infrastructure. In practice, a domain with BOGUS DNSSEC could already fail validation at Let's Encrypt. SC-085v2 formalizes this requirement in the Baseline Requirements and extends it to all CAs, not just those that chose to validate DNSSEC.

What is the difference between MPIC (SC-067) and SC-085v2?

MPIC (SC-067) protects DCV at the network level by verifying from multiple geographic locations. It detects localized BGP attacks. SC-085v2 protects DCV at the DNS level by verifying DNSSEC signatures. It detects forged DNS responses. The two are complementary: MPIC covers the BGP vector, DNSSEC covers the DNS vector.

Will my current certificate be revoked if DNSSEC breaks after issuance?

No. SC-085v2 only applies to validation at the time of issuance. An already-issued certificate remains valid until its expiration, even if DNSSEC breaks after issuance. However, the next renewal will fail as long as DNSSEC is BOGUS.

How do I know if my domain publishes DNSSEC?

Run dig DS captaindns.com +short (replace with your domain). If the command returns one or more DS records, your domain publishes DNSSEC. If the response is empty, DNSSEC is not enabled. You can also use the CaptainDNS DNSSEC Checker for a complete diagnostic including chain of trust validation.

Does SC-085v2 affect wildcard certificates?

Yes. Wildcard certificates are validated via DNS-01 (the only ACME method compatible with wildcards). The CA queries DNS to verify the _acme-challenge TXT and applies DNSSEC validation on this query. If DNSSEC is BOGUS for your domain, the wildcard certificate will not be issued.

What is the connection with Ballot SC-081 on certificate lifetime reduction?

SC-081 reduces the maximum TLS certificate lifetime (200 days in 2026, 100 days in 2027, 47 days in 2029). Shorter certificates mean more frequent renewals. Each renewal triggers a DCV, and each DCV now includes DNSSEC validation (SC-085v2). A broken DNSSEC therefore blocks renewals more often, with less margin before expiration.

Do I need to enable DNSSEC to benefit from SC-085v2 protection?

Yes. SC-085v2 only protects domains that publish DNSSEC. Without DNSSEC, the CA cannot verify the authenticity of DNS responses and DCV remains vulnerable to spoofing. Enabling DNSSEC on your domain is the only way to benefit from this enhanced protection during certificate issuance.

Glossary

CA (Certificate Authority): a trusted entity that issues TLS certificates. Public CAs are included in browser trust stores and are subject to the CA/Browser Forum Baseline Requirements.
DCV (Domain Control Validation): the process by which a CA verifies that the certificate requester actually controls the domain. Common methods: DNS-01, HTTP-01, email.
CA/Browser Forum: a consortium of CAs and browser vendors. It defines the Baseline Requirements, the normative framework that all public CAs must comply with.
MPIC (Multi-Perspective Issuance Corroboration): a mechanism mandated by Ballot SC-067, requiring CAs to validate DCV from at least two geographically distant network perspectives to counter BGP hijacking.
BOGUS: the internal state of a DNSSEC resolver when cryptographic validation fails. A BOGUS domain causes a SERVFAIL for the client. After SC-085v2, a BOGUS domain also blocks certificate issuance.
ACME (Automatic Certificate Management Environment): a standardized protocol (RFC 8555) for automating TLS certificate issuance and renewal. Used by Let's Encrypt, certbot, acme.sh, and cert-manager.
Baseline Requirements (BR): the normative document of the CA/Browser Forum defining the minimum requirements for TLS certificate issuance by public CAs. SC-085v2 amends the BR to mandate DNSSEC validation.