Add a CNAME recursive resolving datasource #390
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR replaces #389 where @bflad mentioned about offering a new datasource that would allow to get the CNAME chained list and in term of design would avoid any confusion and also it would not imply extra resolutions some other do not need.
Feature description
Offer a new dns_recursive_cname_record_set datasource allowing to recursively resolve some chained CNAMEs.
Example:
We would like a way to get all recursive CNAMEs pieces traversed by above A request.
Data structure
Output fields:
cnames (List of strings): ["stage.services.docusign.net", "stage.services.docusign.net.akadns.net."]
last_name (string): "stage.services.docusign.net.akadns.net."
Where cnames is an ordered list respecting CNAME precedence (higher index means more proximity to the last CNAME leaf) and where last_cname is a string containing the CNAME at the end of the chain.
Why to propose such orphan datasource (without a matching resource)?
When CNAME are chained, we have currently no easy way to unstack CNAMES using the existing data sources (dns_cname_record_set) because the chained CNAMEs tree depth is unknown and recursivity is not the Terraform HCL best ally, we currently do not see the way to get all the pieces, other data sources like dns_aaaa_record_set and dns_a_record_set allow to get the final value but we are not able to get the traversed CNAMEs to get up to the record value.
Unlike that, if we want to create such tree, it is as convenient as creating the end record set (with dns_a_record_set) and create some dns_cname_record the number of times we chain CNAMEs (from the one the closest of the leaf to the further one), we have no need to create a new resource for this.
The usecase where we (Docusign) need such datasource
We are using the Akamai terraform provider (https://registry.terraform.io/providers/akamai/akamai/latest/docs) to describe and provision traffic flows up to our datacenters.
This provider offers a akamai_gtm_property resource (https://techdocs.akamai.com/terraform/docs/gtm-rc-gtm-rc-property) that allows us to describe some datacenters as traffic target, for those traffic targets we can define some servers (using IPs or FQDNs).
In the case of FQDNs, if the user set one that has a prefix in akadns.net, then the API will reject it, it is the same if the FQDNs is a CNAME that goes at some point through a akamdns.net suffixed hostname (chained CNAMEs case).
Since we offer a self service to our developers, they may not know this particularity, currently they open a PR creating some properties or update some ones, a terraform plan is done in CI and everything is technically good for merging.
The problems are triggered later after merge/terraform apply when we face the above described GTM business rule and since we had no way to get all the pieces to resolve traversed CNAMEs of the provided FQDN, then we were not able to use a lifecycle precondition on the resource to make things fail on the PR into the CI.
The proposed feature would allows us to write something like this:
We would be able to make a lookup into the CNAMEs pieces of all provided servers for a property and make any plan fail when akadns.net prefixed hostname is traversed at some point.