Cloudformation-coverage-roadmap: AWS::Route53::HostedZone-DelegationSetId

[acdebaca]

1. Title

AWS::Route53::HostedZone-DelegationSetId

2. Scope of request

A new attribute, DelegationSetId, is desired on the AWS::Route53::HostedZone resource type.

• The attribute would be optional.
• The attribute would only be valid with public hosted zones.

When creating a public hosted zone, the Route 53 API allows the caller to specify a DelegationSetId that references an existing reusable delegation set. Specifying a reusable delegation set guarantees that the authoritative name servers for the hosted zone are known in advance, which simplifies configuration of delegation in the parent hosted zone.

The delegation set must be created via the API. It is not within the scope of this request to create delegation sets via CloudFormation, but rather to reference an already-created delegation set in an AWS::Route53::HostedZone resource description in a CloudFormation template.

3. Expected behavior

On Create

The new hosted zone would contain a single NS record at the zone apex, as it already does, however the 4 name servers in the value of the record would match those of the given reusable delegation set.

On Update

• If the `DelegationSetId` attribute is changed from one valid delegation set ID to another valid delegation set ID, then the values of the zone apex NS record would be modified to match the given delegation set.
• If the `DelegationSetId` attribute is removed, then the values of the zone apex NS record would be dynamically generated as they would be when creating a hosted zone without specifying a `DelegationSetId`.
• If the `DelegationSetId` attribute is added to the template of an existing stack that presently did not specify the attribute, then the zone apex NS record would be modified to match the given delegation set.

On Delete

The hosted zone would be deleted, and with it, all record sets including the zone apex NS record, regardless of whether it was generated dynamically or via reusable delegation set.

4. Test Case Recommendations

1. Common use case: Create a stack from a template containing a public hosted zone with a valid ID of a reusable delegation given as the string value of DelegationSetId.
   
   
   
   • Confirm that the zone apex NS record matches those of the delegation set ID.
   
   
   • Note that !Ref <resource-name> would not apply here, as reusable delegation sets cannot be created through CloudFormation (yet). However the value could be a template parameter or a hard-coded value exported as an output value from another stack.
   
   
2. Update case: Update a successfully-created stack containing a public hosted zone whose original template included DelegationSetId by removing the property.
   
   
   
   • Confirm that the stack update succeeds.
   
   
   • Confirm that all other record sets remain unchanged.
   
   
   • Note that, although unlikely, it is remotely possible that the NS records remain unchanged.
   
   
3. Update case: Create a stack containing a public hosted zone whose original template did not include DelegationSetId, and update the stack by adding the property with a valid delegation set ID.
   
   
   
   • Confirm that the zone apex NS record change to the values of the delegation set ID.
   
   
   • Confirm that all other record sets remain unchanged.
   
   
4. Failure case: Specify an invalid delegation set ID for the value of DelegationSetId in a public hosted zone resource template passed to CreateStack.
5. Failure case: Change a valid delegation set ID to an invalid delegation set ID for the value of DelegationSetId in a public hosted zone resource template passed to UpdateStack.
6. Failure case: Specify a valid delegation set ID for the value of DelegationSetId in a private hosted zone resource template passed to CreateStack.
7. Failure case: Create the maximum number of hosted zones allowed by the delegation set in a stack Confirm success. Create one or more hosted zones in a separate stack referencing the same delegation set. Confirm failure.
8. Failure case: Create the maximum number of hosted zones allowed by the delegation set in a stack. Confirm success. Create one or more hosted zones in the same stack template referencing the same delegation set by issuing an UpdateStack action. Confirm failure.
9. Failure case: Create a reusable delegation set from an existing hosted zone by specifying the HostedZoneId parameter in the CreateReusableDelegationSet invocation. Create a CloudFormation stack from a template that includes a hosted zone resource that is a subdomain of the existing hosted zone, with the DelegationSetId set to the delegation set generated from the parent domain. This fails because Route 53 disallows parent zones to delegate to the same nameservers for a subdomain.

5. Helpful Links to speed up research and evaluation

• CreateHostedZone API Docs, particularly the DelegationSetId tag.

