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回答
0
承認された回答

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
回答済み 2年前

ログインしていません。 ログイン 回答を投稿する。

優れた回答とは、質問に明確に答え、建設的なフィードバックを提供し、質問者の専門分野におけるスキルの向上を促すものです。

質問に答えるためのガイドライン

関連するコンテンツ