feat: certificate validation with multiple Route 53 zones

[flora-five]

Description

The proposed change is based on what I think is a simple idea: taking as input a mapping from domain names to publicly hosted Route 53 zone ids, for every record necessary for validation, find the best matching zone that can contain the validation record and create the record into that zone. The best matching zone is found by iterating over all the domain names mapped to hosted zones, from the longest one to the shortest one, and checking if the current fully-qualified domain name is a parent of the fully-qualified name in resource_record_name.

The locals section becomes bigger and maybe too verbose, but I'll try to explain the changes in a little more details:

• the module receives as input an optional mapping from domain names (public zones names) to zone ids
• build two subsets of local.distinct_domain_names and local.validation_domains. One subset contains the items that will be used to create the validation records, one subset contains the items for which validation records cannot be created by the module because they cannot be hosted in the zones given as input
• each validation record is created into the zone with the longest matching domain
• the two subsets for which validation records cannot be created are used as module outputs so that the users of the module can create the validation records outside the module
• some locals used as module outputs are changed slightly to have normalized types

An example is added too: it shows an ACM certificate with requires validation records in three zones. In the set of three zones, one zone has a subdomain delegation to another zone.

There are no documentation changes yet. I would like to see first if the idea is in the good direction.

Motivation and Context

There is high interest in creating ACM certificates with multiple domains in them (#21). My particular use-case is multiple domains ACM certificates for using on CloudFront distributions.

This change or the idea from this change, if accepted, would allow the module to cover more use-cases:

• validation of ACM certificates with multiple domains, for example: domain_one, *.domain_one, domain_two, *.domain_two, where domain_one is hosted in one Route 53 zone and domain_two is hosted in another Route 53 zone
• validation of ACM certificates with one or more parent domains and subdomains, for example: example.com, my.example.com, a.little.deep.my.example.com, with example.com hosted in one Route 53 zone and delegating my.example.com to another Route 53 hosted zone
• for ACM certificates with domains hosted on both Route 53 zones and third-party providers, the creation of the Route 53 validation records part. The user of the module, by setting wait_for_validation to false and using the validation_domains_without_matching_zone output , will be able to create the records at the third-party provides and complete the validation. For example: domains example.com and example.org in the certificate, domain example.com hosted in a Route 53 zone, domain example.org hosted somewhere else.

Breaking Changes

The change adds a new input and new outputs and the new logic is applied when using the new input variable.

How Has This Been Tested?

• I have tested and validated these changes using one or more of the provided examples/* projects

[antonbabenko]

This is a good idea but the implementation is very complicated.

Instead of making any assumptions and finding the best domain/zone_id match, let's just have another map variable that will be used to lookup for correct zone_id (default behavior - as it is now).

[flora-five]

Indeed, the implementation is very complicated.

In the latest change the mapping is for each item from distinct_domain_names, for which the user wants to have a validation record, to a zone id. The user of the module is responsible for building the complete map, even if there are a lot of subdomains.

[github-actions]

This PR has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this PR will be closed in 10 days

[github-actions]

This PR was automatically closed because of stale in 10 days

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.