• Reusable delegation set API docs

  • CreateReusableDelegationSet
  • GetReusableDelegationSet
  • GetReusableDelegationSetLimit - max # of zones that can use a DS
  • ListReusableDelegationSets
  • DeleteReusableDelegationSet

• API docs for changing record sets:

  • ChangeResourceRecordSets
  • ListResourceRecordSets

6. Category

Networking & Content

7. Additional Context

There appear to be only two ways via the Route 53 API to associate a hosted zone with a reusable delegation set:

1. Create a new hosted zone, specifying a DelegationSetId.
2. Create a new reusable delegation set by specifying the optional HostedZoneId parameter when invoking CreateReusableDelegationSet. Doing so creates the delegation set from the current NS records for the zone, and has the side-effect of associating that zone with the delegation set. This also has the side-effect of not allowing the delegation set to be deleted until the original zone from which it was created gets deleted.

Because the API offers no way to associate an existing hosted zone with an existing reusable delegation set, the update behavior described would almost certainly require replacement. Moreover, all non-apex NS and SOA records and all other hosted zone properties would have to be copied from the current resource to the replacement resource.

Record set and record set groups can be created via CloudFormation, so any records in a CloudFormation-created hosted zone that are not created as part of a CloudFormation template would be considered drift. So either the mere presence of non-CloudFormation-created record sets should cause updates to fail, or the records would be subject to loss if an update that requires replacement were invoked. I suppose these cases are already considered in the implementation of the Name property, updates of which require replacement.

[joaopenteado]

Still no updates on this?
In addition to the original request, I believe that introducing AWS::Route53::ReusableDelegationSet as a new resource would also be very well welcomed. Following the requirements for the CreateReusableDelegationSet API call, it could go something along the lines of:

ReusableDelegationSet:
  Type: AWS::Route53::ReusableDelegationSet
  Properties:
     HostedZoneId: # optional parameter

For returned values, we could have !Ref ReusableDelegationSet return the reusable delegation set ID and !GetAtt ReusableDelegationSet.NameServers return an array with the nameservers in it.

Any thoughts?

[mhy42]

This would be very helpful for us too! We have a high amount of Domains we want to move to Route 53 zones. So we like to use Route53 reusable delegation sets in order to reduce the amount of name servers that are used among them. As we're using CloudFormation to create and maintain the Route53 Hosted Zones, we would like to be able to specify a reusable delegation set ID to be used with these resources.
To create a ReusableDelegationSet with CloudFormation would also be fine. (But since this happens much less often, it's possible to do it manually via the command line if necessary.)

[Pablissimo]

This is all the more confusing because the docs seem to suggest you can already do this (as of about early Sept) on the Route53::HostedZone resource but the mentioned DelegationSetId element doesn't exist anywhere else on that page of documentation. Have raised this bug on the documentation, am hoping that it being in the docs means a release with this change in it is on the way?

[mhy42]

@Pablissimo

This is all the more confusing because the docs seem to suggest you can already do this (as of about early Sept) on the Route53::HostedZone resource but the mentioned DelegationSetId element doesn't exist anywhere else on that page of documentation.

Yes. And it's not only the mentioned english documentation - but also in other language versions - e.g. also in the german route53-hostedzone documentation.
I'm hoping that it being in even more docs means a release with this feature is coming soon!

[rajjeet]

This is a major pain point for automating domain creation.

[lennartt]

+1
I would also like to see this implemented.

[Rabadash8820]

No word from Amazon on this? As @Pablissimo mentioned, the docs on this are rather misleading, and this would be a very useful feature. My use case is that I want to set up some S3 buckets and CloudFront distributions, as well as a hosted zone with record sets pointing at those resources, within the same CloudFormation template, but then be able to make a separate hosted zone for the same domain where I can manually add other record sets, for things like mail servers. This will only work if all the hosted zones for the domain use the same delegation set. It would be great if there was a ReusableDelegationSet resource, as @joaopenteado described, or at least a way for me to pass in a DelegationSetId as a parameter to the template and reference it on a new HostedZone resource, as @acdebaca originally described.