<p>Short answer: I don't believe that is possible.</p>
<p><em>In my opinion</em>, I suspect this problem has more to do with process and responsibilities than it does with Terraform.</p>
<p>You said:</p>
<blockquote>
<p>It's possibly that I could go with the fist approach (e.g. where example.com is my only hosted zone) only for someone to later add a hosted zone for the mysite subdomain. If that occurred I wouldn't want to have to change my code...</p>
</blockquote>
<p>Terraform is best when <em>at least most</em> of its associated resources are Terraform-managed. That means you should be managing your zones, too, not just your records.</p>
<p>Which begs the question: why isn't your zone in Terraform?</p>
<p>If your zone was Terraform-managed, the impact of that change should be evident in a <code>terraform plan</code> to anyone who might come along to change it. Even if it references a zone in a different remote state file, a tool like <a href="https://www.runatlantis.io/" rel="nofollow noreferrer">runatlantis.io</a> could show that diff in the Github PR before merging.</p>
<p>Let's say this is the worst-case scenario: you managed the records, it's a different team that creates and manages the zones, and they don't want to use Terraform. In that case, perhaps your DNS records shouldn't be in Terraform, either. Terraform is arguably too stateful for that. Perhaps a few python boto3 scripts can do everything you need it to.</p>

CC BY-SA 4.0
2020-07-24T17:55:28.570Z
2020-07-24T17:55:28.570Z
Woodland
<h2>Context</h2>
<p>In Terraform, to create a new domain record, I first need to find the zone under which it should be hosted.  E.g. If I want to create a DNS record for <code>mysite.example.com</code>, I'd get the zone <code>example.com</code> and create a record for <code>mysite</code> under it, like so:</p>
<pre><code>variable zone {
    type = string
}
variable subdomain {
    type = string
}
variable targets {
    type = list(string)
    default = [&quot;devops.stackexchange.com&quot;] # just defaulting this stuff to reduce code in this sample
}
data aws_route53_zone this {
    name = var.zone
}
resource aws_route53_record this {
    zone_id = data.aws_route53_zone.this.zone_id
    name = &quot;${var.subdomain}.${var.zone}&quot;
    type = &quot;CNAME&quot;
    ttl = 100
    records = var.targets
}
output fqdn {
    value = aws_route53_record.this.fqdn
}
</code></pre>
<p>If I wanted to create <code>devops.mysite.example.com</code> then I'd either call this module with:</p>
<pre><code>zone = &quot;example.com&quot;
subdomain = &quot;devops.mysite&quot;
</code></pre>
<p>Or, if I had a hosted zone for <code>mysite.example.com</code>, I'd call it with:</p>
<pre><code>zone = &quot;mysite.example.com&quot;
subdomain = &quot;devops&quot;
</code></pre>
<p>It's possibly that I could go with the fist approach (e.g. where <code>example.com</code> is my only hosted zone) only for someone to later add a hosted zone for the <code>mysite</code> subdomain.  If that occurred I wouldn't want to have to change my code; since the requirement is still the same; I'd just want Terraform to see that it was still possible to fulfill my requirement (i.e. to create a DNS CName record pointing <code>devops.mysite.example.com</code> at <code>devops.stackexchange.com</code>) and adjust accordingly.</p>
<h1>Question</h1>
<p>Is there a way to have Terraform determine the appropriated hosted zone for a given record?  E.g. So I could call my module passing <code>devops.mysite.example.com</code> and have the system work its way through the hosted zones recursively until it finds the correct one, then creates the appropriate entry there (or if no appropriate zone was found, error)?</p>

<amazon-web-services><terraform><dns>
Find relevant domain/hosted zone under which to host subdomain
JohnLBevan
# Find relevant domain/hosted zone under which to host subdomain

(Asked by: username_0 on 2020-07-24)

Context
In Terraform, to create a new domain record, I first need to find the zone under which it should be hosted.  E.g. If I want to create a DNS record for mysite.example.com, I'd get the zone example.com and create a record for mysite under it, like so:
variable zone {
    type = string
}
variable subdomain {
    type = string
}
variable targets {
    type = list(string)
    default = ["devops.stackexchange.com"] # just defaulting this stuff to reduce code in this sample
}
data aws_route53_zone this {
    name = var.zone
}
resource aws_route53_record this {
    zone_id = data.aws_route53_zone.this.zone_id
    name = "${var.subdomain}.${var.zone}"
    type = "CNAME"
    ttl = 100
    records = var.targets
}
output fqdn {
    value = aws_route53_record.this.fqdn
}

If I wanted to create devops.mysite.example.com then I'd either call this module with:
zone = "example.com"
subdomain = "devops.mysite"

Or, if I had a hosted zone for mysite.example.com, I'd call it with:
zone = "mysite.example.com"
subdomain = "devops"

It's possibly that I could go with the fist approach (e.g. where example.com is my only hosted zone) only for someone to later add a hosted zone for the mysite subdomain.  If that occurred I wouldn't want to have to change my code; since the requirement is still the same; I'd just want Terraform to see that it was still possible to fulfill my requirement (i.e. to create a DNS CName record pointing devops.mysite.example.com at devops.stackexchange.com) and adjust accordingly.
Question
Is there a way to have Terraform determine the appropriated hosted zone for a given record?  E.g. So I could call my module passing devops.mysite.example.com and have the system work its way through the hosted zones recursively until it finds the correct one, then creates the appropriate entry there (or if no appropriate zone was found, error)?

**Tags:** amazon-web-services, terraform, dns


---

## 1 answers

### Answer by username_1 on 2020-07-24. Score: 1

Short answer: I don't believe that is possible.

*In my opinion*, I suspect this problem has more to do with process and responsibilities than it does with Terraform.

You said:

> It's possibly that I could go with the fist approach (e.g. where example.com is my only hosted zone) only for someone to later add a hosted zone for the mysite subdomain. If that occurred I wouldn't want to have to change my code...

Terraform is best when *at least most* of its associated resources are Terraform-managed. That means you should be managing your zones, too, not just your records.

Which begs the question: why isn't your zone in Terraform?

If your zone was Terraform-managed, the impact of that change should be evident in a `terraform plan` to anyone who might come along to change it. Even if it references a zone in a different remote state file, a tool like [runatlantis.io](https://www.runatlantis.io/) could show that diff in the Github PR before merging.

Let's say this is the worst-case scenario: you managed the records, it's a different team that creates and manages the zones, and they don't want to use Terraform. In that case, perhaps your DNS records shouldn't be in Terraform, either. Terraform is arguably too stateful for that. Perhaps a few python boto3 scripts can do everything you need it to.


---

