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 réponse
0
Réponse acceptée

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
répondu il y a 2 ans

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions