I have various environments (in the form of workspaces) in Terraform (dev / staging / prod) on google cloud. They mostly share the same code regarding infrastructure. The changes are in settings for the size of the envs. So far so good. But, when it comes to DNS, all the envs share the exact same code and even the same state as there is only one DNS zone and I don't see a reason to use more zones (maybe I'm wrong).

This comes with some issues: when I make some changes in one environment I need to import it in the others. And when I want to destroy an environment then the DNS zone gets destroyed as well.

I think there must be a better way to handle DNS in multi environment setup.
I need DNS in all envs because when I add a public facing service in any of the envs then its IP needs to be associated with a new record in the zone.

Edit: I am now trying to use various different zones (google_dns_managed_zone) to link to subdomains for each environment. That way I can have only the resource needed in each environment. But now the issue is that each zone is automatically assigned to new NS servers. So I should either update the registrar's list of name servers or I should add those to the main zone (I tried, both way works). But that is getting complicated and not so efficient.

  • Did you ever arrive at a solution for this problem? I'm finding that I'm going to have to create a a project that only manages the HostedZone record, and then import that value into my various environments. Apr 8 '20 at 19:55
  • @BlackDynamite no, I never found a solution.
    – Bastian
    Apr 9 '20 at 20:11

The easiest thing to do is create a separate subdomain within your zone for each environment, i.e. <environment>.example.com. Then your services would create records like <service>.<environment>.example.com; this way each environment shouldn't clash with another if they both contain the same service.

If you have to have a <service>.example.com record then you can always create a CNAME record pointing to whichever environment has the authoritative version of the service running, usually your prod(uction) environment.

  • I was going in a similar direction before, maybe there is something I got wrong: if I create subdomains, as long as they are in the same zone then I still need to have that zone in all environments and the problem stays the same. (The resource is "google_dns_managed_zone" and I need it if I want to configure public facing services. So it needs to be imported between envs and if an env gets destroyed it is destroyed as well.)
    – Bastian
    Feb 20 '19 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.