CDK Route 53 zone lookup brings back wrong zone ID

0

We are attempt to update our IaC code base to CDK v2. Prior to that we're deploy entire stacks of our system in another test environment. One part of a stack creates a TLS certificate for use with our load balancer.

var hostedZone = HostedZone.FromLookup(this, $"{config.ProductName}-dns-zone", new HostedZoneProviderProps
{
	DomainName = config.RootDomainName
});

DnsValidatedCertificate certificate = new DnsValidatedCertificate(this, $"{config.ProductName}-webELBCertificate-{config.Environment}", new DnsValidatedCertificateProps
{
	HostedZone = hostedZone,
	DomainName = config.AppDomainName,
	// Used to implement ValidationMethod = ValidationMethod.DNS
	Validation = CertificateValidation.FromDns(hostedZone)
});

For some reason, the synthesised template defines the hosted zone ID for that AWS::CloudFormation::CustomResource has something else other than the actual zone ID in that account. That causes the certificate request validation process to fail - thus the whole cdk deploy - since it cannot find the real zone to place the validation records in.

If looking at the individual pending certificate requests in Certificate Manager page, they can be approved by manually pressing the [[Create records in Route 53]] button, which finds the correct zone to do so.

Not sure where exactly CDK is finding this mysterious zone ID that does not belong to us?

    "AppwebELBCertificatetestCertificateRequestorResource68D095F7": {
      "Type": "AWS::CloudFormation::CustomResource",
      "Properties": {
        "ServiceToken": {
          "Fn::GetAtt": [
            "AppwebELBCertificatetestCertificateRequestorFunctionCFE32764",
            "Arn"
          ]
        },
        "DomainName": "root.domain",
        "HostedZoneId": "NON-EXISTENT ZONE ID"
      },
      "UpdateReplacePolicy": "Delete",
      "DeletionPolicy": "Delete",
      "Metadata": {
        "aws:cdk:path": "App-webELBStack-test/App-webELBCertificate-test/CertificateRequestorResource/Default"
      }
    }
1 Answer
0
Accepted Answer

So apparently CDK has a file cdk.context.json that cached the (non-existent) zone ID of the old zone of the same name that was deleted a long time ago. Deleting the file allowed CDK to refresh to the new zone ID.

icelava
answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions