[Route53] Support for cross account DNS delegation

[workeitel]

Right now CDK already supports cross stack Route53 delegations and even cross region delegations (since Route53 is a global service).

But with sub-zones it's not uncommon to have a root DNS account and delegating zones into the sub-accounts. It would be great if CDK could help creating the cross account delegation.

Use Case

Creating a global DNS structure across multiple accounts and delegating the regional zones into the right sub-accounts automatically.

Proposed Solution

Some ideas for the interface.

1. Same CFN stack (already works ✅)

const parentZone = new route53.PublicHostedZone(this, "TopZone", {
  zoneName: "someexample.com"
});

parentZone.addDelegation(new route53.PublicHostedZone(this, "SubZone", {
  zoneName: "sub.someexample.com"
}));

2. Same account and region (already works ✅)

It uses CFN import/export to pass route53 zone id

stack 1

zone = new route53.PublicHostedZone(this, "TopZone", {
  zoneName: "someexample.com"
});

stack 2

const subZone = new route53.PublicHostedZone(this, "SubZone", {
  zoneName: "sub.someexample.com"
});

new route53.ZoneDelegationRecord(this, "delegate", {
  nameServers: subZone.hostedZoneNameServers!,
  zone
});

3. Same account different region (already works ✅)

zone id passed via cdk context

stack 2

const subZone = new route53.PublicHostedZone(this, "SubZone", {
  zoneName: "sub.someexample.com"
});

new route53.ZoneDelegationRecord(this, "delegate", {
  nameServers: subZone.hostedZoneNameServers!,
  recordName: "sub.someexample.com",
  zone: route53.PublicHostedZone.fromLookup(this,
    "TopZone",
    { domainName: "someexample.com" },
  )
});

Variant 4.1. Different account - delegation by parent zone (🆕)

Hosted zone name servers needs to be passed from stack 2 to stack 1. Stack 1 puts delegation in place.

Downside: First Stack 2 needs to be synth but the hosted zone does not work yet because it can't be resolved (like for ACM DNS validation). Then Stack 1 needs to be deployed to put delegation in place. That creates an annoying dependency.

stack 1

const parentZone = new route53.PublicHostedZone(this, "TopZone", {
  zoneName: "someexample.com"
});

new route53.ZoneDelegationRecord(this, "delegate", {
  nameServers: [...], // Needs to get the nameServers from stack 2 somehow
  zone
});

stack 2

new route53.ZoneDelegationRecord(this, "delegate", {
  nameServers: subZone.hostedZoneNameServers!,
  zone
});

Variant 4.2 Different account - delegation by child zone (🆕)

Stack 1 creates a role which is allowed to be assumed by Stack 2 to put the delegation in place. Stack 2 requires a custom resource with a lambda function to assume the role and create delegation.

Downside is a custom CloudFormation resource is required to put the delegation in place. Also in case the un-delegate fails on delete a dangling delegation record would be left behind which can be a security problem.

stack 1

const parentZone = new route53.PublicHostedZone(this, "TopZone", {
  zoneName: "someexample.com"
});

role = new iam.Role(this, "CrossAccoundZoneDelegationRole", {
  assumedBy: new iam.AccountPrincipal("STACK2ACCOUNTID"),
  inlinePolicies: {
    "delegation": new iam.PolicyDocument({
      statements: [new iam.PolicyStatement({
        actions: ["route53:ChangeResourceRecordSets"],
        resources: [parentZone.hostedZoneArn]
      })]
    })
  }
});

// maybe with a helper like:
// parentZone.enableCrossAccountDelegation(["STACK2ACCOUNTID"]);

stack 2 - uses new CrossAccountZoneDelegationRecord construct

new route53.CrossAccountZoneDelegationRecord(this, "delegate", {
  nameServers: subZone.hostedZoneNameServers!,
  recordName: "sub.someexample.com",
  roleArn: "arn:...",
  zoneId: "1234"
});

---

I think 4.2 has clear advantages from usage perspective but is more difficult to implement because the custom resource is required.

I'm not super familiar if there is already a mechanism to pass references cross account/region. It looks like the existing system is restricted to same account/region?

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[workeitel]

Any opinion here? Is there something missing from my side or should I just create a PR?

[shivlaks]

@workeitel feel free to create a PR and put it into draft.

I agree with you that 4.2 is the solution that's more user friendly. We haven't particularly shied away from using custom resources. I'll need to look a little more to see if we have other/better prior art though.

[aripalo]

Awesome! I'd love to see this feature in CDK! 👍

[ayush987goyal]

Hi @shivlaks , @workeitel

I have created a draft PR for this. Could you please take a look? We still have to figure out some things related to testing (mentioned in the PR).

Thanks!

Update: Integration tests successful and this PR is now ready for review.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.