AWS::CertificateManager::Certificate - Resource deletion fails when using DomainValidationOptions

[sehrope]

1. Title

AWS::CertificateManager::Certificate - Resource deletion fails when using DomainValidationOptions

2. Scope of request

AWS::CertificateManager::Certificate with DomainValidationOptions allows automated validation of certificates via Route53 records on a HostedZone.

However, deleting the AWS::CertificateManager::Certificate does not remove the validation records from the Route53 HostedZone.

This prevents CloudFormation from being able to delete the HostedZone and thus the stack itself.

3. Expected behavior

Deleting the AWS::CertificateManager::Certificate resource should delete the validation records and allow the HostedZone to be deleted.

4. Suggest specific test cases

Here's an example that creates a new HostedZone, updates its parent HostedZone to reflect the new HostedZone's nameservers, and finally creates an AWS::CertificateManager::Certificate in the new hosted zone using domain validation via a CNAME record:

AWSTemplateFormatVersion: 2010-09-09

Parameters:
  HostedZoneName:
    Description: Full host name for the DNS zone, e.g. foo.example.com
    Type: String
  ParentHostedZoneId:
    Description: Route53 HostedZoneId of the parent of the to be created HostedZoneName, e.g. Z0123456789ABCDEFGHIJ
    Type: String

Resources:
  HostedZone:
    Type: AWS::Route53::HostedZone
    Properties:
      Name: !Sub "${HostedZoneName}."

  HostedZoneNSRecords:
    Type: AWS::Route53::RecordSetGroup
    Properties:
      HostedZoneId: !Sub "${ParentHostedZoneId}"
      RecordSets:
        - Name: !Sub "${HostedZoneName}."
          Type: NS
          TTL: "60"
          ResourceRecords: !GetAtt HostedZone.NameServers

  Certificate:
    Type: "AWS::CertificateManager::Certificate"
    Properties: 
      DomainName: !Sub "*.${HostedZoneName}"
      DomainValidationOptions:
        - DomainName: !Sub "*.${HostedZoneName}"
          HostedZoneId: !Ref HostedZone
      ValidationMethod: DNS

Attempting to delete this stack fails at deleting the HostedZone with the error:

The specified hosted zone contains non-required resource record sets and so cannot be deleted. (Service: Route53, Status Code: 400, Request ID: ec406264-50ae-4f5a-96dd-4d451e207aaf, Extended Request ID: null)

Manually deleting the the domain validation CNAME prior to deleting the CloudFormation stack allows the deletion of the stack to succeed.

5. Helpful Links to speed up research and evaluation

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-certificatemanager-certificate.html

https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html

6. Category (required) - Networking & Content

[stoyan-scava]

I see this bug rusting here for about 2 years without any attention while in the aws-cdk there are a dozen of issues tracking it and it's not clear to me why.

@Dzhuneyt I was wondering if you could suggest some magic trick to raise the awareness about it and hopefully push it form the 'Research' column to 'We are working on it' column?

[Dzhuneyt]

@stoyan-scava I don't see this issue receiving any preferential treatment until it affects a critical mass of projects/developers - which is usually represented by the number of upvotes on the issue - currently at five. The prioritisation is based purely on this factor AFAIK, rather than how "old" the issue is.

This being said this issue has an unofficial "escape hatch" that involves attaching a custom resource (Lambda) that does the cleanup of DNS records (using AWS SDK) prior to the Hosted Zone being deleted. I've seen an L3 construct that does this somewhere in GitHub that could save you the time of figuring this out, but for me, this was never a pain point enough to force me to explore that territory deeper, given that deleting dns records manually is relatively easy from the aws console and this issue comes around to bite me no more than once per year or so.

[stoyan-scava]

Yes I know about the unofficial solution, but there is a good reason for it to stay unofficial - Custom Resources are not meant to add new CloudFormation Resources

[piotrekwitkowski]

This should be prioritised to allow migration from a deprecated construct in CDK v2!

[kylerjensen]

This is a super annoying behavior for my use case. I'm in early stages of using CDK and it is really cumbersome to have to go clean up those records each time I destroy and recreate my stack.

[robzet]

This is blocking CDK destroy command from working when you run basic infrastructure such as Cloudfront that needs a working dns/cert setup.

[aaroncowie]

@stoyan-scava I don't see this issue receiving any preferential treatment until it affects a critical mass of projects/developers - which is usually represented by the number of upvotes on the issue - currently at five. The prioritisation is based purely on this factor AFAIK, rather than how "old" the issue is.

This being said this issue has an unofficial "escape hatch" that involves attaching a custom resource (Lambda) that does the cleanup of DNS records (using AWS SDK) prior to the Hosted Zone being deleted. I've seen an L3 construct that does this somewhere in GitHub that could save you the time of figuring this out, but for me, this was never a pain point enough to force me to explore that territory deeper, given that deleting dns records manually is relatively easy from the aws console and this issue comes around to bite me no more than once per year or so.

Given that this ticket is now at 43 upvotes that gives it more votes than half of the issues currently in the "We're working on it" column. Just wanted to bump this to see if it's priority can be revisited.

I understand that upvotes are not the only factor to consider, I'm sure there is good reason to work on those issues ahead of this one however it would be great if someone could quickly revisit this ticket's priority. Thanks!

[stoyan-scava]

Thank you @aaroncowie

IMO the Cloudformation edge deployment solution would be optimal

[MyNameIsOka]

Any news about this? Would love this to be fixed.

[RickKrause]

Any news about this? I would love to have this fixed