feat(infra): let Terraform adopt the zone Route 53 Domains creates - #390
Merged
Merged
Conversation
Registering a domain through Route 53 Domains creates a hosted zone for it automatically and points the domain's nameservers at that zone. `dns.tf` unconditionally created its own `aws_route53_zone.app`, so buying the domain inside AWS -- the plan for branchaccounting.com -- would leave two zones for one name with different nameservers. Records would be written to the Terraform zone while resolution followed the registrar's, and every lookup would return NXDOMAIN with nothing in the plan output looking wrong. `var.use_existing_hosted_zone` picks the source: false keeps the current behaviour of creating the zone, true reads the existing one through `data.aws_route53_zone.app`. Both paths feed `local.zone_id`, which every record in dns.tf and email.tf now uses instead of reaching for the resource, and `local.zone_name_servers` behind the `app_domain_nameservers` output. Adopting rather than importing keeps the zone owned by whoever created it: there is no Terraform resource that registers a domain, so the registration and its zone are created outside this module either way, and a data source says that without pretending the module owns them. Also corrects the `app_domain` example and description. Both described a subdomain delegated from an external registrar, which is no longer the intended shape. Locals verified with `terraform console` across all three states: app_domain = "" -> create/lookup both false app_domain set -> create true, lookup false app_domain set + use_existing_hosted_zone -> create false, lookup true Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Auto-formatted .tf files with terraform fmt - Updated README.md with terraform-docs Co-authored-by: nourshoreibah <nourshoreibah@users.noreply.github.com>
Contributor
Terraform Plan 📖
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Follow-up to #388. We're keeping everything in AWS, which means registering
branchaccounting.comthrough Route 53 Domains — and that breaks anassumption
dns.tfwas making.The problem
Registering a domain in Route 53 Domains automatically creates a hosted zone
for it and points the domain's nameservers at that zone.
dns.tfunconditionallycreated its own:
So buying the domain inside AWS would leave two hosted zones for one name,
each with a different set of nameservers. Terraform would happily write the ACM
validation records, the SES DKIM CNAMEs, SPF and DMARC into its zone, while the
registrar kept pointing the world at the other one.
The failure mode is nasty because nothing looks wrong: the plan is clean, every
record shows as created, the SES console says "pending verification" forever, and
public lookups return NXDOMAIN. You would be debugging DKIM propagation while the
actual problem is that the records are in a zone nobody queries.
The fix
var.use_existing_hosted_zoneselects where the zone comes from:false(default)aws_route53_zone.apptruedata.aws_route53_zone.appBoth feed two new locals —
local.zone_idandlocal.zone_name_servers— andevery record in
dns.tfandemail.tfnow goes throughlocal.zone_idinsteadof reaching for
aws_route53_zone.app[0]directly. Theapp_domain_nameserversoutput readslocal.zone_name_servers, so it keepsworking in both modes (and is simply informational in the Route 53 case, since
the registrar already points at the right zone).
Adopting rather than importing is deliberate. There is no Terraform resource
that registers a domain, so the registration and its zone get created outside
this module no matter what. A data source states that honestly; an
importblockwould claim the module owns a zone it did not create and would put zone deletion
on the table during a destroy.
Also corrected
The
app_domainvariable's comment and description both described "a subdomaindelegated to Route 53 from the registrar" and used
accounting.branchinitiative.comas the example. Neither matches the plan any more —
branchaccounting.comis anapex, registered in AWS. Updated to match.
Verification
terraform fmt -check -recursiveclean,terraform validatepassesGating checked with
terraform consoleacross all three states — the two zoneflags are mutually exclusive and never both true:
app_domainuse_existing_hosted_zonecreate_zonelookup_zone""falsetrueDerived values resolve correctly for the real domain:
no-reply@branchaccounting.com,mail.branchaccounting.com,api.branchaccounting.com, and both DMARC forms(
v=DMARC1; p=none;and withrua=mailto:…)Applies as a no-op today —
app_domainis still""🤖 Generated with Claude Code