Website security is not only dependent on HTTPS encryption. There’s a certificate validation process that takes place behind every legitimate TLS certificate that aims to verify that the person or company requesting the certificate actually has control over that domain.
This validation process almost entirely relies on the domain name system, which means that weaknesses in the DNS can impact the security of issuing certificates.
In response to this vulnerability, the CA/Browser Forum has introduced Ballot SC-085v2, which states that publicly trusted certificate authorities (CAs) need to carry out DNSSEC validation during necessary CAA and DCV DNS lookups if DNSSEC is in use.
This requirement came into force on March 15, 2026. It is worth mentioning that SC-085v2 does not require every website owner to enable DNSSEC, but rather obliges CAs to validate DNSSEC, when DNSSEC is available on the domain.
What is SC-085v2?
SC-085v2 is a CA/Browser Forum ballot named “Require Validation of DNSSEC for CAA and DCV Lookups.” It adds a new layer to the baseline requirements set out for the issuance of certificates by certificate authorities.
The idea behind this is to make the process of obtaining certificates less vulnerable to DNS spoofing, cache poisoning, and other network-based attacks.
According to the new requirement, certificate authorities must ensure DNSSEC validation for CAA inquiries and domain control verification queries when DNSSEC is supported.
The ballot was accepted on June 18, 2025, and came into force on March 15, 2026. The new requirements will apply to publicly trusted TLS certificates, including DV, OV, and EV.
Why Is DNSSEC Important for TLS Certificates?
Obtaining a TLS certificate means that the certificate authority has to ensure that the applicant has control over the domain, which is known as the Domain Control Verification (DCV) process.
In fact, one of the most widely used strategies involves DNS-based validation which may also include the placement of a certain TXT record under such a domain as: _acme-challenge.example.com
The CA makes a request to DNS to check if it got the right record.
The issue is that regular DNS doesn’t know how to verify the records it receives. The hacker can interfere in the flow of data sent through DNS and be capable of providing false information to CA.
This means that issuing fraudulent certificates is possible.
DNSSEC which stands for Domain Name System Security Extensions, solves this issue by using cryptographic signatures in DNS records. It allows the validating resolver to confirm that the DNS data is original and hasn’t been altered while in transit.
Also Read: ACME Challenges for Domain Validation: Which is Best?
What’s New In SC-085v2?
Before SC-085v2 came into existence, the publicly trusted certificate authorities were responsible for making the CAA checks whenever it was applicable, so they used DNS during many DCV methods. However, CA/Browser Forum hasn’t made DNSSEC checking compulsory for the DNS responses.
When DNSSEC is deployed for a domain, CAs must validate DNSSEC for:
- CAA lookups
- DNS-based DCV lookups
- Other DNS queries associated with DCV, depending on the validation method
Experts indicate that this requirement applies to TLS certificates, which mandates DNSSEC verification from the perspective of the CA’s primary network. This is to avoid the possibility that a CA relies on an unsigned or uncorrected DNS response in making its certificate-issuance decisions.
What are CAA Records?
CAA means Certification Authority Authorization. A CAA record allows a domain owner to determine which CAs can issue certificates for their domain.
For instance, a CAA record may grant authorization to one CA.
In this way, extra protection is provided. In case an unauthorized CA receives a request for a domain’s certificate, application of the CAA policy can prevent the issuance of the certificate.
The only problem with applicants is that CAA records are kept in the DNS system, and if attackers manipulate DNS responses that CAs receive, they may hide/modify/delete information about CAA records.
Thus, SC-085v2 makes DNSSEC validation of the required CAA lookups necessary if DNSSEC exists. This makes CAA verification more reliable, as CAs can check the DNS response using cryptography.
How DNSSEC Protects Domain Validation?
With DNS Security Extensions (DNSSEC), the chain of trust from the root of the DNS system to the target domain is established.
The information contained in the DNS records is encrypted by the DNSSEC keys. The certificate authority’s validating resolver examines the encrypted files to verify that every step in the chain is valid.
Let us imagine a situation where a specific organization requires a certificate using the DNS-01 validation mechanism.
In such a case, the organization first publishes the corresponding TXT record required to check its ownership. The certificate authority queries the DNS system to get the data.
According to SC-085v2, in the case of a domain that utilizes DNSSEC technology, the CA validator verifies the chain of trust established for the domain before finding the received data trustworthy.
If the validation of the DNSSEC chain is successful, then the received response is considered authenticated.
In terms of the most unpleasant situations when the DNSSEC validation fails, SC-085v2 offers a safeguard against outright trust of the received information.
What Happens If DNSSEC Is Misconfigured?
The biggest operational risk is not DNSSEC itself but broken DNSSEC.
A domain can publish DNSSEC and still have an invalid configuration. Common problems include:
- Missing DS records at the registrar
- Expired DNSSEC signatures
- Incorrect DNSKEY or DS records
- Problems during DNS provider migration
- Incorrect key rotation
- Unsupported or obsolete DNSSEC algorithms
- Unsigned delegations
- Incorrect timing or TTL configuration
When DNSSEC is turned on, but the trust chain is broken, any validating resolver can label the domain as BOGUS. According to SC-085v2, this will stop the CA from completing the certificate validation prompt, so it will not be able to issue or renew the certificate.
This is especially important for those companies that work with automatic certificate renewals.
Does SC-085v2 Make DNSSEC Mandatory?
No. This is the main point for the owners of the websites.
SC-085v2 does not say that organizations must turn DNSSEC on just to get a TLS certificate. If a domain does not apply DNSSEC, the CA proceeds with the current certificate-validation procedure without DNSSEC validation.
Moreover, organizations that already use DNSSEC are obliged to make sure it has been set up properly.
It clarifies that organizations that do not apply DNSSEC are not obliged to turn it on due to these new requirements.
However, unique properties of DNSSEC give an organization additional security features against DNS-based certificate validation manipulation.
Impact on Automated Certificate Renewal
SC-085v2 matters in the context of automated environments.
ACME-related systems and tools are increasingly used by modern companies for semi-automatic or fully automatic certificate issuance and renewal purposes. DNS-01 validation has become the most widely used mechanism for allowing automation, especially in wildcard certificate cases.
If properly configured, DNSSEC will ensure that the certificate issuance/renewal process continues to work.
Unfortunately, in the case of DNSSEC configuration becoming invalid, the automated certificate renewal may fail. The current TLS certificate may still be in effect until it expires but not be replaced by any newly issued certificate.
Thus, organizations need to be aware of the condition of both DNSSEC and certificate expirations.
CheapSSLWEB states that faulty DNSSEC can lead to failures of certificate issuance/renewal and may cause service interruption in case of the use of automated certificate renewal.
SC-085v2 and Multi-Perspective Validation
SC-085v2 is part of a wider initiative for enhancing the security of digital certificates issued.
Multi-Perspective Issuance Corroboration (MPIC) is another project by the CA/Browser Forum which requires CAs to validate a domain name from various locations. This will also help to prevent types of local routing attacks such as BGP hijacking.
Both DNSSEC and MPIC solve different problems.
MPIC tackles the issue at the network perspective, while DNSSEC addresses it at the cryptographic level.
In combination, MPIC and DNSSEC can counteract any attempts to sabotage the certificate validation process.
What Organizations Should Do?
Organizations that have deployed DNSSEC should check their configuration in advance rather than waiting for a certificate to expire.
A practical checklist includes:
- Identify domains using DNSSEC.
- Check DS and DNSKEY records for consistency.
- Verify that DNSSEC signatures have not expired
- Review DNSSEC key-rotation procedures
- Check CAA records and confirm that authorized CAs are correct.
- Test automated certificate renewal before certificates expire.
- Monitor DNSSEC continuously for chain-of-trust failures.
- Set alerts for certificate expiration and DNSSEC problems.
- Test DNSSEC using diagnostic tools such as DNSViz or the Verisign DNSSEC Debugger.
These steps are particularly important for enterprises operating large numbers of domains and certificates.
The Bigger Picture
The SC-085v2 comes at a time when certificate management is getting more automated, and the duration of certificates is getting shorter.
The wider changes in certificate lifecycle by the CA/Browser Forum mean that organizations will be required to renew their certificates more often. This makes DNS a more important infrastructure.
A failure of DNSSEC that could have missed the notice in the past could now create a problem in renewing the certificate at a crucial moment. Therefore, DNSSEC cannot just be seen as part of the duties of a DNS administrator. It is being more closely connected to TLS management and domain name problems.
Conclusion
SC-085v2 is a significant move towards enhancing the security of issuing TLS certificates. With the requirement of publicly trusted certificate authorities ensuring DNSSEC is validated for relevant CAA and DCV lookups, the CA/Browser Forum is making it harder for cyber criminals to manipulate DNS data during domain validation.
Meeting the requirement does not imply that all organizations have to use DNSSEC. However, companies that have already adopted DNSSEC will have to verify that their configurations are correct and up-to-date.
For companies that use automated TLS certificates, this is crucial. A faulty DNSSEC chain can lead to other issues than just DNS problems as failure to renew a certificate can jeopardize website uptime.
Thus, the following solution is to be proactive, oversee DNSSEC, ensure existing CAA records are correct, verify that certificate renewal operations work as expected, and treat DNS integrity as part of TLS security.
As long as the internet’s certificate system evolves, the combination of DNSSEC, solid domain validation, and automated certificate management will gain more importance when it comes to trust on the internet.
