4

Using Google Cloud DNS I have foo.com DNS Zone setup. I would like a separate DNS Zone to be delegated responsiblity for dev.foo.com domain names ( e.g. myappserver.dev.foo.com could be defined in the delegated DNS zone )

I could of course simply add an A Record into the foo.com definition. But I am using Terraform ( as Infrastructure as code ) and the dev subdomain ( servers/records etc ) will be built and destroyed on a regular basis.

The problem is that if I have all this in one DNS Zone that is built/destroyed regularly then this would mean that everything in foo.com would be unstable. I just want anything on dev.foo.com to be unstable from this point of view.

Is this possible? It would seem this would be easy using different name servers for dev.foo.com, so I'm assuming it should be okay somehow using the same nameservers but a different DNS Zone. Perhaps something to do with circular dependencies and glue records but I haven't managed to get anything working yet.

Andy Boyle
  • 71
  • 1
  • 5
  • I have a solution of sorts. When using terraform ( or any GCloud client I guess ) the nameservers of a new DNS Managed Zone are "computed" - assigned by Google but without predication. If these Name Servers are different than my parent Zone's then it is a simple case of point **dev**.foo.com to the Name Server's assigned for dev.foo.com Zone. – Andy Boyle Jan 24 '17 at 14:15
  • From a Terraform point of view I don't want to destroy the sub DNS zone. This is kind of possible using **prevent_destory** although there is an outstanding bug ( See https://github.com/hashicorp/terraform/issues/3874 ). In meantime I can split up terraform project into **transient** and **sticky/permenant** sub projects in order to get the behaviour I want. I will confirm later if this works as expected. – Andy Boyle Jan 24 '17 at 14:18
  • So yeah, splitting out the terraform projects into "enduring" and "ephemeral" means that only when I run the "enduring" porject ( i.e. assign new Name Servers to dev.foo.com ) do I then need to manually update these in the parent DNS entry. Rest is automated after that so consider me happy :-) – Andy Boyle Jan 26 '17 at 14:32
  • +1 for using Terraform, it's great. Terraform shouldn't need to create/destroy the subzone when you are making changes, it can just update the record sets (https://www.terraform.io/docs/providers/google/r/dns_record_set.html) to match. Even in the case where you are creating a project from scratch with a main and delegated subzones, it should be possible to automate this, as you can use the [name_servers](https://www.terraform.io/docs/providers/google/r/dns_managed_zone.html#name_servers) attribute to get the name servers for the subzone and create a corresponding NS record in the parent zone. – Alex Dupuy Jan 29 '17 at 00:20
  • If you can post (a link to) a simple sample TF file that sets up the parent and child zones, I could probably suggest an edit to automate the NS record set up or other changes that would work a bit better. – Alex Dupuy Jan 29 '17 at 00:26
  • Thanks for comments @AlexDupuy The parent zone is actually manual in this case ... and some way from being IAC ( because it runs other software ). But that said if I do get there then I hear you on the update option ( i.e. updating the parent ). To be clear only the sub domain is destroyed and recreated - mainly an economical reasons for running VM costs ( but defintely enjoyed getting to use the power of Terraform et al!). Thanks for your suggestion though and I'll hopefully get to implement in future. – Andy Boyle Jan 31 '17 at 21:21

1 Answers1

2

Instead of destroying the dev subdomain on a regular basis, delegate it to another nameserver (by including NS [and A glue!] records for dev.foo.com) -- which may also reside at Google, or not, as you wish -- and then have Terraform create and destroy RRs (Resource Records, such as A, CNAME, etc) within the dev.foo.com domain.

You shouldn't need to destroy and recreate dev.foo.com, and if for some reason you do (such as the ability to really test the creation and destruction of records at the level of the main domain itself), use a different domain name altogether such as foo-test.com, foo.io, etc.

Alex
  • 661
  • 1
  • 5
  • 18