Why didn't the CNAME record resolve for my ACM issued certificate and the DNS validation status is still "Pending validation"?

7 minute read

I used DNS validation to request a new AWS Certificate Manager (ACM) certificate for my domain. However, the CNAME record didn't resolve and the status is still "Pending validation."

Short description

DNS validation certificate requests might remain in the "Pending validation" state for the following reasons:

You didn't add the CNAME record to the correct DNS configuration.
The CNAME record includes additional characters or is missing characters.
You added the CNAME record to the correct DNS configuration, but the DNS provider automatically added the bare domain to the end of its DNS records.
A CNAME record and a TXT record exist for same domain name.
DNSSEC is activated for the domain but the configuration isn't correct.
Note: ACM periodically checks for the DNS record. You can't manually check for the DNS record.

Resolution

Note: Run the Linux and macOS commands in your machine's terminal. Or, run the Windows commands in PowerShell or cmd.

You didn't add the CNAME record to the correct DNS configuration

Note: In the following commands, replace example-cname.example.com with your ACM CNAME record.

Run the following command for your operating system (OS) to check whether you added the CNAME record to the correct DNS configuration:

Linux and macOS:

dig +short _example-cname.example.com

Windows:

nslookup -type=cname _example-cname.example.com

Note: If you added the CNAME record to the correct DNS configuration and the record propagated, then the command output contains the CNAME record's value. Some DNS providers can take 24 to 48 hours to propagate DNS records.

If the command didn't return an output, then add the CNAME record to the correct DNS configuration.

Run the following command for your OS to determine the DNS configuration that you must add the CNAME record to:

Linux and macOS:

dig NS example.com

Windows:

nslookup -type=ns example.com

Note: The output provides the name servers in the NS record of the correct DNS configuration.

Confirm that the DNS configuration where you add the CNAME record includes an NS record with these name servers.

For information about how to add CNAME records to your Amazon Route 53 hosted zone, see Creating records by using the Amazon Route 53 console.

Note: When the CNAME record is in a Route 53 private hosted zone, you can't validate domain ownership. The CNAME record must be in a public hosted zone.

The CNAME record includes additional characters or is missing characters

If the CNAME record contains additional characters, then remove them. If characters are missing in the name or value, then add them.

The DNS provider appended the bare domain to the CNAME record name

Some DNS providers might automatically append the bare domain to the end of the name field of all DNS records. The propagated CNAME record is similar to the following:

_example-cname.example.com.example.com

Because the CNAME record name doesn't match the one that ACM provides, the validation isn't successful. The ACM certificate remains in Pending validation until it fails 72 hours after the request.

Run the following command for your OS to determine whether your DNS provider automatically appended the bare domain to the CNAME record:

Linux and macOS:

dig +short _example-cname.example.com.example.com

Windows:

nslookup -type=cname _example-cname.example.com.example.com

If the output returns the value of the CNAME record, then your DNS provider added the bare domain.

To resolve this issue, edit your CNAME record to remove the bare domain from the text that you entered for the name field. After your DNS provider adds the bare domain, only one bare domain remains.

A CNAME record and a TXT record exist for same domain name

Run the following commands for your OS to check whether the CNAME record and TXT record exist for the same domain:

Linux and macOS:

dig +short CNAME cname_record_name
dig TXT cname_record_name

Windows:

nslookup -type=CNAME cname_record_name
nslookup -type=TXT cname_record_name

Note: In the preceding commands, replace cname_record_name with your CNAME record name.

Compare the CNAME record and TXT record types in the output. If the record types are identical, then a malformed record is keeping the certificate in the Pending validation state. To resolve this issue, delete the TXT record. For more information, see Troubleshoot DNS validation problems.

DNSSEC is configured for the domain but validation fails

If your domain uses DNSSEC but the configuration is incorrect, then ACM can't validate your certificate. The private CA must issue certificates to a domain that has a valid DNSSEC chain of trust. When DNSSEC is present, ACM validates the DNSSEC signatures back to the IANA root trust anchor during Domain Control Validation (DCV) and Certificate Authority Authorization (CAA) record lookups. If any link in that chain is broken or misconfigured, then DNSSEC validation fails and the DNS response is treated as untrustworthy. This blocks certificate issuance or renewal.

Note: Domains without DNSSEC configured are not affected. When ACM queries a domain without DNSSEC, ACM classifies the response as "insecure" and issuance proceeds normally.

Run the following command for your OS to determine whether DNSSEC causes the issue:

Linux and macOS:

  dig @8.8.8.8 _example-cname.example.com CNAME

Windows:

  nslookup -type=cname _example-cname.example.com 8.8.8.8

Note: Replace _example-cname.example.com with your ACM CNAME record.

If the response shows status SERVFAIL instead of NOERROR or "Server failed", then DNSSEC validation might fail.

To confirm on Linux and macOS, run the following query with DNSSEC checking turned off:

  dig @8.8.8.8 _example-cname.example.com CNAME +cd

If the query with +cd returns the correct CNAME value but the query without it returns SERVFAIL, then a DNSSEC misconfiguration blocks ACM validation.

Run the following command to check whether DNSSEC is turned on for your domain:

  dig DS example.com +short

Note: If the output this returns DS records, then this confirms that DNSSEC is turned on for your domain.

Run the following command to check for matching DNSKEY records in your zone:

  dig DNSKEY example.com +short

If DS records exist at the parent zone but no matching DNSKEY records exist in your zone, then the DNSSEC chain of trust is broken.

Note: The dig DS and DNSKEY commands are available on Linux and macOS only. For Windows, use an online DNSSEC diagnostic tool to check the chain of trust.

If DNSSEC isn't required for your domain, then take the following actions:

Remove the DS record at your domain registrar. For instructions, see Deleting public keys for a domain.
Wait for DNS propagation. This can take up to 48 hours.
Confirm that dig DS example.com +short no longer returns DS records.
Retry certificate issuance. If the existing certificate has timed out, delete it and request a new one.

If DNSSEC is required for your domain, then take the following actions:

Compare the DS records at the parent zone with the DNSKEY records in your zone, and then identify the specific break in the chain of trust

Correct the misconfiguration at your DNS provider or domain registrar. To fix the DNSSEC misconfiguration, take the following actions:

Update mismatched DS records to match the current DNSKEY in your zone.
Activate the AWS Key Management Service (AWS KMS) keys that you used for DNSSEC signing in Route 53.
Add DS records in the parent zone for child subdomains that have DNSSEC signing turned on.
Run the following command to confirm that the output returns NOERROR with the expected value:
```
@8.8.8.8 _example-cname.example.com
```
Note: After DNSSEC is correctly configured, ACM automatically retries domain validation on its next periodic check.